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/basic-auth: Use with Basic authentication

  • kubernetes.io/dockercfg: Use as an image pull secret

  • kubernetes.io/dockerconfigjson: Use as an image pull secret

  • kubernetes.io/service-account-token: Use to obtain a legacy service account API token

  • 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.

Note

You can specify other arbitrary types, such as example.com/my-secret-type. These types are not enforced server-side, but indicate that the creator of the secret intended to conform to the key/value requirements of that type.

For examples of creating different types of secrets, see Understanding how to create secrets.

↑ Up: Understanding secrets | ⌂ Home: Red Hat OpenShift Container Platform | Next: Secret data keys →