Kubernetes Secrets : Securely Managing Sensitive Data in Your Applications

Kubernetes Secrets separate sensitive application settings from a container image. They can hold values such as a database password, token or certificate. That separation is useful, but the word “Secret” does not mean the value is automatically encrypted everywhere or hidden from every cluster user.

What a Secret protects—and what it does not

Secret values in the data field are base64-encoded. Base64 is an encoding, not encryption. Upstream Kubernetes stores Secrets unencrypted in etcd by default unless encryption at rest has been configured. Managed platforms can apply different defaults, so verify the settings for your own cluster.

Access control is equally important. Someone with permission to read a Secret can retrieve its contents. A person who can create workloads in a namespace may also be able to arrange for a workload to read a Secret there. Namespace access needs to reflect that relationship.

A small example without a password in the command

For a learning environment, place a disposable test value in a local file called password.txt. Keep it outside source control and restrict access to the file. The following example assumes that a namespace named demo already exists:

kubectl -n demo create secret generic app-credentials \
  --from-file=password=./password.txt

The file is still sensitive. Using a file avoids putting its value directly into this command, but does not make local storage, backups or access to the workstation safe automatically. Production credential handling should follow your organisation’s approved process.

Choose how the application receives the value

A workload can reference a Secret through an environment variable or a mounted file. Choose the method the application supports. Avoid exposing the same credential through both methods unless there is a reason.

Here is a fragment to place inside a container definition in a Pod or Deployment specification:

env:
  - name: APP_PASSWORD
    valueFrom:
      secretKeyRef:
        name: app-credentials
        key: password

The Secret and the workload must be in the same namespace. This fragment does not create a complete Deployment or initialise a database; it only shows how an application environment variable can reference a Secret key.

Plan credential rotation

Updating a Secret does not automatically change an environment variable inside an already-running process. Plan a controlled rollout when the application reads credentials at startup. Mounted Secret files have different update behaviour, and the application still needs a way to reload the changed value; mounts using subPath have additional limitations.

Test the full sequence: introduce the new credential, update the application, confirm connectivity, and retire the previous credential when it is safe to do so. Changing a Kubernetes object is only one part of rotation.

A practical review checklist

• Verify encryption at rest and protection of etcd backups.
• Grant only the Secret access each workload and operator needs.
• Keep real Secret manifests and credentials out of public repositories and logs.
• Check who can create Pods or Deployments in the namespace.
• Document rotation and recovery, including external services that use the credential.

Official references

• Kubernetes Secrets
• Good practices for Kubernetes Secrets
• Encrypting confidential data at rest

Related reading

• Docker Secrets: Command-Line Management Guide
• AI and ML for Kubernetes Intrusion Detection