What are Kubernetes secrets?

Kubernetes secrets are Kubernetes objects designed to hold small pieces of sensitive data such as passwords, tokens, API keys, transport layer security (TLS) certificates and SSH keys. They are a core part of Kubernetes secrets management and help secure cloud-native workloads by separating confidential data from container images, configuration files and plain text manifests.

A secret is an object in a Kubernetes cluster that stores secret data as key-value pairs, typically representing credentials, tokens or certificates needed by workloads. Kubernetes objects are persistent resources that define the wanted state of your cluster.

Kubernetes secrets allow you to store sensitive information separately from pods and application code, enhancing security. The Kubernetes API treats secrets as first‑class resources, enabling this process to work. With this approach, pods, deployments and other controllers can reference them without embedding sensitive information directly in the pod spec or hardcoding it into applications.

Kubernetes secrets are distinct fromConfigMaps , which are intended for non-sensitive configuration data. Secrets are intended for sensitive data that should not be exposed in plain text or in container images. Common use cases include authentication secrets for databases, API keys for third-party services, SSH authentication material, TLS certificates and Docker registry credentials.

Kubernetes, often called k8s or kube, is an open source platform for orchestrating containerized applications across distributed environments. It automates core operational tasks such as deploying applications, managing their lifecycle and scaling workloads as demand changes. By handling responsibilities like container scheduling and service discovery, Kubernetes provides a consistent framework for running applications reliably at scale. This action allows teams to focus on building and improving software rather than managing the underlying infrastructure.

Kubernetes secrets are stored inetcd , the key-value store backing the Kubernetes API server, and are by default Base64 encoded rather than encrypted. This encoding is for transport and formatting purposes and does not protect against disclosure. It is for that reason that encrypting secrets at rest inetcd  is recommended for strong confidentiality.

The Kubernetes API server exposes secret objects through the Kubernetes API and only authenticated and authorized clients can access them based on role-based access control (RBAC) policies. Kubelet, the node agent, retrieves secret objects referenced by pods scheduled onto that node and makes them available to the container runtime.

This action allows them to be mounted into pods or injected as environment variables. This process lets pods use confidential data without directly embedding it in the pod spec or container images.

A secret is typically defined in a YAML file. This file can then be applied with akubectl  command. A basic secret manifest includes fields such as apiVersion, kind, metadata and either data orstringData  to define the secret key-value pairs. A generic secret that uses Base64 encoded data might look like this:

apiVersion: v1

kind: Secret

metadata:

name: mysecret

namespace: default

annotations:

app.kubernetes.io/description: “Sample secret for auth”

type: Opaque

data:

username: dXNlcg==

password: cGFzc3dvcmQ=

In this example, the data values are Base64 encoded representations of the plain text values. However, the underlying semantics are just key-value pairs representing secret data. Alternatively,stringData  can be used to specify values in plain text in the YAML file, with Kubernetes encoding them to Base64 upon creation of the secret object.

Kubernetes supports several built-in types of secrets, each optimized for different use cases. The “type” field in the secret manifest helps the API server and tools validate the data structure and enforce constraints for each type.

• Opaque secrets: The default type for arbitrary key-value pairs representing sensitive information such as API keys or passwords.
• Service account token secrets: Used to store tokens that allow pods to authenticate to the Kubernetes API, typically associated with a service account.
• Docker registry (dockerconfigjson) secrets: Hold credentials for authenticating to container registries when pulling private container images.
• TLS secrets: Store TLS certificates and private keys for securing communications to services through HTTPS or other TLS-based protocols.
• Basic authentication (kubernetes.io/basic-auth) secrets: Store username/password combinations for basic authentication scenarios.
• SSH authentication secrets: Store private keys used for SSH authentication.
• Bootstrap token secrets: Support node bootstrap and join operations when adding new nodes to a cluster.

Kubernetes provides options to create secret objects directly from the command line with kubectl. A common approach is to use “kubectl create secret generic” to generate an opaque secret from literals or files.

The next example presents how to create a generic secret from literal key-value pairs:

kubectl create secret generic mysecret \

  --from-literal=username=user \

  --from-literal=password=password

This command stores the provided literals as Base64 encoded secret keys in themysecret  secret object. To confirm the secret exists, you can usekubectl get secret mysecret  orkubectl describe secret mysecret  to view metadata and the number of data items stored.

Secrets can also be created from existing files, which is especially useful when you have certificates or keys already stored as files on disk. To do this action, apply the method in this example:

kubectl create secret generic db-user-pass \

  --from-file=username.txt \

  --from-file=password.txt

We can see here that each file becomes a key in the secret data, with its contents Base64 encoded as the corresponding value.

You can inspect secrets by usingkubectl :

