Enable envelope encryption in Amazon EKS by associating the cluster with a customer managed KMS key for Kubernetes secrets. This causes the control plane to encrypt secret data before storing it in etcd. Check that the key policy permits the cluster to use the key, and rotate the key only after confirming workloads can still read existing secrets.
What changes when you enable EKS envelope encryption for Kubernetes secrets?
envelope encryption changes where protection happens and who controls the key. In Amazon EKS, the control plane encrypts secret data before it is written to etcd, but the practical security boundary is the customer managed KMS key and its policy. That means the operational question is not just “is encryption on?” but “can the cluster still use the key safely over time?”
For practitioners, the important effect is reduced exposure of secret material in the control plane data store and a clearer separation between cluster operations and key custody. That makes the configuration useful even when workloads still depend on Kubernetes Secrets, because the storage layer is no longer the place where cleartext secret values live.
How do you enable it without breaking the cluster?
Enable the feature by associating the cluster with a customer managed KMS key, then verify that the key policy allows the EKS control plane to use that key for secret encryption and decryption. The setup is straightforward, but the policy detail is where most failures happen: if the control plane cannot access the key, secrets may not be readable after rotation or during recovery.
That is why the implementation sequence matters. Treat the KMS policy, cluster association and secret-read path as one control set. If you rotate the key, confirm that workloads can still read existing secrets before you rely on the new key in production. For broader secret handling patterns, the Secrets Management Guide is the right companion to this configuration because it covers rotation, centralisation and moving away from static secret handling.
For Kubernetes-specific hardening, Kubernetes Security Guide is the broader cluster baseline, while Kubernetes NHI Security Guide is the more specific path when you also need to govern service accounts, tokens, Secrets and workload identity together.
What should you check after encryption is enabled?
After you switch it on, confirm three things: the cluster is actually associated with the intended customer managed key, the key policy permits the control plane to use it, and existing workloads can still read previously stored secrets. That last check is important because encryption changes storage behaviour, not application logic, so a failure may surface only when a pod restarts or a controller tries to re-read a Secret.
You should also decide whether secret rotation is part of the change window or a later maintenance task. If the key change is combined with workload rollout, testing becomes easier because any read failure is exposed immediately. If not, keep a rollback path ready so you can restore access to secret data without guessing whether the failure is policy, permissions or stale application state.
Risk and Threat Considerations
Secrets stored in Kubernetes are often operationally sensitive even when they are not meant to be long-lived. The main risk is not that encryption exists, but that organisations assume the presence of encryption means secret exposure is solved, while the real failure mode is usually key-policy drift, weak key custody or untested rotation.
Failure mechanism: If the KMS key policy does not allow the EKS control plane to use the key, or if a rotation changes access unexpectedly, the cluster can lose the ability to read existing secrets even though the data remains encrypted.
Impact: Workloads may fail to start, controllers may lose access to credentials or configuration, and recovery can become slower because the failure looks like an application outage even though the underlying issue is key access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle control for secrets and credentials protected by the cluster key |
| SC-28 — Protection of Information at Rest | Directly applies to encrypting Kubernetes secret data stored in etcd | |
| AC-6 — Least Privilege | Key policy should grant only the EKS control plane the access it needs | |
| Recommendation — Validate secret rotation and revocation processes before changing key custody. Apply at-rest encryption to stored secret material and verify it remains protected. Restrict KMS use so only the cluster path can decrypt secret data. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Encryption of Kubernetes secrets is a cryptographic control over stored data |
| Recommendation — Define and operate cryptographic key usage rules for stored secrets. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Encrypting secrets at rest is a core data protection safeguard |
| Recommendation — Protect sensitive data at rest with approved encryption and key controls. | ||
Practitioner Guidance
What to verify: Confirm the exact KMS key ARN used by the cluster, the policy path that grants EKS usage, and the behaviour of at least one real workload after a key rotation or re-association change. Do not rely on the console state alone.
Decision rule: If the secret can affect production availability or authentication, treat read-after-rotation testing as mandatory before the change is considered complete. If the workload cannot be validated, delay the key change rather than assuming encryption-only changes are low risk.
Practitioner takeaway: Envelope encryption is a storage-control improvement, not a finish line; the control is only trustworthy when key policy, cluster access and secret-read validation are all proven together.
Related resources from NHI Mgmt Group
- What is the difference between envelope encryption and storing secrets directly in Kubernetes?
- What breaks when Kubernetes secrets are treated as fully protected after EKS encryption is enabled?
- How do you enable Amazon GuardDuty protection plans such as S3, EKS and runtime monitoring?
- How do you enable control plane logging in Amazon EKS?