AWSOverview
Encrypt Kubernetes secrets, stored in etcd, using secrets encryption feature during Amazon EKS cluster creation.
Rationale
Kubernetes can store secrets that pods can access via a mounted volume. Today, Kubernetes secrets are stored with Base64 encoding, but encrypting is the recommended approach. Amazon EKS clusters version 1.13 and higher support the capability of encrypting your Kubernetes secrets using AWS Key Management Service (KMS) Customer Managed Keys (CMK). The only requirement is to enable the encryption provider support during EKS cluster creation. Use AWS Key Management Service (KMS) keys to provide envelope encryption of Kubernetes secrets stored in Amazon EKS. Implementing envelope encryption is considered a security best practice for applications that store sensitive data and is part of a defense in depth security strategy. Application-layer Secrets Encryption provides an additional layer of security for sensitive data, such as user defined Secrets and Secrets required for the operation of the cluster, such as service account keys, which are all stored in etcd. Using this functionality, you can use a key, that you manage in AWS KMS, to encrypt data at the application layer. This protects against attackers in the event that they manage to gain access to etcd.
Default value
By default secrets created using the Kubernetes API are stored in tmpfs and are encrypted at rest.
Remediation guidance
This process can only be performed during Cluster Creation. Enable 'Secrets Encryption' during Amazon EKS cluster creation as described in the links within the 'References' section.
References
Multiple Remediation Paths
AWS
SERVICE-WIDE (RECOMMENDED when many resources are affected): Deploy centralized guardrails and remediation using AWS Config Conformance Packs and (if applicable) AWS Organizations SCPs.
aws configservice put-organization-conformance-pack --organization-conformance-pack-name <pack-name> --template-s3-uri s3://<bucket>/<template>.yaml
ASSET-LEVEL: Apply the resource-specific remediation steps above to only the affected assets.
PREVENTIVE: Add CI/CD policy checks (CloudFormation/Terraform validation) before deployment to prevent recurrence.
References for Service-Wide Patterns
- AWS Config Conformance Packs: https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html
- AWS Organizations SCP examples: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- AWS: deploy/adjust organization conformance packs and policy guardrails.
aws configservice put-organization-conformance-pack --organization-conformance-pack-name <pack-name> --template-s3-uri s3://<bucket>/<template>.yaml
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
EKS Clusters without secrets encryption
Connectors
Covered asset types
Expected check: eq []
{
eksClusters(where:{
OR:[{encryptionConfig: null}, {encryptionConfig: {providerKeyARN: ""}}]
}) {
...AssetFragment
}
}
