4.6 KiB
Encrypted persistent storage
Confidential VMs provide runtime memory encryption to protect data in use. In the context of Kubernetes, this is sufficient for the confidentiality and integrity of stateless services. Consider a front-end web server, for example, that keeps all connection information cached in main memory. No sensitive data is ever written to an insecure medium. However, many real-world applications need some form of state or data-lake service that's connected to a persistent storage device and requires encryption at rest. As described in Use persistent storage, cloud service providers (CSPs) use the container storage interface (CSI) to make their storage solutions available to Kubernetes workloads. These CSI storage solutions often support some sort of encryption. For example, Google Cloud encrypts data at rest by default, without any action required by the customer.
Cloud provider-managed encryption
CSP-managed storage solutions encrypt the data in the cloud backend before writing it physically to disk. In the context of confidential computing and Constellation, the CSP and its managed services aren't trusted. Hence, cloud provider-managed encryption protects your data from offline hardware access to physical storage devices. It doesn't protect it from anyone with infrastructure-level access to the storage backend or a malicious insider in the cloud platform. Even with "bring your own key" or similar concepts, the CSP performs the encryption process with access to the keys and plaintext data.
In the security model of Constellation, securing persistent storage and thereby data at rest requires that all cryptographic operations are performed inside a trusted execution environment. Consequently, using CSP-managed encryption of persistent storage usually isn't an option.
Constellation-managed encryption
Constellation provides CSI drivers for storage solutions in all major clouds with built-in encryption support. Block storage provisioned by the CSP is mapped using the dm-crypt, and optionally the dm-integrity, kernel modules, before it's formatted and accessed by the Kubernetes workloads. All cryptographic operations happen inside the trusted environment of the confidential Constellation node.
Note that for integrity-protected disks, volume expansion isn't supported.
By default the driver uses data encryption keys (DEKs) issued by the Constellation KeyService. The DEKs are in turn derived from the Constellation's key encryption key (KEK), which is directly derived from the master secret. This is the recommended mode of operation, and also requires the least amount of setup by the cluster administrator.
Alternatively, the driver can be configured to use a key management system to store and access KEKs and DEKs.
Refer to keys and cryptography for more details on key management in Constellation.
Once deployed and configured, the CSI driver ensures transparent encryption and integrity of all persistent volumes provisioned via its storage class. Data at rest is secured without any additional actions required by the developer.
Cryptographic algorithms
This section gives an overview of the libraries, cryptographic algorithms, and their configurations, used in Constellation's CSI drivers.
dm-crypt
To interact with the dm-crypt kernel module, Constellation uses libcryptsetup. New devices are formatted as LUKS2 partitions with a sector size of 4096 bytes. The used key derivation function is Argon2id with the recommended parameters for memory-constrained environments of 3 iterations and 64 MiB of memory, utilizing 4 parallel threads. For encryption Constellation uses AES in XTS-Plain64. The key size is 512 bit.
dm-integrity
To interact with the dm-integrity kernel module, Constellation uses libcryptsetup. When enabled, the used data integrity algorithm is HMAC with SHA256 as the hash function. The tag size is 32 Bytes.