Kubernetes Secrets checklist: what admins and developers each own

Kubernetes Secret safety is split. Cluster administrators own encryption at rest, RBAC and etcd. Developers own which containers see a Secret, what the app does with the value, and what ends up in manifests. This checklist follows the good practices page for each group.

Cluster administrators

1. Encrypt Secret data at rest. The docs say Secrets are stored unencrypted in etcd by default, and that you should configure encryption. See whether Secrets are encrypted by default.
2. Restrict watch and list on Secrets to the most privileged, system-level components. Grant get only when a component needs it.
3. Restrict get, watch and list for humans. Only allow cluster administrators to access etcd, including read-only access.
4. Remember that list implicitly returns contents, and that creating a pod that uses a Secret reveals its value.
5. Use short-lived Secrets where you can.
6. Add audit rules that alert on events such as one user reading many Secrets at once.
7. Use separate namespaces to isolate access to mounted secrets.
8. If you run several etcd instances, encrypt communication between them with TLS, and consider wiping or shredding etcd storage when it is retired.
9. Consider an external Secret store. The docs mention third party providers and the Secrets Store CSI driver, which lets the kubelet fetch Secrets from external stores and mount them as a volume into authorized pods.

Developers

1. In a pod with several containers, give the Secret volume mount or environment variable only to the container that needs it.
2. Protect the value after reading it. The docs say applications must avoid logging secret data in the clear or sending it to an untrusted party.
3. Do not share or commit Secret manifests. Sharing the file makes the secret available to everyone who can read it.
4. Remember base64 is not encryption. It provides no extra confidentiality over plain text.
5. Do not paste real values into issues, chat or screenshots.

Where the two groups meet

The handoff is the manifest. Developers should never need the production value in Git. Administrators should provide a path, such as an external store reference, so values never appear in a repository. A Secret that was committed once stays in history, so rotate it, not just delete the file.

Click through it at your own pace, or open it full screen.

A five minute test

Pick one Secret in production. Answer: who can read it through RBAC, who can read it by creating a pod, whether it is encrypted in etcd, how often it rotates, and whether any container that does not need it can see it. Any answer of "not sure" is your next task.

Where Safeguard fits

Safeguard can scan repositories for hard-coded secrets and apply policies and gates in pull requests, which covers the developer half before values reach a cluster. The cluster side stays with Kubernetes configuration.

Quick check

Sources

• Good practices for Kubernetes Secrets, Kubernetes docs
• Role Based Access Control Good Practices, Kubernetes docs

Last reviewed: 19 October 2026.