Kubernetes Secrets: 8 Practices for Safer Credential Use

Kubernetes Secrets separate sensitive configuration from container images, but the object name is not a guarantee of confidentiality. A credential can still escape through a repository, an overpowered operator account, a compromised workload or an application log.

A useful secret-management design answers five questions: where the credential originates, how it reaches the workload, who can read it, how it changes and how access is revoked. This guide follows that lifecycle with eight practical checks and small examples.

Technical review: 30 October 2026. Examples use disposable lab credentials in an existing demo namespace. Do not paste production credentials into examples, screenshots or public manifests.

1. Kubernetes Secrets encoding is not encryption

The data field uses base64 encoding. Anyone who obtains that value can decode it; base64 is not cryptographic protection. Upstream Kubernetes requires encryption-at-rest configuration to protect stored Secret data in etcd. Managed platforms may apply their own defaults, so inspect the actual cluster configuration and provider documentation.

Protect etcd backups, encryption keys and recovery access as well. The encryption-at-rest procedure also matters during migration: changing a provider configuration does not itself rewrite every previously stored object. Follow the documented rewrite and key-rotation process rather than assuming an option change completes the work.

2. Treat workload creation as part of the access boundary

RBAC should limit reading, listing and watching Secrets. However, an identity that can create or modify workloads in a namespace may be able to arrange for a Pod to consume credentials there. Protect deployment permissions alongside direct Secret access.

Separate environments and trust levels intentionally. A namespace is a useful administrative boundary, but its protection depends on the permissions, admission controls and network design around it. Do not put untrusted build jobs beside highly privileged release credentials merely because their application labels differ.

# Authorised checks; these return permission decisions, not values
kubectl auth can-i get secrets -n demo
kubectl auth can-i list secrets -n demo
kubectl auth can-i create pods -n demo
kubectl auth can-i patch deployments.apps -n demo

Run impersonation checks only when you are authorised to do so. A permission review should include both expected denials and expected successful workload behaviour.

3. Create a disposable lab Secret without a value in the command

Place a disposable test password in a restricted local file called password.txt, outside source control. The file itself remains sensitive; protect its permissions and any workstation backups.

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

The second command displays metadata rather than the secret value. Avoid requesting YAML output in shared terminals, recordings or build logs. The creation command does not configure a database account: the credential must already correspond to the external service you intend to access.

A Kubernetes Secrets review should include who can read the object and who can create a workload that consumes it.

For a production workflow, decide whether an approved deployment system, a secret-management controller or a workload identity should deliver the credential. Manual workstation creation is a learning example, not an automatic recommendation for ongoing operations.

4. Choose mounted files or environment variables deliberately

Reference only the keys and containers that need the value. The following Pod fragment mounts a selected key read-only. It is a fragment, not a complete workload:

spec:
  containers:
    - name: app
      # Use your approved, pinned application image.
      volumeMounts:
        - name: credentials
          mountPath: /run/app-secrets
          readOnly: true
  volumes:
    - name: credentials
      secret:
        secretName: app-credentials
        items:
          - key: password
            path: password

Configure the application to read /run/app-secrets/password. File permissions and the container’s user identity must be compatible; verify that the application can read the file without broadening access unnecessarily.

An environment-variable reference is another option when the application expects it:

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

The Secret and Pod must be in the same namespace. Environment variables are fixed for an existing process; changing the object does not update them. Ordinary mounted Secret volumes receive changes eventually, but subPath mounts do not receive those automated updates. The application must also reload a changed file when appropriate.

5. Test secret rotation as a service change

Rotation crosses more than one system. Our suggested sequence is: provision the replacement credential at the issuing service, deliver it through the approved mechanism, make the application consume it, validate service access, then revoke the old credential once the transition is safe.

If your application reads credentials only on startup, plan a controlled rollout. A typical rollout command is shown below; execute it only after validating the new value and the service’s disruption requirements:

kubectl -n demo rollout restart deployment/web-api
kubectl -n demo rollout status deployment/web-api

Record a rollback plan before the change. If a provider supports overlapping credentials, use that capability deliberately; otherwise, coordinate the cutover to avoid a period in which every replica has an invalid password. Do not report success solely because a controller says an object was synchronised.

Verify Kubernetes Secrets rotation from the application’s point of view, including how a new value becomes active.

6. Understand what an external secret store changes

External Secrets Operator can reconcile values from external systems into Kubernetes Secret objects. That can centralise ownership and refresh policy, but it also means the resulting credential exists in Kubernetes and needs the same access and storage protections.

Other delivery patterns mount data through a supported CSI integration or let the application access an external service using workload identity. Choose based on provider support, application behaviour, availability requirements and operational ownership. Avoid adding a controller only because it has “Secrets” in its name.

Test the failure case: what happens when the external store is temporarily unavailable? Existing access, new Pod startup and rotation may behave differently. Put that result in the runbook.

7. Reduce exposure in logs, Git and troubleshooting

• Keep real plaintext Secret manifests out of ordinary Git repositories.
• If using encrypted GitOps files, define key custody and the decryption boundary.
• Review debug output, environment dumps and application exception messages.
• Limit shell access to workloads and avoid mounting credentials into unrelated sidecars.
• Prefer short-lived, narrowly scoped credentials where supported.

A secret committed to a repository should be treated as exposed: removing the latest file does not remove copies or history. Revoke or rotate it and investigate its use. Our Jenkins security guide covers related build-system credential risks.

8. Make the review repeatable

For each credential, record its issuer, owner, consuming workload, required permissions, refresh method, revocation path and last tested rotation. Use that record during access reviews and recovery exercises.

A useful acceptance test is a disposable credential that rotates successfully while an unrelated workload is denied access. Also test a failed rotation and a revoked credential. Those cases expose gaps that a successful first deployment can hide.

Kubernetes Secrets: frequently asked questions

Does base64 protect a password?

No. It changes representation, not confidentiality. Encryption, access controls and application handling are separate requirements.

Will every running Pod immediately see a new Secret?

No. Delivery method, update propagation and application reload behaviour all matter. Test the actual consumer.

Does an external store remove Kubernetes RBAC requirements?

No. Protect the controller’s identity and any synchronised Secret, as well as the workload’s access.

Official references

• Kubernetes Secrets concepts and update behaviour
• Good practices for Kubernetes Secrets
• Encrypting confidential data at rest
• External Secrets Operator architecture

Related reading: Docker Swarm Secrets: Create, Use and Rotate Credentials · Kubernetes Intrusion Detection: Where AI and ML Help