List all secrets in a namespace

kubectl get secrets

View details about a specific secret

kubectl describe secret mysecret

Check which keys exist inside a secret

kubectl get secret mysecret -o jsonpath=’{.data}’

Because secret data is stored as Base64 values, you must decode them to read the actual content.

Read a specific key

kubectl get secret mysecret -o jsonpath=’{.data.username}’ | base64 --decode

Read all keys in a secret

kubectl get secret mysecret -o json | jq -r ‘.data | map_values(@base64d)’

Export a secret to YAML

kubectl get secret mysecret -o yaml

(Values will still be Base64‑encoded.)

After creation, workloads such as pods, deployments and “StatefulSets” reference secrets through the pod spec. This method will allow for secure injection of confidential data. There are two primary ways to consume a secret: as environment variables or as mounted volumes inside the container file system.

To use secret values as environment variables, you can use env and valueFrom with secretKeyRef in the pod spec:

apiVersion: v1

kind: Pod

metadata:

name: secret-env-pod

spec:

containers:

- name: app

image: docker.io/library/nginx:latest

env:

 - name: DB_USERNAME

 valueFrom:

  secretKeyRef:

  name: mysecret

   key: username

   - name: DB_PASSWORD

   valueFrom:

   secretKeyRef:

    name: mysecret

    key: password

This pod uses environment variables to inject secret data into the application process, avoiding plain text values in the YAML or container image.

Another method you can apply is mounting a secret as a volume within the container file system:

apiVersion: v1

kind: Pod

metadata:

name: secret-volume-pod

spec:

containers:

- name: app

image: docker.io/library/nginx:latest

volumeMounts:

- name: secret-volume

mountPath: “/etc/secret”

readOnly: true

volumes:

- name: secret-volume

secret:

secretName: mysecret

In this instance, each key in the secret data is represented as a file under themountPath , which allows application code to read credentials from files. Volume mounts are often used for TLS certificates, SSH keys or other file-based credentials.

Kubernetes uses role-based access control (RBAC) to constrain which users and service accounts can read or modify secret objects within a namespace. RBAC roles and role bindings specify authorized operations such as get, list and update on secret resources. Following a least-privilege model is recommended to minimize exposure of sensitive data.

Secrets are namespaced resources, meaning each secret resides in a specific namespace and is accessible only to workloads and users with permissions in that namespace. Anyone authorized to create pods in a namespace can potentially configure a pod to reference any secret in that namespace. This access means that controlling who can create or update workloads is a critical part of Kubernetes secrets management.

Service accounts provide identities for pods and are often associated with specific permissions to access secrets. Service account tokens themselves can be represented as secrets and Kubernetes automatically mounts them into pods, which makes it essential to carefully manage service account permissions.

Kubernetes supports encrypting secret data at rest by enabling encryption providers configured on the API server, which ensures that secret data is encrypted before being written toetcd . This feature is a key part of encrypting secrets and protects against disclosure if the underlying store is compromised. In addition, TLS is used for communication between components such as kubelet and the API server, protecting secrets in transit.

Managing secrets in Kubernetes involves securing them throughout their entire lifecycle. By lifecycle this means creation, storage, access, rotation and deletion. Kubernetes provides several built‑in mechanisms to help you protect sensitive data and the official documentation offers detailed guidance on these practices. The next steps are the optimal method to manage Kubernetes secrets:

1. Enable encryption at rest, so secret data is encrypted before being written to etcd. This action prevents attackers from reading sensitive values even if they gain access to the data.
2. Use RBAC to restrict access to secret objects. Only trusted users and service accounts should have permission to read or modify secrets.
3. Limit the number of users that can create pods because anyone with pod‑creation rights in a namespace can mount any secret in that namespace.
4. Rotate secrets regularly, especially credentials, API keys and TLS certificates. Automating rotation helps reduce the risk of long‑lived credentials being compromised.
5. Use external secret managers (such as HashiCorp® Vault, AWS Secrets Manager or Google Secret Manager) together with the Secrets Store CSI driver when you need centralized lifecycle management or compliance‑grade security.
6. Audit secret access by using Kubernetes audit logs to detect suspicious or unauthorized reads.
7. Avoid storing secrets in version control, even in Base64 form. Use tools that support secure templating or encrypted manifests when necessary.

• Enable encryption at rest for secrets stored in etcd to protect against compromise of the backend store.
• Apply strict RBAC policies and least-privilege principles so only necessary users, service accounts and workloads can access specific secrets.
• Avoid storing secrets in plain text within version control. Use carefully and consider tools that manage YAML files securely.
• stringData
• ​Rotate sensitive data regularly, including API keys, passwords and TLS certificates and automate updates where possible.