Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

automatic service serving cert signer #2324

Merged
merged 1 commit into from Aug 30, 2016
Merged

automatic service serving cert signer #2324

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
15 changes: 15 additions & 0 deletions dev_guide/secrets.adoc
View file
Open in desktop
Expand Up @@ -116,6 +116,21 @@ Pull Secrets] for more information.
See link:builds.html#using-private-repositories-for-builds[Using Private
Repositories for Builds] for more information.

[[service-serving-certificate-secrets]]
=== Service Serving Certificate Secrets

To secure communication to your service, you can have the cluster generate a signed
serving certificate/key pair into a secret in your namespace. To do this, set the
"*service.alpha.openshift.io/serving-cert-secret-name*" to the name you want to use
for your secret. Your PodSpec can then mount that secret and when it is available
your pod will run. The certificate will be good for the internal service DNS name:
`*<service.name>.<service.namespace>.svc*`. The certificate and key are in PEM format,
stored in `*tls.crt*` and `*tls.key*` respectively.

Other pods can trust cluster-created certificates (which are only signed for internal
DNS names), by using the CA bundle in the `*/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt*`
file that is automatically mounted in their pod.

[[secrets-restrictions]]
== Restrictions

Expand Down