edgelesssys · derpsteb · Mar 3, 2023 · Mar 3, 2023 · Mar 3, 2023
@@ -66,7 +66,7 @@ The protocol can be used by clients to verify a server certificate, by a server
 The challenge for Constellation is to lift a CVM's attestation statement to the Kubernetes software layer and make it end-to-end verifiable.
 From there, Constellation needs to expand the attestation from a single CVM to the entire cluster.
 
-The [*JoinService*](components.md#joinservice) and [*VerificationService*](components.md#verificationservice) are where all runs together.
+The [*JoinService*](microservices.md#joinservice) and [*VerificationService*](microservices.md#verificationservice) are where all runs together.
 Internally, the *JoinService* uses remote attestation to securely join CVM nodes to the cluster.
 Externally, the *VerificationService* provides an attestation statement for the cluster's CVMs and configuration.
 
@@ -114,7 +114,7 @@ The [signed image measurements](#chain-of-trust) include measurements that are k
 
 * **Measurements produced by the Constellation bootloader and boot chain**:
 The Constellation Bootloader takes over from the CVM firmware and [measures the rest of the boot chain](images.md).
-The Constellation [Bootstrapper](components.md#bootstrapper) is the first user mode component that runs in a Constellation image.
+The Constellation [Bootstrapper](microservices.md#bootstrapper) is the first user mode component that runs in a Constellation image.
 It extends PCR registers with the [IDs](keys.md#cluster-identity) of the cluster marking a node as initialized.
 
 Constellation allows to specify in the config which measurements should be enforced during the attestation process.
@@ -222,24 +222,24 @@ The latter means that the value can be generated offline and compared to the one
 
 ## Cluster attestation
 
-Cluster-facing, Constellation's [*JoinService*](components.md#joinservice) verifies each node joining the cluster given the configured ground truth runtime measurements.
-User-facing, the [*VerificationService*](components.md#verificationservice) provides an interface to verify a node using remote attestation.
-By verifying the first node during the [initialization](components.md#bootstrapper) and configuring the ground truth measurements that are subsequently enforced by the *JoinService*, the whole cluster is verified in a transitive way.
+Cluster-facing, Constellation's [*JoinService*](microservices.md#joinservice) verifies each node joining the cluster given the configured ground truth runtime measurements.
+User-facing, the [*VerificationService*](microservices.md#verificationservice) provides an interface to verify a node using remote attestation.
+By verifying the first node during the [initialization](microservices.md#bootstrapper) and configuring the ground truth measurements that are subsequently enforced by the *JoinService*, the whole cluster is verified in a transitive way.
 
 ### Cluster-facing attestation
 
 The *JoinService* is provided with the runtime measurements of the whitelisted Constellation image version as the ground truth.
 During the initialization and the cluster bootstrapping, each node connects to the *JoinService* using [aTLS](#attested-tls-atls).
 During the handshake, the node transmits an attestation statement including its runtime measurements.
 The *JoinService* verifies that statement and compares the measurements against the ground truth.
-For details of the initialization process check the [component descriptions](components.md).
+For details of the initialization process check the [microservice descriptions](microservices.md).
 
 After the initialization, every node updates its runtime measurements with the *clusterID* value, marking it irreversibly as initialized.
 When an initialized node tries to join another cluster, its measurements inevitably mismatch the measurements of an uninitialized node and it will be declined.
 
 ### User-facing attestation
 
-The [*VerificationService*](components.md#verificationservice) provides an endpoint for obtaining its hardware-based remote attestation statement, which includes the runtime measurements.
+The [*VerificationService*](microservices.md#verificationservice) provides an endpoint for obtaining its hardware-based remote attestation statement, which includes the runtime measurements.
 A user can [verify](../workflows/verify-cluster.md) this statement and compare the measurements against the configured ground truth and, thus, verify the identity and integrity of all Constellation components and the cluster configuration. Subsequently, the user knows that the entire cluster is in the expected state and is trustworthy.
 
 ## Chain of trust

@@ -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 [*KeyService*](components.md#keyservice).
+By default the driver uses data encryption keys (DEKs) issued by the Constellation [*KeyService*](microservices.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.
 

@@ -45,5 +45,5 @@ See the section on [keys and encryption](keys.md#storage-encryption) for more in
 
 ## Kubernetes components
 
-During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
+During initialization, the [*Bootstrapper*](microservices.md#bootstrapper) downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
 They're stored on the state partition and can be updated once new releases need to be installed.
@@ -27,7 +27,7 @@ On node boot, they're determined using the CVM's attestation mechanism and [meas
 
 The **clusterID** represents the identity of a single initialized Constellation cluster.
 It's derived from the master secret and a cryptographically random salt and unique for every Constellation cluster.
-The [Bootstrapper](components.md#bootstrapper) measures the *clusterID* into its own PCR before executing any code not measured as part of the *base measurements*.
+The [Bootstrapper](microservices.md#bootstrapper) measures the *clusterID* into its own PCR before executing any code not measured as part of the *base measurements*.
 See [Node attestation](attestation.md#node-attestation) for details.
 
 The remote attestation statement of a Constellation cluster combines the *base measurements* and the *clusterID* for a verifiable, unspoofable, unique identity.

@@ -1,15 +1,15 @@
-# Components
+# Microservices
 
 Constellation takes care of bootstrapping and initializing a Confidential Kubernetes cluster.
 During the lifetime of the cluster, it handles day 2 operations such as key management, remote attestation, and updates.
-These features are provided by several components:
+These features are provided by several microservices:
 
-* 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 [KeyService](components.md#keyservice) manages Constellation-internal keys
+* The [Bootstrapper](microservices.md#bootstrapper) initializes a Constellation node and bootstraps the cluster
+* The [JoinService](microservices.md#joinservice) joins new nodes to an existing cluster
+* The [VerificationService](microservices.md#verificationservice) provides remote attestation functionality
+* The [KeyService](microservices.md#keyservice) manages Constellation-internal keys
 
-The relations between components are shown in the following diagram:
+The relations between microservices are shown in the following diagram:
 
 ```mermaid
 flowchart LR
@@ -34,18 +34,18 @@ flowchart LR
 
 ## Bootstrapper
 
-The *Bootstrapper* is the first component launched after booting a Constellation node image.
+The *Bootstrapper* is the first microservice launched after booting a Constellation node image.
 It sets up that machine as a Kubernetes node and integrates that node into the Kubernetes cluster.
 To this end, the *Bootstrapper* first downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
-The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
+The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](microservices.md#joinservice) to join the node.
 Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
 
 ## JoinService
 
 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 [*KeyService*](components.md#keyservice) 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*](microservices.md#keyservice) for its state disk, and a Kubernetes bootstrap token.
 
 
 ```mermaid

@@ -34,10 +34,10 @@ In addition, the cluster's [identifier](orchestration.md#post-installation-confi
 
 1. The CLI `create` command creates the confidential VM (CVM) resources in your cloud environment and configures the network
 2. Each CVM boots the Constellation node image and measures every component in the boot chain
-3. The first component launched in each node is the [*Bootstrapper*](components.md#bootstrapper)
+3. The first microservice launched in each node is the [*Bootstrapper*](microservices.md#bootstrapper)
 4. The *Bootstrapper* waits until it either receives an initialization request or discovers an initialized cluster
 5. The CLI `init` command connects to the *Bootstrapper* of a selected node, sends the configuration, and initiates the initialization of the cluster
-6. The *Bootstrapper* of **that** node [initializes the Kubernetes cluster](components.md#bootstrapper) and deploys the other Constellation [components](components.md) including the [*JoinService*](components.md#joinservice)
+6. The *Bootstrapper* of **that** node [initializes the Kubernetes cluster](microservices.md#bootstrapper) and deploys the other Constellation [microservices](microservices.md) including the [*JoinService*](microservices.md#joinservice)
 7. Subsequently, the *Bootstrappers* of the other nodes discover the initialized cluster and send join requests to the *JoinService*
 8. As part of the join request each node includes an attestation statement of its boot measurements as authentication
 9. The *JoinService* verifies the attestation statements and joins the nodes to the Kubernetes cluster
@@ -66,15 +66,15 @@ The *clusterID* uniquely identifies a cluster and can be used to [verify your cl
 
 ## Upgrades
 
-Constellation images and components may need to be upgraded to new versions during the lifetime of a cluster.
+Constellation images and microservices may need to be upgraded to new versions during the lifetime of a cluster.
 Constellation implements a rolling update mechanism ensuring no downtime of the control or data plane.
 You can upgrade a Constellation cluster with a single operation by using the CLI.
 For step-by-step instructions on how to do this, refer to [Upgrade your cluster](../workflows/upgrade.md).
 
 ### Attestation of upgrades
 
 With every new image, corresponding measurements are released.
-During an update procedure, the CLI provides the new measurements to the [JoinService](components.md#joinservice) securely.
+During an update procedure, the CLI provides new measurements to the [JoinService](microservices.md#joinservice) securely.
 New measurements for an updated image are automatically pulled and verified by the CLI following the [supply chain security concept](attestation.md#chain-of-trust) of Constellation.
 The [attestation section](attestation.md#cluster-facing-attestation) describes in detail how these measurements are then used by the JoinService for the attestation of nodes.
 

@@ -9,9 +9,9 @@ To learn more about Constellation and Kubernetes, see [product overview](../over
 As a cluster administrator, you can use the [Constellation CLI](orchestration.md) to install and deploy a cluster.
 Updates are provided in accordance with the [support policy](versions.md).
 
-## About the components and attestation
+## About microservices and attestation
 
-Constellation manages the nodes and network in your cluster. All nodes are bootstrapped by the [*Bootstrapper*](components.md#bootstrapper). They're verified and authenticated by the [*JoinService*](components.md#joinservice) before being added to the cluster and the network. Finally, the entire cluster can be verified via the [*VerificationService*](components.md#verificationservice) using [remote attestation](attestation.md).
+Constellation manages the nodes and network in your cluster. All nodes are bootstrapped by the [*Bootstrapper*](microservices.md#bootstrapper). They're verified and authenticated by the [*JoinService*](microservices.md#joinservice) before being added to the cluster and the network. Finally, the entire cluster can be verified via the [*VerificationService*](microservices.md#verificationservice) using [remote attestation](attestation.md).
 
 ## About node images and verified boot
 

@@ -1,7 +1,7 @@
 # Versions and support policy
 
-All [components](components.md) of Constellation use a three-digit version number of the form `v<MAJOR>.<MINOR>.<PATCH>`.
-The components are released in lock step, usually on the first Tuesday of every month. This release primarily introduces new features, but may also include security or performance improvements. The `MINOR` version will be incremented as part of this release.
+All [microservices](microservices.md) of Constellation use a three-digit version number of the form `v<MAJOR>.<MINOR>.<PATCH>`.
+The microservices are released in lock step, usually on the first Tuesday of every month. This release primarily introduces new features, but may also include security or performance improvements. The `MINOR` version will be incremented as part of this release.
 
 Additional `PATCH` releases may be created on demand, to fix security issues or bugs before the next `MINOR` release window.
 

@@ -66,7 +66,7 @@ NAME              STATUS   ROLES           AGE   VERSION
 control-plane-0   Ready    control-plane   66s   v1.24.6
 ```
 
-A worker node will request to join the cluster shortly. Before the new worker node is allowed to join the cluster, its state is verified using remote attestation by the [JoinService](../architecture/components.md#joinservice).
+A worker node will request to join the cluster shortly. Before the new worker node is allowed to join the cluster, its state is verified using remote attestation by the [JoinService](../architecture/microservices.md#joinservice).
 If verification passes successfully, the new node receives keys and certificates to join the cluster.
 
 You can follow this process by viewing the logs of the JoinService:

@@ -5,7 +5,7 @@ If you want to use cert-manager with Constellation, pay attention to the followi
 :::
 
 Constellation ships with cert-manager preinstalled.
-The default installation is part of the `kube-system` namespace, as all other Constellation-managed components.
+The default installation is part of the `kube-system` namespace, as all other Constellation-managed microservices.
 You are free to install more instances of cert-manager into other namespaces.
 However, be aware that any new installation needs to use the same version as the one installed with Constellation or rely on the same CRD versions.
 Also remember to set the `installCRDs` value to `false` when installing new cert-manager instances.

@@ -37,7 +37,7 @@ Similar output to the following means your node was restarted and needs to decry
 {"level":"INFO","ts":"2022-09-08T09:56:43Z","logger":"rejoinClient","caller":"rejoinclient/client.go:65","msg":"Starting RejoinClient"}
 ```
 
-The node will then try to connect to the [*JoinService*](../architecture/components.md#joinservice) and obtain the decryption key.
+The node will then try to connect to the [*JoinService*](../architecture/microservices.md#joinservice) and obtain the decryption key.
 If this fails due to an unhealthy control plane, you will see log messages similar to the following:
 
 ```json
@@ -73,7 +73,7 @@ Similar output to the following means your node was restarted and needs to decry
 {"level":"INFO","ts":"2022-09-08T10:21:53Z","logger":"recoveryServer","caller":"recoveryserver/server.go:59","msg":"Starting RecoveryServer"}
 ```
 
-The node will then try to connect to the [*JoinService*](../architecture/components.md#joinservice) and obtain the decryption key.
+The node will then try to connect to the [*JoinService*](../architecture/microservices.md#joinservice) and obtain the decryption key.
 If this fails due to an unhealthy control plane, you will see log messages similar to the following:
 
 ```json
@@ -104,7 +104,7 @@ Similar output to the following means your node was restarted and needs to decry
 {"level":"INFO","ts":"2022-09-08T10:21:53Z","logger":"recoveryServer","caller":"recoveryserver/server.go:59","msg":"Starting RecoveryServer"}
 ```
 
-The node will then try to connect to the [*JoinService*](../architecture/components.md#joinservice) and obtain the decryption key.
+The node will then try to connect to the [*JoinService*](../architecture/microservices.md#joinservice) and obtain the decryption key.
 If this fails due to an unhealthy control plane, you will see log messages similar to the following:
 
 ```json

@@ -1,6 +1,6 @@
 # Consume software bill of materials (SBOMs)
 
-Constellation builds produce a [software bill of materials (SBOM)](https://www.ntia.gov/SBOM) for each generated [artifact](../architecture/components.md).
+Constellation builds produce a [software bill of materials (SBOM)](https://www.ntia.gov/SBOM) for each generated [artifact](../architecture/microservices.md).
 You can use SBOMs to make informed decisions about dependencies and vulnerabilities in a given application. Enterprises rely on SBOMs to maintain an inventory of used applications, which allows them to take data-driven approaches to managing risks related to vulnerabilities.
 
 SBOMs for Constellation are generated using [Syft](https://github.com/anchore/syft), signed using [Cosign](https://github.com/sigstore/cosign), and stored with the produced artifact.