Good practices for Kubernetes Secrets

    In Kubernetes, a Secret is an object that stores sensitive information, such as passwords, OAuth tokens, and SSH keys.

    Secrets give you more control over how sensitive information is used and reduces the risk of accidental exposure. Secret values are encoded as base64 strings and are stored unencrypted by default, but can be configured to be encrypted at rest.

    A can reference the Secret in a variety of ways, such as in a volume mount or as an environment variable. Secrets are designed for confidential data and ConfigMaps are designed for non-confidential data.

    The following good practices are intended for both cluster administrators and application developers. Use these guidelines to improve the security of your sensitive information in Secret objects, as well as to more effectively manage your Secrets.

    This section provides good practices that cluster administrators can use to improve the security of confidential information in the cluster.

    Configure least-privilege access to Secrets

    When planning your access control mechanism, such as Kubernetes Role-based Access Control , consider the following guidelines for access to Secret objects. You should also follow the other guidelines in RBAC good practices.

    • Components: Restrict watch or list access to only the most privileged, system-level components. Only grant access for Secrets if the component’s normal behavior requires it.
    • Humans: Restrict get, watch, or list access to Secrets. Only allow cluster admistrators to access . This includes read-only access. For more complex access control, such as restricting access to Secrets with specific annotations, consider using third-party authorization mechanisms.

    Caution: Granting list access to Secrets implicitly lets the subject fetch the contents of the Secrets.

    A user who can create a Pod that uses a Secret can also see the value of that Secret. Even if cluster policies do not allow a user to read the Secret directly, the same user could have access to run a Pod that then exposes the Secret. You can detect or limit the impact caused by Secret data being exposed, either intentionally or unintentionally, by a user with this access. Some recommendations include:

    • Implement audit rules that alert on specific events, such as concurrent reading of multiple Secrets by a single user

    Consider wiping or shredding the durable storage used by etcd once it is no longer in use.

    If there are multiple etcd instances, configure encrypted SSL/TLS communication between the instances to protect the Secret data in transit.

    Configure access to external Secrets

    You can use third-party Secrets store providers to keep your confidential data outside your cluster and then configure Pods to access that information. The is a DaemonSet that lets the kubelet retrieve Secrets from external stores, and mount the Secrets as a volume into specific Pods that you authorize to access the data.

    For a list of supported providers, refer to Providers for the Secret Store CSI Driver.

    Developers

    This section provides good practices for developers to use to improve the security of confidential data when building and deploying Kubernetes resources.

    If you are defining multiple containers in a Pod, and only one of those containers needs access to a Secret, define the volume mount or environment variable configuration so that the other containers do not have access to that Secret.

    Protect Secret data after reading

    Applications still need to protect the value of confidential information after reading it from an environment variable or volume. For example, your application must avoid logging the secret data in the clear or transmitting it to an untrusted party.

    Caution: Base64 encoding is not an encryption method, it provides no additional confidentiality over plain text.