How to create a Secret in Kubernetes? & It's Lifecycle

What is a Secret in Kubernetes?

A simple API object called a Kubernetes Secret may store and manage passwords, OAuth tokens, SSH keys, and database credentials. Decoupling sensitive configuration data from the container image is best practice in modern containerization. Passwords or certificates that are “baked” into an image layer remain accessible even if the file is later deleted because container layers are additive and an attacker can obtain previous states. Secrets allows developers to create portable and reusable container images that are comparable in staging, production, and development environments. The sensitive data is only injected during runtime.

The Core Concept: Decoupling Sensitive Data

It is essential to manage configuration and code independently in a contemporary cloud-native environment. Secrets are expressly set aside for data that needs to be protected and have restricted access, whereas ConfigMaps are used for non-confidential settings such as hostnames or ports. ConfigMaps store data in plaintext, but Secrets use Base64.

Focus on the fact that Base64 encoding is not encryption but a technique to store binary-safe data. The cluster’s etcd datastore stores secrets by default. Enabling encryption at rest for the API server is a best practice to guarantee the physical storage of Secrets is secure, since etcd contains all cluster state data.

You can also read Kind: A Practical Guide to Local Kubernetes Clusters

Creation and Structure

Kubernetes Secrets can be generated declaratively with YAML manifests or imperatively with the command line.

Imperative Creation

The kubectl create secret command allows you to generate a Secret directly from literal values or files on disk. For example, to create a Secret named creds with a username and password:

kubectl create secret generic creds \
  --from-literal=username=nigelpoulton \
  --from-literal=password=Password123

Alternatively, you can load data from local files, which is particularly useful for TLS certificates:

kubectl create secret generic kuard-tls \
  --from-file=kuard.crt \
  --from-file=kuard.key

Declarative Creation (YAML)

When defining a Secret in a YAML file, you must provide the values in their base64-encoded format. To encode a value like “app-db” on a Linux system, you would use: echo -n "app-db" | base64.

apiVersion: v1
kind: Secret
metadata:
  name: api-secret
type: Opaque # The default type for user-defined secrets
data:
  dbname: YXBwLWRi
  dbuser: YXBwLXVzZXI=
  dbpass: YXBwLXBhc3M=

Alternatively, Kubernetes provides a stringData field (not shown in all examples but implied by management tools) that allows you to provide values in plain text within the YAML; the API server will automatically convert these to Base64 when the object is created.

You can also read How to Get Started Kubernetes? Explained Briefly

Consuming Secrets in Pods

Pods can use Secret data as command-line parameters, volume files, or environment variables.

As Environment Variables

Injecting Secrets as environment variables is common for database credentials. However, this method has a significant drawback: environment variables are static. If the Secret is updated in the cluster, the running container will not see the new value until it is restarted.

Example Deployment using Secret Env Vars:

spec:
  containers:
  - name: mysql
    image: mysql:5.6
    env:
    - name: MYSQL_ROOT_PASSWORD
      valueFrom:
        secretKeyRef:
          name: app-secret
          key: dbpass

As Volume Mounts

Mounting a Secret as a volume is often preferred for applications that expect configuration files on disk or for larger sets of credentials.

apiVersion: v1
kind: Pod
metadata:
  name: volume-secret-pod
spec:
  containers:
  - name: app-container
    image: nginx
    volumeMounts:
    - name: cert-vol
      mountPath: "/etc/certs"
      readOnly: true
  volumes:
  - name: cert-vol
    secret:
      secretName: tls-certs

Inside the container, each key in the Secret becomes a file in /etc/certs/, and the file’s content is the decoded Secret value.

Update Lifecycle and Management

The way updates are sent to active Pods is one of Secrets’ most important operational features:

Environment Variables are Static: Until the Pod is restarted or a fresh rollout is initiated, Pods that use a Secret as an environment variable will not see the modified values.
Mounted Volumes Update Automatically: The kubelet eventually updates the files in the mounted volume during its recurring sync when a Secret is updated. The kubelet’s sync period (by default, one minute) and cache propagation delay determine the latency.
SubPath Restriction: Automatic updates won’t be sent to containers that use a Secret as a subPath volume mount.

You can also read What is the Importance of Kubernetes & Why Kubernetes?

Immutable Secrets

Starting with Kubernetes v1.19 (stable in v1.21), you can mark a Secret as immutable.

apiVersion: v1
kind: Secret
metadata:
  name: static-credentials
immutable: true
data:
  key: ...

Advantages of Immutability:

Safety: Protects against malicious or accidental changes causing application downtime.
Performance: The reduction of API server burden is achieved by making clusters with thousands of Secrets immutable, which eliminates the necessity to “watch” for changes.

The only way to change an immutable Secret is to wipe and rebuild it, which frequently requires rebuilding the connected Pods.

Technical Constraints and Size Limits

The size restriction for a Secret item is strictly 1 MiB. This comprises all of the key-value pairs and metadata that are kept inside the object. Because secrets are kept in etcd and big objects can impair the cluster’s overall stability and performance, this limit is enforced. It is advised to utilize a different file service or Kubernetes Volumes if you need to store larger files.

Security Best Practices

Secrets are just as safe as the cluster configuration, even if they offer a fundamental layer of separation. Expert suggestions include of:

The NSA and CISA advise a number of hardening steps because secrets are not secure by default.
Encryption at Rest: On the API server, cluster managers should set up data-at-rest encryption. This is frequently accomplished by linking with an external Key Management Service (KMS) via a cloud provider, which stops local drives from storing raw encryption keys.
Role-Based Access Control (RBAC): There should be stringent restrictions on access to the secret resource. It should only be possible for Pods and users that have a validated “need to know” to get or list Secrets within a namespace.
Audit Logging: The audit policy should be set up to log Secret-related requests at the Metadata level rather than RequestResponse in order to avoid sensitive material from escaping into system logs.
Service Account Tokens: Kaubernetes automatically installs a service account token as a Secret to provide each Pod a unique identity. If a Pod does not need to communicate with the API server, administrators should disable this by setting automountServiceAccountToken: false in the Pod spec to reduce the attack surface.
Third-Party Tools: In lieu of native Kubernetes Secrets for business security, numerous organizations implement HashiCorp Vault, AWS Secrets Manager, or Google Secrets Manager, which provide sophisticated rotation and fine-grained access controls.

You can also read What is Container Orchestration in Kubernetes?

Page Content

Tutorials

How to create a Secret in Kubernetes? & It’s Lifecycle