Git-Mirrors/constellation
1
0
Fork 0
mirror of https://github.com/edgelesssys/constellation.git synced 2025-07-27 09:15:22 -04:00
Code Issues Projects Releases Packages Wiki Activity

kms: rename kms to keyservice

Browse source 
In the light of extending our eKMS support it will be helpful
to have a tighter use of the word "KMS".
KMS should refer to the actual component that manages keys.
The keyservice, also called KMS in the constellation code,
does not manage keys itself. It talks to a KMS backend,
which in turn does the actual key management.
This commit is contained in:
Otto Bittner 2023-01-11 10:08:57 +01:00
parent 67f8336b9d
commit 90b88e1cf9
101 changed files with 313 additions and 319 deletions
Download patch file Download diff file Expand all files Collapse all files

16
docs/docs/architecture/components.md
View file

@ -7,7 +7,7 @@ These features are provided by several components:
* The [Bootstrapper](components.md#bootstrapper) initializes a Constellation node and bootstraps the cluster
* The [JoinService](components.md#joinservice) joins new nodes to an existing cluster
* The [VerificationService](components.md#verificationservice) provides remote attestation functionality
* The [Key Management Service (KMS)](components.md#kms) manages Constellation-internal keys
* The [KeyService](components.md#keyservice) manages Constellation-internal keys
The relations between components are shown in the following diagram:
@ -22,7 +22,7 @@ flowchart LR
end
subgraph Kubernetes
D[JoinService]
E[KMS]
E[KeyService]
F[VerificationService]
end
A -- deploys -->
@ -45,7 +45,7 @@ Otherwise, it waits for an initialization request to create a new Kubernetes clu
The *JoinService* runs as [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) on each control-plane node.
New nodes (at cluster start, or later through autoscaling) send a request to the service over [attested TLS (aTLS)](attestation.md#attested-tls-atls).
The *JoinService* verifies the new node's certificate and attestation statement.
If attestation is successful, the new node is supplied with an encryption key from the [*KMS*](components.md#kms) for its state disk, and a Kubernetes bootstrap token.
If attestation is successful, the new node is supplied with an encryption key from the [*KeyService*](components.md#keyservice) for its state disk, and a Kubernetes bootstrap token.
```mermaid
@ -55,8 +55,8 @@ sequenceDiagram
New node->>JoinService: aTLS handshake (server side verification)
JoinService-->>New node: #
New node->>+JoinService: IssueJoinTicket(DiskUUID, NodeName, IsControlPlane)
JoinService->>+KMS: GetDataKey(DiskUUID)
KMS-->>-JoinService: DiskEncryptionKey
JoinService->>+KeyService: GetDataKey(DiskUUID)
KeyService-->>-JoinService: DiskEncryptionKey
JoinService-->>-New node: DiskEncryptionKey, KubernetesJoinToken, ...
```
@ -66,8 +66,8 @@ The *VerificationService* runs as DaemonSet on each node.
It provides user-facing functionality for remote attestation during the cluster's lifetime via an endpoint for [verifying the cluster](attestation.md#cluster-attestation).
Read more about the hardware-based [attestation feature](attestation.md) of Constellation and how to [verify](../workflows/verify-cluster.md) a cluster on the client side.
## KMS
## KeyService
The *KMS* runs as DaemonSet on each control-plane node.
The *KeyService* runs as DaemonSet on each control-plane node.
It implements the key management for the [storage encryption keys](keys.md#storage-encryption) in Constellation. These keys are used for the [state disk](images.md#state-disk) of each node and the [transparently encrypted storage](encrypted-storage.md) for Kubernetes.
Depending on wether the [constellation-managed](keys.md#constellation-managed-key-management) or [user-managed](keys.md#user-managed-key-management) mode is used, the *KMS* holds the key encryption key (KEK) directly or calls an external service for key derivation respectively.
Depending on wether the [constellation-managed](keys.md#constellation-managed-key-management) or [user-managed](keys.md#user-managed-key-management) mode is used, the *KeyService* holds the key encryption key (KEK) directly or calls an external key management service (KMS) for key derivation respectively.

2
docs/docs/architecture/encrypted-storage.md
View file

@ -28,7 +28,7 @@ All cryptographic operations happen inside the trusted environment of the confid
Note that for integrity-protected disks, [volume expansion](https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/) isn't supported.
By default the driver uses data encryption keys (DEKs) issued by the Constellation [*KMS*](components.md#kms).
By default the driver uses data encryption keys (DEKs) issued by the Constellation [*KeyService*](components.md#keyservice).
The DEKs are in turn derived from the Constellation's key encryption key (KEK), which is directly derived from the [master secret](keys.md#master-secret).
This is the recommended mode of operation, and also requires the least amount of setup by the cluster administrator.