Git-Mirrors/constellation
1
0
Fork 0
mirror of https://github.com/edgelesssys/constellation.git synced 2024-10-01 01:36:09 -04:00
Code Issues Packages Projects Releases Wiki Activity

Polish

Browse Source
This commit is contained in:
flxflx 2024-09-26 14:37:34 +02:00
parent 55cd190c7a
commit 810a2a9d24
1 changed files with 4 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
dev-docs/security-overview.md
View File

@ -146,19 +146,17 @@ On success, an aTLS connection between the two is created, which is used mainly
1. The new node sends a certificate signing request (CSR) for its *node certificate* to the JoinService.
1. The JoinService issues a corresponding certificate with a lifetime of one year and sends it to the new node.
The JoinService uses the signing key of the Kubernetes cluster for this, which is [generated by kubeadm](https://kubernetes.io/docs/setup/best-practices/certificates/).
The JoinService uses the signing key of the Kubernetes cluster for this, which is [generated by kubeadm](https://kubernetes.io/docs/setup/best-practices/certificates/). Note that the lifetime of the node certificate is a best practice only, as Constellation relies on the untrusted infrastructure to provide time when validating certificates.
1. The JoinService sends a [kubeadm token](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-token/) to the new node.
1. The JoinService sends the hashes of the expected Kubernetes binaries to the new node.
1. The JoinService sends encryption key for the new node's local storage.
This key is generated and managed by the cluster's KeyService.
1. The JoinService sends the certificate of the cluster's control plane to the new node.
Note that the lifetime of the node certificate is a best practice only, as Constellation relies on the untrusted infrastructure to provide time when validating certificates.
After this, the aTLS connection is closed and the node is marked as "initialized" in the same way as described [above](#cluster-creation).
The Bootstrapper on the new node uses the kubeadm token to download the configuration of the cluster from the Kubernetes API server.
Subsequently, it downloads, verifies, and runs the given Kubernetes binaries accordingly.
The Bootstrapper downloads, verifies, and runs the given Kubernetes binaries.
Further, the Bootstrapper uses the kubeadm token to download the configuration of the cluster from the Kubernetes API server.
The kubeadm token is never used after this.
The kubelet on the new node uses its own node certificate and the certificate of the cluster's control plane (which the new node both received from the JoinService) to establish an mTLS connection with the cluster's Kubernetes API server.
@ -169,7 +167,7 @@ In Constellation, a virtual private network (VPN) exists between all nodes of a
This VPN is created with the help of Cilium.
To join this VPN, the new node generates WireGuard credentials for itself and writes the public key to etcd via the mTLS connection with the Kubernetes API server.
It also downloads the public keys of existing nodes from etcd.
The Cilium agents running on other nodes fetch the new node's credentials from there.
Subsequently, the Cilium agents running on other nodes fetch the new node's public key from etcd as well.
Note that etcd communication between nodes is an exception: This traffic always goes via mTLS based on node certificates.