Bug 1413729

Summary: [DOCS] Service Serving Certificate primary usecase is for "re-encrypt routes"
Product: OpenShift Container Platform Reporter: Eric Rich <erich>
Component: DocumentationAssignee: Brandi <bmcelvee>
Status: CLOSED CURRENTRELEASE QA Contact: Yan Du <yadu>
Severity: medium Docs Contact: Vikram Goyal <vigoyal>
Priority: low    
Version: 3.4.0CC: aos-bugs, bmeng, ccoleman, jokerman, mmccomas
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-22 15:01:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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 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 2017-02-07 20:46:25 UTC
Thanks, Meng!