mirror of
https://github.com/edgelesssys/constellation.git
synced 2025-06-28 16:07:21 -04:00
docs: rename components to microservices
Since we now have a config value called microserviceVersion it hopefully makes it easier for users to understand what this value controls if we also use the term microservice in the docs.
This commit is contained in:
parent
273225968f
commit
67a58bcc56
13 changed files with 36 additions and 36 deletions
|
@ -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.
|
||||
|
|
|
@ -57,7 +57,7 @@ measurements:
|
|||
Each entry specifies the expected value of the Constellation node, and whether the measurement should be enforced (`warnOnly: false`), or only a warning should be logged (`warnOnly: true`).
|
||||
By default, the subset of the [available measurements](../architecture/attestation.md#runtime-measurements) that can be locally reproduced and verified is enforced.
|
||||
|
||||
During attestation, the validating side (CLI or [join service](../architecture/components.md#joinservice)) compares each measurement reported by the issuing side (first node or joining node) individually.
|
||||
During attestation, the validating side (CLI or [join service](../architecture/microservices.md#joinservice)) compares each measurement reported by the issuing side (first node or joining node) individually.
|
||||
For mismatching measurements that have set `warnOnly` to `true` only a warning is emitted.
|
||||
For mismatching measurements that have set `warnOnly` to `false` an error is emitted and attestation fails.
|
||||
If attestation fails for a new node, it isn't permitted to join the cluster.
|
||||
|
@ -86,7 +86,7 @@ Once the above properties are verified, you know that you are talking to the rig
|
|||
|
||||
The `verify` command also allows you to verify any Constellation deployment that you have network access to. For this you need the following:
|
||||
|
||||
* The IP address of a running Constellation cluster's [VerificationService](../architecture/components.md#verificationservice). The `VerificationService` is exposed via a `NodePort` service using the external IP address of your cluster. Run `kubectl get nodes -o wide` and look for `EXTERNAL-IP`.
|
||||
* The IP address of a running Constellation cluster's [VerificationService](../architecture/microservices.md#verificationservice). The `VerificationService` is exposed via a `NodePort` service using the external IP address of your cluster. Run `kubectl get nodes -o wide` and look for `EXTERNAL-IP`.
|
||||
* The cluster's *clusterID*. See [cluster identity](../architecture/keys.md#cluster-identity) for more details.
|
||||
|
||||
For example:
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue