Bug 1413729

Summary:	[DOCS] Service Serving Certificate primary usecase is for "re-encrypt routes"
Product:	OpenShift Container Platform	Reporter:	Eric Rich <erich>
Component:	Documentation	Assignee:	Brandi Munilla <bmcelvee>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Yan Du <yadu>
Severity:	medium	Docs Contact:	Vikram Goyal <vigoyal>
Priority:	low
Version:	3.4.0	CC:	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:
Embargoed:

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!

Comment 6 Brandi Munilla 2017-02-22 15:01:43 UTC

Link to documentation on the Customer Portal: https://access.redhat.com/documentation/en-us/openshift_container_platform/3.4/html-single/developer_guide/#service-serving-certificate-secrets