Bug 1413729 - [DOCS] Service Serving Certificate primary usecase is for "re-encrypt routes"
Summary: [DOCS] Service Serving Certificate primary usecase is for "re-encrypt routes"
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Documentation
Version: 3.4.0
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
: ---
Assignee: Brandi Munilla
QA Contact: Yan Du
Vikram Goyal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-16 20:20 UTC by Eric Rich
Modified: 2017-02-22 15:01 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-22 15:01:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Eric Rich 2017-01-16 20:20:12 UTC
Document URL: https://docs.openshift.com/container-platform/3.3/dev_guide/secrets.html#service-serving-certificate-secrets

Section Number and Name: Service Serving Certificate

Describe the issue: The certificate (that is created with this feature) will be good for the internal service DNS name, <service.name>.<service.namespace>.svc. The problem with this is that the DNS name, <service.name>.<service.namespace>.svc is not externally routable (in most cases). 

Suggestions for improvement: We should explain that when using this feature, the purpose or intent is for it to be used with "reencrypt" routes (using the wildcard DNS) so that the client -> router communication is secured by the routers default certificate, and the router -> service (pod) communication is secured by the generated service certificate (that was auto created). 

Additional information: 

This documenation will be needed until DNS work offered by: https://bugzilla.redhat.com/show_bug.cgi?id=1393486 can allow for this feature to use the dynamic DNS name and not the service DNS name.

Comment 1 Clayton Coleman 2017-01-16 20:22:44 UTC
Well, the primary use is for intracluster or intraservice communication.  But absolutely the next most primary use is reencrypt.

Anyone generating a cert using oadm create-cert for the service name + public route name should probably be using service serving certs + reencrypt (includes registry, router, etc)

Comment 2 Brandi Munilla 2017-02-03 21:00:56 UTC
Hi Eric, Clayton, and Yan,

I opened PR#3660[1] with a note clarifying the use of <service.name>.<service.namespace>.svc in the Service Serving Certificates section. Please take a look when you have a chance. 

Thanks!

[1] https://github.com/openshift/openshift-docs/pull/3660

Comment 3 Meng Bo 2017-02-04 02:56:10 UTC
The changes look good, verify the bug.

Comment 4 openshift-github-bot 2017-02-07 20:44:22 UTC
Commits pushed to master at https://github.com/openshift/openshift-docs

https://github.com/openshift/openshift-docs/commit/14bf9cb104011b4faeacff3dfa1862d31d3608a4
Bug 1413729 Added a note clarifying the use of <service.name>.<service.namespace>.svc.

https://github.com/openshift/openshift-docs/commit/f29155a2315b7bfbc57840df2402f45274581ba0
Merge pull request #3660 from bmcelvee/BZ1413729

Bug 1413729 Added a note clarifying the use of `<service.name>.<service.namespace>.svc`

Comment 5 Brandi Munilla 2017-02-07 20:46:25 UTC
Thanks, Meng!


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