Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1314553 - [RFE] Feature to provide certificate or keys to templates for routes and other objects using secrets or secure method.
[RFE] Feature to provide certificate or keys to templates for routes and othe...
Status: CLOSED ERRATA
Product: OpenShift Container Platform
Classification: Red Hat
Component: RFE (Show other bugs)
3.1.0
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Ben Parees
zhaozhanqi
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-03 17:01 EST by Ryan Howe
Modified: 2017-03-08 13 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-18 07:39:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0066 normal SHIPPED_LIVE Red Hat OpenShift Container Platform 3.4 RPM Release Advisory 2017-01-18 12:23:26 EST

  None (edit)
Description Ryan Howe 2016-03-03 17:01:05 EST
Description of problem:

When creating templates with objects requiring cert and key data. Add the the ability to supply this data via a secret. Need to avoid placing the certs directly into the template. 


Version-Release number of selected component (if applicable):
3.x

How to accomplish:
1. Be able to extract secret data to to be added via a parameter to be added to objects created in a template 

2. Define a secret to be used for the route cert and key, (edge termination routing)

3. Parameter able to read data from a file path. 


Additional info:

Example: Add a way to add a secret that will provide this data to the routespec.tls  

https://docs.openshift.com/enterprise/3.1/rest_api/openshift_v1.html#v1-routespec
https://docs.openshift.com/enterprise/3.1/rest_api/openshift_v1.html#v1-tlsconfig
Comment 1 Ben Parees 2016-10-18 15:04:12 EDT
Since secrets can now be defined in terms of string values using the stringdata field on secrets, this is now achievable.

Reading parameters from a file path is being handled elsewhere and is orthogonal to this RFE:
https://github.com/openshift/origin/pull/10952/files
Comment 2 zhaozhanqi 2016-10-18 21:15:30 EDT
since this PR 10952 have not been merged and also the bug was reported to OCP. So I changed the status to Assigned. please feel free change to ON_QA once this PR 10952 was merged to OCP. thanks
Comment 3 Ben Parees 2016-10-18 22:14:47 EDT
The pr is unrelated to this rfe. We are not concerned with reading parameters from a file in this rfe. 

Secrets can be defined via parameters using the stringData mechanism, so the rfe is complete.
Comment 4 zhaozhanqi 2016-10-18 22:40:17 EDT
Thanks Ben

 I checked the bug again. and this bug should already fixed as my understanding. we can use CLI to create tls route with related cert/key. example:

$oc create route edge -h
Create a route that uses edge TLS termination

Specify the service (either just its name or using type/name syntax) that the
generated route should expose via the --service flag.

Usage:
  oc create route edge [NAME] --service=SERVICE [options]

Examples:
  # Create an edge route named "my-route" that exposes frontend service.
  oc create route edge my-route --service=frontend
  
  # Create an edge route that exposes the frontend service and specify a path.
  # If the route name is omitted, the service name will be re-used.
  oc create route edge --service=frontend --path /assets

Options:
      --ca-cert='': Path to a CA certificate file.
      --cert='': Path to a certificate file.
      --hostname='': Set a hostname for the new route
      --insecure-policy='': Set an insecure policy for the new route
      --key='': Path to a key file.
  -o, --output='': Output mode. Use "-o name" for shorter output (resource/name).
      --path='': Path that the router watches to route traffic to the service.
      --port='': Name of the service port or number of the container port the route will route traffic to
      --schema-cache-dir='~/.kube/schema': If non-empty, load/store cached API schemas in this directory, default is '$HOME/.kube/schema'
      --service='': Name of the service that the new route is exposing
      --validate=false: If true, use a schema to validate the input before sending it

Use "oc options" for a list of global command-line options (applies to all commands).

   so verified this bug.
Comment 6 errata-xmlrpc 2017-01-18 07:39:28 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:0066

Note You need to log in before you can comment on or make changes to this bug.