Creating Kubernetes Secrets: choose the source and rotation model

Your application needs a database password or API token, and you need to supply it without baking it into the container image or committing it to Git. A Kubernetes Secret holds values that a Pod can receive as files or environment variables. It is one part of credential delivery, not a complete system for generating, protecting and replacing credentials.

First choose where the authoritative value lives. An external secret store can manage it outside Kubernetes; a controller can then copy the permitted value into the cluster. Alternatively, an approved deployment tool can decrypt an encrypted configuration file. For some cloud APIs, workload identity can provide temporary credentials without distributing a permanent key.

This is a guide to creating and supplying secrets, not a recommendation for an identified product named “Kubernetes Secret Creator.” The original article at this address was not recovered.

Choose where the credential is managed

For an externally managed credential, an operator such as External Secrets can reconcile selected values into a Kubernetes Secret. For encrypted values stored in Git, evaluate the key ownership and recovery process of tools such as SOPS or Sealed Secrets. For short-lived cloud access, workload identity may remove the need to distribute a static key at all. These patterns solve different problems.

Protect creation and consumption

1. Grant the generating or synchronizing identity only the permissions it needs. Review namespace boundaries and who can create workloads that mount a Secret.
2. Keep plaintext values out of chart values committed to Git, shell history, build logs and support screenshots. Base64 encoding does not encrypt the value.
3. Review encryption at rest and access to the Kubernetes API, including backup copies and administrative access.
4. Expose only the required keys to each workload and avoid sharing a broad credential across unrelated applications.

Test rotation rather than assuming it

Change a harmless test credential, observe when the delivery object updates, and verify when the application actually begins using the new value. A process that reads a value only at startup may need a controlled restart. Coordinate old and new credentials if the provider supports an overlap period, then revoke the old credential after consumers move.

Failure and recovery

Document the outcome when the external provider is unavailable, the controller loses authorization or a decryption key is lost. Test recovery without putting live secrets into the test report. Retain a route to restore the source of truth; restoring a Kubernetes object alone may restore an already-revoked credential.

See the secret-management comparison to choose a delivery model. This page intentionally provides no credential-handling command that would encourage entering a live secret into a terminal transcript.