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

remove sample config in docs

Browse source
This commit is contained in:
Leonard Cohnen 2022-09-13 13:09:29 +02:00 • committed by 3u13r
parent 4898f06421
commit a5e82fcb0e
16 changed files with 14 additions and 164 deletions
Download patch file Download diff file Expand all files Collapse all files

4
docs/versioned_docs/version-2.0/architecture/attestation.md
View file

@ -120,7 +120,7 @@ Refer to [images](images.md) for more details on the Constellation boot chain.
The Constellation [Bootstrapper](components.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](../reference/config.md) which measurements should be enforced during the attestation process
Constellation allows to specify in the config which measurements should be enforced during the attestation process
Enforcing non-reproducible measurements controlled by the cloud provider means that changes in these values require manual updates to the cluster's config.
By default, Constellation only enforces measurements that are stable values produced by the infrastructure or by Constellation directly.
@ -187,7 +187,7 @@ The latter means that value can be generated offline and compared to the one in
## Cluster attestation
Cluster-facing, Constellation's [*JoinService*](components.md#joinservice) verifies each node joining the cluster given the [configured](../reference/config.md) ground truth runtime measurements.
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.

4
docs/versioned_docs/version-2.0/architecture/components.md
View file

@ -39,7 +39,7 @@ flowchart LR
The *Bootstrapper* is the first component 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](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the [configured](../reference/config.md) versions.
To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) 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.
Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
@ -78,4 +78,4 @@ Depending on wether the [constellation-managed](keys.md#constellation-managed-ke
## AccessManager
The *AccessManager* runs as DaemonSet on each node.
It manages the user's SSH access to nodes as specified in the [configuration](../reference/config.md).
It manages the user's SSH access to nodes as specified in the config.

2
docs/versioned_docs/version-2.0/architecture/images.md
View file

@ -41,5 +41,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](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as [configured](../reference/config.md) by the user.
During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) 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.

1
docs/versioned_docs/version-2.0/architecture/orchestration.md
View file

@ -20,7 +20,6 @@ Releases of Constellation are [published on GitHub](https://github.com/edgelesss
To allow for fine-grained configuration of your cluster and cloud environment, Constellation supports an extensive configuration file with strong defaults.
The CLI provides you with a good default configuration which can be generated with `constellation config generate`. Some cloud account-specific information is always required and to be set by the user.
Details and examples can be found in the [reference guide](../reference/config.md).
The following files are generated during the creation of a Constellation cluster and stored in the current workspace: