Git-Mirrors/constellation
1
0
Fork 0
mirror of https://github.com/edgelesssys/constellation.git synced 2024-12-24 23:19:39 -05:00
Code Issues Packages Projects Releases Wiki Activity

rfc: add recovery section to eKMS rfc (#919)

Browse Source 
This new section describes how recovery currently depends on
the mastersecret and how that will change.

Co-authored-by: Daniel Weiße <dw@edgeless.systems>
This commit is contained in:
Otto Bittner 2023-01-10 11:36:11 +01:00 committed by GitHub
parent 78fd2abc5f
commit 43afb86e33
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 21 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
rfc/external-kms.md
View File

@ -30,6 +30,27 @@ It's designed to support different (cloud) KMS services as backend.
Currently, only the ClusterKMS backend is used, which uses the master secret from the Kubernetes secrets to derive the DEKs.
The clients of the CKMS are the join-service and the CSI drivers.
### Recovery
When a node boots, the disk-mapper will setup the encrypted state disk during initramfs.
To decrypt an already existing disks, the disk-mapper will ask all available joinservice instances for a decryption key for it's current disk UUID.
In case there is no join-service instance that can provide the decryption key, manual recovery becomes necessary.
To enable manual recovery the disk-mapper starts a recovery server.
The recovery server waits for a `recover` gRPC call.
During a `recover` call the CLI will attest the measurements of the node.
After successful attestation the CLI will provide a disk decryption key and measurement secret for the given disk UUID.
The measurement secret, together with a measurement salt (not secret) is used to derive the clusterID.
*Changes for eKMS; regarding disk decryption:*
* Recovery server accepts one KMS URI and one storage URI instead of a masterSecret.
* For eKMS backends the two URIs can be used directly to request new DEKs.
* For the cKMS backend the KMS URI can include an optional parameter that holds the masterSecret: `kms://cluster-kms?masterSecret=<masterSecret>`.
The above approach allows us to integrate with the existing setup code in `kms/setup/setup.go` with only minimal changes (parse masterSecret in case of cluster-kms).
This code is used to setup CloudKMS objects.
The `setup.go` code will have to be refactored to live in `internal` so that the disk-mapper pkg can directly communicate with the respective external KMS.
### Implemented, but yet unused features
There are CKMS backends for Azure, GCP, and AWS.