Skip to main content

More Info:

Where etcd encryption is used, appropriate providers should be configured.

Risk Level

Medium

Address

Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS EKS
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Manual Steps

  1. Identify the cluster and region
    • On any machine with AWS CLI access, list clusters and pick the target name and region:
  2. Check if KMS encryption is enabled and which key is used
    • On any machine with AWS CLI access, run:
    • Review the output: ensure resources includes "secrets" and that provider.keyArn points to the intended customer-managed KMS key (not just an AWS-managed default, if your policy requires CMKs).
  3. Review the KMS key configuration and key policy
    • On any machine with AWS CLI access, get key details:
    • Confirm the key is customer-managed, enabled, in the correct account, and the key policy allows the EKS cluster’s IAM role (or node roles, per your design) to use it for encryption/decryption.
  4. Decide remediation approach (replacement, recreation, or accept risk)
    • If encryptionConfig is empty, does not include "secrets", or uses an incorrect key:
      • Document that etcd secrets are not protected by the desired CMK.
      • Decide whether to:
        • Recreate the cluster with Secrets Encryption enabled and the correct CMK, then migrate workloads; or
        • Create a new, compliant cluster and gradually cut over; or
        • Accept/temporarily waive the risk with a documented exception.
  5. Implement remediation via cloud/IaC (for new or replacement clusters)
    • For a new or replacement cluster using AWS CLI, specify encryption with your CMK:
    • If using CloudFormation/Terraform, configure the encryptionConfig/encryption_config block with resources = ["secrets"] and provider.keyArn = <KMS_KEY_ARN> and deploy the new cluster.
  6. Verify the final state
    • After creating or migrating to the compliant cluster, re-run:
    • Confirm that resources includes "secrets" and provider.keyArn matches the intended customer-managed KMS CMK.
kubectl cannot configure EKS secrets encryption or modify the kube-apiserver encryption-provider settings; this must be done via the EKS control plane configuration at cluster creation time using the AWS console/CLI/IaC. Refer to the Manual Steps section for how to review current settings and plan remediation (which will typically require recreating the cluster with Secrets Encryption enabled).

How to interpret the output

Run (from any machine with AWS CLI access):
Indicators of a problem for a given cluster:
  • encryptionConfig: [] or printed as []
  • Any provider with:
    • resources: <none> or resources not including secrets
    • keyArn: <none>
    • KMS key state not Enabled
    • KMS KeyManager not CUSTOMER (i.e., not a customer-managed CMK)
This script only reports; remediation requires recreating or reconfiguring the cluster with Secrets Encryption enabled using a customer-managed KMS CMK.

Additional Reading: