Container Service for Kubernetes (ACK) lets you enable encryption at rest for Kubernetes Secrets with a customer master key (CMK) from Key Management Service (KMS). This feature secures your cluster's sensitive data through a simple configuration.
Use cases
Kubernetes manages sensitive information required for communication across different products, services, and modules. This information includes passwords, certificates, credentials, and access keys. Kubernetes uses Secret objects to store and manage this sensitive data for the cluster system and its applications. These Secrets are stored and replicated in the cluster's etcd.
For example, a new Kubernetes cluster with no workloads still contains about 50 default Secrets. Leaking any of these Secrets poses a significant risk to your cluster, applications, and business operations. Therefore, it is critical to protect the credentials stored in your cluster against potential security threats.
How it works
In an ACK Pro managed cluster, you can use a customer master key (CMK) created in Key Management Service (KMS) to encrypt Kubernetes Secrets. The encryption process is based on the KMS Encryption Provider mechanism from Kubernetes and uses envelope encryption to automatically encrypt and decrypt Kubernetes Secret keys stored in etcd. For more information about envelope encryption, see Use envelope encryption with KMS to encrypt and decrypt data locally. The encryption and decryption process for Kubernetes Secret keys is as follows:
When a Secret is stored by using the Kubernetes API, the API server first encrypts the data with a randomly generated data key. The API server then encrypts this data key with your specified CMK from KMS, which creates an encrypted data key that is stored in etcd.
When a Secret is retrieved, the API server calls the KMS Decrypt API to decrypt the encrypted data key. The API server then uses the resulting plaintext key to decrypt the Secret data and returns it to the client.
Prerequisites
The Alibaba Cloud account used to manage your Kubernetes clusters must have the AliyunCSManagedSecurityRole role. If the role is not granted, you are prompted to grant it when you enable encryption at rest for a new or existing ACK Pro cluster.
If you log on as a RAM user, ensure the RAM user has the AliyunKMSCryptoAdminAccess permission. For more information, see Manage RAM user permissions.
Ensure that you have created a customer master key (CMK) in the KMS console. For more information, see Create a key.
NoteOnly CMKs of the Aliyun_AES_256 type are supported.
Enable Secret encryption on a new cluster
Log on to the Container Service Management Console.
On the Cluster List page, click Cluster Templates in the upper-right corner.
In the Select Cluster Template dialog box, select Managed Kubernetes Cluster Pro and click Create.
On the ACK Managed Cluster tab, find the Secret Encryption section, select the Select Key checkbox, and then select a key ID from the drop-down list.
Configure the other parameters as prompted.
For more information, see Create an ACK Pro cluster.
Enable Secret encryption on an existing cluster
On the Clusters page, click the name of the target ACK Pro cluster.
Click the Basic Information tab and in the Basic Information section, turn on the Secret Encryption switch.
In the Secret Encryption dialog box, select a key ID from the drop-down list and click OK.
After the cluster status changes from Updating to Running, the encryption at rest feature is enabled.
Verify the result
You can verify that encryption at rest for Secrets is enabled in the ActionTrail console. If you find encryption and decryption events associated with the AliyunCSManagedSecurityRole on the Event Query page, the feature is active. You can use ActionTrail to audit all API calls to KMS.