OpenShift Secrets Concepts: Difference between revisions
Line 14: | Line 14: | ||
A secret is a piece of text or binary data, associated with a name. OpenShift offers a "Secret" primitive, that can be created and managed independently of any other primitives, then associated with a pod in such a way that the name/data is exposed, or "delivered" to the pod. This approach is convenient when dealing with confidential data that | A secret is a piece of text or binary data, associated with a name. OpenShift offers a "Secret" primitive, that can be created and managed independently of any other primitives, then associated with a pod in such a way that the name/data is exposed, or "delivered" to the pod. This approach is convenient when dealing with confidential data that should not be stored in the images the pods are created from. | ||
For more details on the "Secret" primitive definition see: {{Internal|OpenShift Secret Definition|Secret Definition}} | For more details on the "Secret" primitive definition see: {{Internal|OpenShift Secret Definition|Secret Definition}} |
Revision as of 17:26, 30 January 2018
External
- https://docs.openshift.com/container-platform/latest/dev_guide/secrets.html
- https://kubernetes.io/docs/concepts/configuration/secret/
- https://github.com/kubernetes/community/blob/master/contributors/design-proposals/auth/secrets.md
- https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/
- https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
Internal
Overview
A secret is a piece of text or binary data, associated with a name. OpenShift offers a "Secret" primitive, that can be created and managed independently of any other primitives, then associated with a pod in such a way that the name/data is exposed, or "delivered" to the pod. This approach is convenient when dealing with confidential data that should not be stored in the images the pods are created from.
For more details on the "Secret" primitive definition see:
OpenShift uses secrets routinely to hold keys for authentication to other internal systems like Docker registries.
The simplest procedure to expose such name/value pair is:
1. Create the secret, based on the content of a file
echo "passwd123" > ./db-passwd
oc secret new db-password-secret ./db-passwd
This is a terse syntax, where the name of the key is inferred from the name of the file. More explanatory syntax variants are available. TODO - link to operations.
The secret thus created is:
oc get -o yaml secret/db-password-secret
apiVersion: v1 data:
db-passwd: cGFzc3dkMTIzCg==
kind: Secret
2. Expose the name/confidential value to a pod, automatically, by associating the secret with the deployment configuration that creates the pod. The data can be exposed as a file, using the volume mechanism, or an environment variable.
2.1 Exposing the data as a file, by using the volume mechanism:
oc set volume dc/centos-loop --add --name=db-password-volume --mount-path=/etc/secrets --secret-name= db-password-secret
The confidential data will become available to the pod as the content of the /etc/secrets/db-password file.
The volume is mounted as "tmpfs":
mount tmpfs on /etc/secrets type tmpfs (rw,relatime,seclabel)
2.2 Exposing the data as the value of an environment variable:
oc env dc/centos-loop --from=secret/db-password-secret --prefix=BLUE_
env | grep BLUE BLUE_DB_PASSWD=passwd123
Difference from a ConfigMap.
Accessibility: not encrypted, base64 - how can it be protected?
Operations
Organizatorium
They are base64 encoded. Are mounted into pods using the volume mount mechanism. The volumes are backed by temporary file-storage facilities (tmpfs). Secrets from builds can be referenced.
By default, every container is given a single secret which contains a token for accessing the API with limited privileges, at /var/run/secrets/kubernetes.io/serviceaccount.
Secret Types
Key File-Based
Basic Auth
A secret containing the user name and the password to use in HTTP basic authentication.