Profile Applicability:
Level 1
Description:
In Kubernetes, Secrets are used to store and manage sensitive information such as passwords, OAuth tokens, SSH keys, and other private data. By default, Kubernetes encrypts Secrets at rest using a Kubernetes-managed key. However, for additional security and compliance, organizations may need to encrypt these secrets using their own Customer Master Keys (CMKs) managed via AWS Key Management Service (KMS) or another cloud provider's KMS.
Encrypting Kubernetes Secrets using CMKs allows organizations to maintain control over the encryption process and key lifecycle, ensuring that secrets are securely stored in accordance with internal policies and regulatory requirements.
Rationale:
Encrypting Kubernetes Secrets with CMKs provides enhanced security by:
Control Over Encryption Keys: Organizations have full control over the keys used to encrypt the secrets, including rotating, disabling, or auditing key usage.
Compliance: Helps meet security standards and compliance requirements such as SOC 2, HIPAA, PCI-DSS, and ISO 27001.
Increased Security: CMK encryption ensures that sensitive data is securely stored and only accessible by authorized entities, reducing the risk of unauthorized access or data breaches.
Key Management: Integration with KMS or other key management services ensures that encryption keys are managed securely and can be rotated on a regular basis.
Impact:
Pros:
Improved Security: Secrets are encrypted with CMKs, ensuring strong data protection and confidentiality.
Compliance: Enables organizations to meet regulatory and compliance requirements for handling sensitive information.
Key Control: Full control over the encryption key lifecycle, including rotation, deactivation, and auditing of key usage.
Reduced Risk: Encrypting Kubernetes Secrets using CMKs ensures that sensitive data is less vulnerable to unauthorized access.
Cons:
Increased Complexity: Implementing CMK-based encryption requires additional setup and management, including configuring KMS and managing encryption keys.
Potential Cost: KMS and CMK usage incur costs, particularly with large numbers of keys or frequent key rotations.
Performance Overhead: Encrypting and decrypting secrets using CMKs may add slight overhead to secret retrieval operations.
Default Value:
By default, Kubernetes encrypts Secrets using the built-in Kubernetes-managed keys. To use Customer Master Keys (CMKs) for encryption, you need to explicitly configure this during cluster setup or by modifying the cluster's encryption settings.
Pre-requisite:
AWS IAM Permissions:
kms:CreateKey
kms:DescribeKey
kms:GenerateDataKey
kms:Decrypt
eks:UpdateClusterConfig
AWS CLI installed and configured.
KMS Key created and available in the AWS KMS service.
Kubernetes Cluster running with appropriate permissions to configure encryption.
Familiarity with Kubernetes Secrets, KMS, and EKS cluster configurations.
Remediation
Test Plan:
Using AWS Console (EKS):
Sign in to the AWS Management Console.
Navigate to Amazon EKS under Services.
In the EKS Dashboard, select the Kubernetes cluster to check or modify its encryption settings.
Check the Kubernetes Secrets Encryption section under Cluster Configuration.
If Secrets Encryption is not enabled with CMKs, enable it by choosing the Customer Master Key (CMK) to be used for encryption.
Ensure that the appropriate KMS key is selected for encryption.
After applying, verify that Secrets in your cluster are encrypted with CMKs using kubectl.
Using kubectl (CLI):
To check if Kubernetes Secrets are using CMK encryption, run:
kubectl get secrets --namespace=<namespace> -o json | jq '.items[].data'
Ensure that the Secrets are encrypted. If they are not, you will need to configure CMK encryption for your Kubernetes cluster.
To enable CMK-based encryption for Secrets in your cluster, use:
kubectl apply -f <path-to-encryption-config>.yaml
Verify the encryption configuration by describing the cluster:
aws eks describe-cluster --name <cluster-name> --query "cluster.encryptionConfig"
Implementation Steps:
Using AWS Console (EKS):
Log in to the AWS Management Console and navigate to EKS.
Select the desired EKS cluster and go to the Configuration section.
Under Cluster Encryption Configuration, click on Edit.
Select Customer Managed Keys (CMK) as the encryption option.
Choose or create a KMS CMK for encrypting Secrets.
Save changes to enable CMK-based encryption for Kubernetes Secrets.
Verify that the cluster is now using CMK encryption for storing secrets.
Using AWS CLI:
Create or select an existing KMS Key for encryption. To create a new key:
aws kms create-key --description "Kubernetes secrets encryption" --key-usage ENCRYPT_DECRYPT
Update your EKS cluster to use CMKs for encrypting Secrets:
aws eks update-cluster-config --name <cluster-name> --encryption-config '{"resources":["secrets"],"provider":{"keyArn":"arn:aws:kms:<region>:<account-id>:key/<key-id>"}}'Verify the encryption configuration:
aws eks describe-cluster --name <cluster-name> --query "cluster.encryptionConfig"
Backout Plan:
Console Process
Create a CMK:
Go to the AWS KMS Console and create a new key or use an existing one.
Update API Server:
Edit the kube-apiserver settings to include an encryption configuration file.
Add Encryption Config:
Create a file (encryption-config.yaml) and specify the CMK for encrypting secrets.
Restart API Server:
Save changes and restart the kube-apiserver.
CLI Process
Create CMK:
aws kms create-key --description "Kubernetes Secrets Encryption"
Add Encryption File:
Create an encryption-config.yaml file with the CMK key.
Restart API Server:
Update and restart the kube-apiserver with the encryption configuration.
Note:
Key Rotation: Set up automatic KMS key rotation for your CMKs to ensure that encryption keys are regularly rotated to enhance security.
Audit Logs: Enable CloudTrail and CloudWatch Logs to monitor KMS key usage and audit the access to Secrets in the cluster.
Testing: Before enabling CMK encryption in production, test it in a development or staging environment to avoid application disruptions.