Container Compute Service:Sensitive data encryption

Sensitive data in Kubernetes

Kubernetes provides two types of objects for data storage: Secret and ConfigMap. You can mount Secrets and ConfigMaps to pods. This way, pods can load and use the data stored in Secrets and ConfigMaps. Secrets are used to store sensitive information, such as database passwords, application certificates, and tokens. ConfigMaps are used to store the configurations of applications, such as startup parameters. To store sensitive data in Kubernetes clusters, we recommend that you follow the Kubernetes best practices and use Secrets instead of ConfigMaps.

The following list describes the terms related to Secrets:

• When users send Secret creation requests to the API server of a cluster, the API server creates and saves Secrets as Base64-encoded plaintext in the etcd of the cluster.

• Users that have role-based access control (RBAC) permissions can access the API server to retrieve the plaintext data in the Secrets in the cluster.

• Secrets can be mounted to pods as files or environment variables.

• After you mount a Secret to a pod, the sensitive information in the Secret is stored in the temporary file system (tmpfs) of the node.

As the vessel that stores the sensitive information of applications in Kubernetes, Secrets cannot ensure the security of the sensitive information. Developers and security engineers may encounter the following issues when using Secrets:

• Developers and security engineers need to decide on a security solution to manage and store sensitive information before they deploy applications.

• How do developers and security engineers keep the reading, writing, and transmission of keys safe without compromising the loading and use of keys?

• What security solutions do cloud service providers offer to ensure the security of sensitive information?

To resolve the preceding issues, we recommend that you choose the security solutions for sensitive information management provided by cloud service providers and the security best practices for sensitive information management intended for developers.

Security solutions

Based on the shared responsibility model for cloud security, cloud service providers are responsible for ensuring the security of configurations and sensitive information on the control plane side and providing security solutions for sensitive information management. This helps you enhance the security of sensitive information. We recommend that you use key management services provided by cloud service providers to protect your sensitive information.

Cloud service providers usually provide key management services. For example, Alibaba Cloud Key Management Service (KMS) provides professional key lifecycle management and data encryption/decryption services to help you simplify the procedure of application system integration. For more information about KMS, see What is KMS?

Data breaches may occur during sensitive information hard-coding across the pipeline of application system development and deployment. To avoid hard-coding, you can use key management services in the cloud to read and write sensitive information throughout the pipeline of application development, testing, and building. Key management services also support automatic key rotation, which reduces the risk of sensitive data breaches and helps enterprises meet security compliance requirements.

Security best practices

Based on the security solutions for sensitive information management provided by cloud service providers, developers and O&M engineers need to ensure the security of the sensitive information on their side. The following sections describe the recommended security best practices for sensitive information management on the business side.

• RBAC

  Secret is a basic model of Kubernetes. RBAC on Secrets is fundamental but essential to data security. You need to follow the least privilege principle during daily cluster development and maintenance to avoid issuing credentials that provide read and write permissions on global Secrets. You also need to revoke cluster credentials that may be disclosed.

• Supply chain security reinforcement

  Sensitive information is retrieved and used throughout the lifecycle of application artifacts. Therefore, enterprises must improve their awareness of sensitive information security and further regulate the use of sensitive information. Sensitive information hard-coding must be prohibited in application templates, code repositories, and configuration files. Key management services are required to centrally manage keys throughout the artifact supply chain. In addition, the internal security management and O&M teams of enterprises need to develop an automatic security inspection mechanism to prevent data breaches in each component of the supply chain.

• Auditing and monitoring

  In enterprise application systems, all operations related to the reading, writing, use, and lifecycle management of keys must be audited and logged to ensure that operations on sensitive data are traceable. In addition, a runtime monitoring mechanism is required, such as alert rules for suspicious read and write operations on sensitive data and alert rules for breaches of the AccessKey pairs of Alibaba Cloud accounts. This way, logs and alerts can be generated to help O&M engineers quickly handle sensitive data breaches, assess impacts, and minimize financial losses.

• Use temporary tokens, periodically rotate keys, or configure automatic key rotation

  Do not use static credentials such as AccessKey pairs in application systems. We recommend that you use temporary tokens. When an attacker breaches a temporary token, the attacker can exploit the token only within a limited time. This minimizes the chances of the attacker to expand their attack and provides an opportunity for the system O&M engineer to patch the system vulnerability. The vulnerability patching work would be more complicated if long-term credentials are disclosed. We recommend that you periodically rotate keys or enable the automatic key rotation feature when managing the keys stored in KMS to enhance application security.

• Use KMS to protect sensitive information in Kubernetes clusters

  If you want to store sensitive information in Kubernetes Secrets and ConfigMaps, we recommend that you use KMS to encrypt the sensitive information. You can also use KMS to decrypt the sensitive information based on your business requirements.

• Use envelope encryption to protect the last key

  Unlike directly encrypting plaintext by using the keys stored in a key management service in the cloud, envelope encryption allows you to use a separate key and then pass the encrypted key through an envelope. With the help of envelope encryption, sensitive data can be encrypted and decrypted offline on the business side. This helps avoid uploading your keys to the cloud and resolves the trust issue arising from cloud computing. In offline computing scenarios where large amounts of data need to be encrypted and decrypted, envelope encryption also helps save the IT spending on data transmission to the cloud and cloud computing, and improves the overall performance. For more information about envelope encryption, see Use envelope encryption to encrypt and decrypt local data.

  The Last Key is a common issue in key management service-based encryption and decryption scenarios. Envelope encryption requires you to store a Key Encryption Key (KEK) in the cloud to encrypt and decrypt the Content Encryption Key (CEK). To protect the KEK based on the least privilege principle in most scenarios, you can use an access control service such as Alibaba Cloud Resource Access Management (RAM). On the application side, you need to limit access to the RAM credentials that are used to retrieve the KEK from the cloud. You may also need to use automatically rotated temporary tokens to protect the RAM credentials. We recommend that you use an isolation mechanism similar to RRSA to limit applications from accessing the RAM credentials.