# Good practices for Kubernetes Secrets

> Principles and practices for good Secret management for cluster administrators and application developers.

---

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->

<p><p>In Kubernetes, a Secret is an object that stores sensitive information, such as passwords, OAuth tokens, and SSH keys.</p></p>
<p>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
<a href="/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted">encrypted at rest</a>.</p>
<p>A <a class='glossary-tooltip' title='A Pod represents a set of running containers in your cluster.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/workloads/pods/' target='_blank' aria-label='Pod'>Pod</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
<a href="/docs/tasks/configure-pod-container/configure-pod-configmap/">ConfigMaps</a> are
designed for non-confidential data.</p>

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.

<!-- body -->

## Cluster administrators

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

### Configure encryption at rest

By default, Secret objects are stored unencrypted in <a class='glossary-tooltip' title='Consistent and highly-available key value store used as backing store of Kubernetes for all cluster data.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/tasks/administer-cluster/configure-upgrade-etcd/' target='_blank' aria-label='etcd'>etcd</a>. You should configure encryption of your Secret
data in `etcd`. For instructions, refer to
[Encrypt Secret Data at Rest](/docs/tasks/administer-cluster/encrypt-data/).

### Configure least-privilege access to Secrets {#least-privilege-secrets}

When planning your access control mechanism, such as Kubernetes
<a class='glossary-tooltip' title='Manages authorization decisions, allowing admins to dynamically configure access policies through the Kubernetes API.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/reference/access-authn-authz/rbac/' target='_blank' aria-label='Role-based Access Control'>Role-based Access Control</a> [(RBAC)](/docs/reference/access-authn-authz/rbac/),
consider the following guidelines for access to `Secret` objects. You should
also follow the other guidelines in
[RBAC good practices](/docs/concepts/security/rbac-good-practices).

- **Components**: Restrict `watch` or `list` access to only the most
  privileged, system-level components. Only grant `get` access for Secrets if
  the component's normal behavior requires it.
- **Humans**: Restrict `get`, `watch`, or `list` access to Secrets. Only allow
  cluster administrators to access `etcd`. 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.

<div class="alert alert-caution" role="note"><h4 class="alert-heading">Caution:</h4>Granting <code>list</code> access to Secrets implicitly lets the subject fetch the
contents of the Secrets.</div>


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:

*  Use short-lived Secrets
*  Implement audit rules that alert on specific events, such as concurrent
   reading of multiple Secrets by a single user

#### Restrict Access for Secrets
Use separate namespaces to isolate access to mounted secrets.

### Improve etcd management policies

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

<div class="alert alert-secondary callout third-party-content" role="note"><strong>Note:</strong>&puncsp;This section links to third party projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for these projects, which are listed alphabetically. To add a project to this list, read the <a href="/docs/contribute/style/content-guide/#third-party-content">content guide</a> before submitting a change. <a href="#third-party-content-disclaimer">More information.</a></div>


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 [Kubernetes Secrets Store CSI Driver](https://secrets-store-csi-driver.sigs.k8s.io/)
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](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver).

## Good practices for using swap memory

For best practices for setting swap memory for Linux nodes, please refer to
[swap memory management](/docs/concepts/cluster-administration/swap-memory-management/#good-practice-for-using-swap-in-a-kubernetes-cluster).

## Developers

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

### Restrict Secret access to specific containers

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.

### Avoid sharing Secret manifests

If you configure a Secret through a
<a class='glossary-tooltip' title='A serialized specification of one or more Kubernetes API objects.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/reference/glossary/?all=true#term-manifest' target='_blank' aria-label='manifest'>manifest</a>, with the secret
data encoded as base64, sharing this file or checking it in to a source
repository means the secret is available to everyone who can read the manifest.

<div class="alert alert-caution" role="note"><h4 class="alert-heading">Caution:</h4>Base64 encoding is <em>not</em> an encryption method, it provides no additional
confidentiality over plain text.</div>