Features and Types of Secrets
Features of secrets
The main features of secrets include:
- Secret data can be shared within a project namespace.
- Secret data is referenced independently of the secret definition. Administrators can create and manage a secret resource, and other team members reference the secret in their deployment configurations.
- Secret data is injected into pods when OKD creates a pod. You can expose a secret as an environment variable or as a mounted file in the pod.
- If the value of a secret change during pod execution, the secret data does not update in the pod. After a secret value changes, you must create new pods to inject the new secret data.
- Any secret data that OKD injects into a pod is ephemeral. If OKD exposes sensitive data to a pod as environment variables, those variables are destroyed when the pod is destroyed.
If a secret is mounted as a file in the pod, the file is also destroyed when the pod is destroyed. Secret data volumes are backed by temporary file storage.
Types of Secrets
The value in the type field indicates the structure of the secret’s key names and values. The type can be used to enforce the presence of user names and keys in the secret object. If you do not want validation, use the opaque type, which is the default.
Specify one of the following types to trigger minimal server-side validation to ensure the presence of specific key names in the secret data:
kubernetes.io/service-account-token. Uses a service account token.
kubernetes.io/basic-auth. Use with Basic Authentication.
kubernetes.io/ssh-auth. Use with SSH Key Authentication.
kubernetes.io/tls. Use with TLS certificate authorities.
Specify type: Opaque if you do not want validation, which means the secret does not claim to conform to any convention for key names or values. An opaque secret allows for unstructured key:value pairs that can contain arbitrary values.