Free tools Windows power users keep installed
One-click scans. No signup required.
Kubernetes Secret values are base64-encoded in API representations, not encrypted by that encoding, and Secret objects are stored unencrypted in etcd by default. For production, configure and verify encryption at rest, restrict both direct Secret permissions and indirect access through workload creation, and expose each value only to the containers that need it.
1. Encrypt Secret data at rest—and verify existing records
Configure API-server encryption at rest for the Secret API resource. This protects Kubernetes API data in addition to any encryption applied to etcd or the underlying filesystem; it does not replace those infrastructure protections. See the Kubernetes encryption at rest guide.
- Confirm the API server is configured to encrypt Secrets, and ensure the encryption keys or managed encryption service have appropriate access controls. The cluster operator remains responsible for suitable controls even when a provider manages key use or lifecycle.
- Verify existing Secret objects are encrypted before removing an identity or plaintext fallback. If plaintext records remain when fallback is removed, the API server may no longer be able to retrieve them.
- Encrypt etcd backups and consider full-disk encryption as additional layers of protection; neither substitutes for API-resource encryption.
Base64 is an encoding format, not a confidentiality control. As the Kubernetes project puts it in its Secret good-practices guidance, “Base64 encoding is not an encryption method, it provides no additional confidentiality over plain text.” Treat a base64-encoded manifest as sensitive if it contains a real Secret.
2. Restrict direct Secret access and workload creation
RBAC review must include more than who can run get. Kubernetes documents that list and watch responses can disclose Secret contents, and that permission to create a Pod or other workload in a namespace can provide indirect access to Secrets that workload can mount. See Good practices for Kubernetes Secrets and RBAC good practices.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
- Grant
getonly to identities whose normal component behavior requires it. Keeplistandwatchlimited to the most privileged system components and tightly controlled operators. - For every namespace containing Secrets, review who can create Pods, Deployments, Jobs, and other workload resources—not just who can read Secret objects directly.
- Prefer namespace-scoped Roles and RoleBindings when they meet the access need. Use separate namespaces for different access tiers when doing so creates useful isolation.
- Review Secret access patterns and consider alerts for suspicious activity, such as one user reading many Secrets concurrently. Short-lived credentials can limit the time an exposed credential remains useful.
3. Deliver each Secret only to the containers that need it
Limit exposure at the Pod and container level. Kubernetes checklist guidance favors mounted Secret volumes, preferably memory-backed where appropriate, over giving a Pod’s service account broad API access to Secrets. A mounted file is not automatically safe: applications and permissions still determine who can read or leak the value.
- Mount a Secret only into the Pod that needs it, and make it available only to the specific container that uses it.
- Consider file-based delivery with restrictive permissions. Kubernetes cautions that environment variables may be more prone to leakage through logs and crash dumps; this is a risk distinction, not a guarantee that files cannot leak.
- Ensure applications do not write Secret values to logs or send them to untrusted parties after reading them.
- Do not commit Secret manifests, including base64-encoded manifests, to repositories or share them with people who are not authorized to know the underlying values.
These controls align with the Kubernetes Security Checklist, which also emphasizes that checklists alone do not establish a good security posture and that controls need to be evaluated for the cluster’s circumstances.
Rank #2
4. Decide whether an external Secret store fits your architecture
Native Kubernetes Secret objects and external Secret stores are both possible approaches; Kubernetes documentation does not declare one universally superior. Compare them against your persistence, access, key-custody, delivery, rotation, audit, and operational-ownership requirements.
| Decision area | Native Kubernetes Secret | External store with Kubernetes integration |
|---|---|---|
| Where values are persisted | Secret objects are stored in etcd; they are unencrypted by default unless encryption at rest is configured. Kubernetes Secrets and encryption at rest. | Values are held by an external provider and retrieved for authorized Pods; exact persistence and safeguards depend on the provider. The Kubernetes documentation describes the integration pattern, not provider-specific guarantees. Good practices. |
| Who can retrieve values | RBAC governs direct Secret access, while workload-creation permissions can grant indirect access to mountable Secrets. RBAC good practices. | Access depends on the external provider’s controls as well as which Pods are authorized to receive mounted values. Provider-specific details are not established by Kubernetes’ general guidance. |
| Encryption and key custody | Configure API-server encryption at rest and protect keys; also protect etcd backups and underlying storage. | Review the provider’s encryption and key-custody controls. Kubernetes does not specify a universal provider configuration. |
| How values reach containers | Kubernetes can deliver Secrets through mounted volumes or environment variables; scope delivery to the containers that need each value. | The Secrets Store CSI Driver is a DaemonSet that lets kubelet retrieve data from external providers and mount it into authorized Pods. Provider projects are third-party, and the Kubernetes project does not assume responsibility for them. Good practices. |
| Rotation and credential lifetime | Set operational processes for credential rotation and removal when credentials are no longer needed. | Rotation behavior depends on the provider and integration; verify it against your requirements rather than assuming it is automatic. |
| Audit visibility and ownership | Use cluster audit controls and protect records; cluster operators own Kubernetes configuration and operations. | Determine which events are visible in provider and cluster audit records, and assign responsibility for provider and integration operations. |
The CSI Driver is an integration option, not an endorsement of any provider. Kubernetes documentation does not establish compatibility or security properties for every third-party provider, so evaluate the specific implementation you plan to operate.
Quick Recap
Rank #4
5. Harden service-account tokens and audit records
- Do not mount service-account tokens into Pods that do not need Kubernetes API access. Prefer bound, time-limited service-account tokens over non-expiring tokens; the Kubernetes checklist states this guidance applies to Kubernetes v1.22 and later. See Security Checklist.
- Enable audit logging according to the cluster’s needs and protect the resulting records. Kubernetes describes auditing as a chronological security-relevant record; cluster guidance recommends archiving audit files on a secure server. See Auditing and Securing a Cluster.
- Rotate infrastructure credentials and revoke or remove bootstrap-token authorization after node setup. Shorter credential lifetimes reduce the period in which a compromised credential can be used. See Securing a Cluster.
Production review checklist
- Storage: Confirm API-server encryption at rest covers Secrets; verify existing objects are encrypted before removing plaintext fallback; protect keys, etcd backups, and underlying storage.
- Authorization: Review
get,list, andwatchpermissions, plus workload-creation rights in each namespace containing Secrets. - Delivery: Scope each Secret to the required Pod and container; choose a delivery method with its leakage risks in mind.
- Application behavior: Check that Secret values are not logged or sent to untrusted parties, and do not share encoded manifests as if encoding made them safe.
- Operations: Assess whether an external store fits your key custody, rotation, audit, and ownership requirements; restrict unnecessary token mounts; protect audit records; and rotate or revoke credentials as appropriate.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
