Key management and cryptographic primitives
Constellation protects and isolates your cluster and workloads. To that end, cryptography is the foundation that ensures the confidentiality and integrity of all components. Evaluating the security and compliance of Constellation requires a precise understanding of the cryptographic primitives and keys used. The following gives an overview of the architecture and explains the technical details.
Confidential VMs
Confidential VM (CVM) technology comes with hardware and software components for memory encryption, isolation, and remote attestation. For details on the implementations and cryptographic soundness please refer to the hardware vendors' documentation and advisories.
Master secret
The master secret is the cryptographic material used for deriving the clusterID and the key encryption key (KEK) for storage encryption. It's generated during the bootstrapping of a Constellation cluster. It can either be managed by Constellation or an external key management system In case of recovery, the master secret allows to decrypt the state and recover a Constellation cluster.
Cluster identity
The identity of a Constellation cluster consists of two parts:
- baseID: The identity of a valid and measured, uninitialized Constellation node
- clusterID: The identity unique to a single initialized Constellation cluster
Using the CVM's attestation mechanism and measured boot up to the read-only root filesystem guarantees baseID. The clusterID is derived from the master secret and a cryptographically random salt. It's unique for every Constellation cluster. The remote attestation statement of a Constellation cluster combines baseID and clusterID for a verifiable, unspoofable, unique identity.
Network encryption
Constellation encrypts all cluster network communication using the container network interface (CNI). See network encryption for more details.
The Cilium agent running on each node establishes a secure WireGuard tunnel between it and all other known nodes in the cluster. Each node creates its own Curve25519 encryption key pair and distributes its public key via Kubernetes. A node uses another node's public key to decrypt and encrypt traffic from and to Cilium-managed endpoints running on that node. Connections are always encrypted peer-to-peer using ChaCha20 with Poly1305. WireGuard implements forward secrecy with key rotation every 2 minutes. Cilium supports key rotation for the long-term node keys via Kubernetes secrets.
Storage encryption
Constellation supports transparent encryption of persistent storage. The Linux kernel's device mapper-based encryption features are used to encrypt the data on the block storage level. Currently, the following primitives are used for block storage encryption:
Adding primitives for integrity protection in the CVM attacker model are under active development and will be available in a future version of Constellation. See encrypted storage for more details.
As a cluster administrator, when creating a cluster, you can use the Constellation installation program to select one of the following methods for key management:
- Constellation-managed key management
- User-managed key management
Constellation-managed key management
Key material and key derivation
During the creation of a Constellation cluster, the cluster's master secret is used to derive a KEK. This means creating two clusters with the same master secret will yield the same KEK. Any data encryption key (DEK) is derived from the KEK via HKDF. Note that the master secret is recommended to be unique for every cluster and shouldn't be reused (except in case of recovering a cluster).
State and storage
The KEK is derived from the master secret during the initialization. Subsequently, all other key material is derived from the KEK. Given the same KEK, any DEK can be derived deterministically from a given identifier. Hence, there is no need to store DEKs. They can be derived on demand. After the KEK was derived, it's stored in memory only and never leaves the CVM context.
Availability
Constellation-managed key management has the same availability as the underlying Kubernetes cluster. Therefore, the KEK is stored in the distributed Kubernetes etcd storage to allow for unexpected but non-fatal (control-plane) node failure. The etcd storage is backed by the encrypted and integrity protected state disk of the nodes.
Recovery
Constellation clusters can be recovered in the event of a disaster, even when all node machines have been stopped and need to be rebooted. For details on the process see the recovery workflow.
User-managed key management
User-managed key management is under active development and will be available soon. In scenarios where constellation-managed key management isn't an option, this mode allows you to keep full control of your keys. For example, compliance requirements may force you to keep your KEKs in an on-prem key management system (KMS).
During the creation of a Constellation cluster, you specify a KEK present in a remote KMS. This follows the common scheme of "bring your own key" (BYOK). Constellation will support several KMSs for managing the storage and access of your KEK. Initially, it will support the following KMSs:
Storing the keys in Cloud KMS of AWS, Azure, or GCP binds the key usage to the particular cloud identity access management (IAM). In the future, Constellation will support remote attestation-based access policies for Cloud KMS once available. Note that using a Cloud KMS limits the isolation and protection to the guarantees of the particular offering.
KMIP support allows you to use your KMIP-compatible on-prem KMS and keep full control over your keys. This follows the common scheme of "hold your own key" (HYOK).
The KEK is used to encrypt per-data "data encryption keys" (DEKs). DEKs are generated to encrypt your data before storing it on persistent storage. After being encrypted by the KEK, the DEKs are stored on dedicated cloud storage for persistence. Currently, Constellation supports the following cloud storage options:
The DEKs are only present in plaintext form in the encrypted main memory of the CVMs. Similarly, the cryptographic operations for encrypting data before writing it to persistent storage are performed in the context of the CVMs.
Recovery and migration
In the case of a disaster, the KEK can be used to decrypt the DEKs locally and subsequently use them to decrypt and retrieve the data. In case of migration, configuring the same KEK will provide seamless migration of data. Thus, only the DEK storage needs to be transferred to the new cluster alongside the encrypted data for seamless migration.