* Delete helm chart on failure before retrying installation
* Add chart name to debug output
* Remove now unused wait flag from helm Release struct
---------
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
* Add attestation options to config
* Add join-config migration path for clusters with old measurement format
* Always create MAA provider for Azure SNP clusters
* Remove confidential VM option from provider in favor of attestation options
* cli: add config migrate command to handle config migration (#1678)
---------
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
* Remove using measurements from the initial control-plane node for the cluster's initial measurements
* Add using measurements from the user's config for the cluster's initial measurements to align behavior with upgrade command
---------
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
The test is implemented as a go test.
It can be executed as a bazel target.
The general workflow is to setup a cluster,
point the test to the workspace in which to
find the kubeconfig and the constellation config
and specify a target image, k8s and
service version. The test will succeed
if it detects all target versions in the cluster
within the configured timeout.
The CI automates the above steps.
A separate workflow is introduced as there
are multiple input fields to the test.
Adding all of these to the manual e2e test
seemed confusing.
Co-authored-by: Fabian Kammel <fk@edgeless.systems>
* Convert enforceIDKeyDigest setting to enum
* Use MAA fallback in Azure SNP attestation
* Only create MAA provider if MAA fallback is enabled
---------
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
Co-authored-by: Thomas Tendyck <tt@edgeless.systems>
Previously backups were created even if no service upgrades were
executed. To allow this some things are restructured:
* new chartInfo type that holds release name, path and chart name
* upgrade execution and version validity are checked separately
* Add attestation type to config (optional for now)
* Get attestation variant from config in CLI
* Set attestation variant for Constellation services in helm deployments
* Remove AzureCVM variable from helm deployments
---------
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
The variable VersionInfo is supposed to be set by `go build -X ...` during link time but should not be modified at runtime.
This change ensures the underlying var is private and can only be accessed by a public getter.
* As charts receive information like the container image from
the cli it makes sense to also version the charts based on the cli
version.
* The pseudoversion is recalculated when running cmake.
* When merging changes from release branch to main,
a new commit is introduced to set the PROJECT_VERSION back
to 0.0.0, so that builds include a pseudoversion.
Because values in the charts might change in the future and
some values (like the image) are part of a valid upgrade we
need to load all values for an upgrade.
However, during upgrades we don't want to reapply user
input like the masterSecret. Therefore this patch splits the
application of user input and the static loading of chart values.
Upgrade check is used to find updates for the current cluster.
Optionally the found upgrades can be persisted to the config
for consumption by the upgrade-execute cmd.
The old `upgrade execute` in this commit does not work with
the new `upgrade plan`.
The current versions are read from the cluster.
Supported versions are read from the cli and the versionsapi.
Adds a new config field MicroserviceVersion that will be used
by `upgrade execute` to update the service versions.
The field is optional until 2.7
A deprecation warning for the upgrade key is printed during
config validation.
Kubernetes versions now specify the patch version to make it
explicit for users if an upgrade changes the k8s version.
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.
Run with: constellation upgrade execute --helm.
This will only upgrade the helm charts. No config is needed.
Upgrades are implemented via helm's upgrade action, i.e. they
automatically roll back if something goes wrong. Releases could
still be managed via helm, even after an upgrade with constellation
has been done.
Currently not user facing as CRD/CR backups are still in progress.
These backups should be automatically created and saved to the
user's disk as updates may delete CRs. This happens implicitly
through CRD upgrades, which are part of microservice upgrades.
* Merge enforced and expected measurements
* Update measurement generation to new format
* Write expected measurements hex encoded by default
* Allow hex or base64 encoded expected measurements
* Allow hex or base64 encoded clusterID
* Allow security upgrades to warnOnly flag
* Upload signed measurements in JSON format
* Fetch measurements either from JSON or YAML
* Use yaml.v3 instead of yaml.v2
* Error on invalid enforced selection
* Add placeholder measurements to config
* Update e2e test to new measurement format
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
* Include EXC0014 and fix issues.
* Include EXC0012 and fix issues.
Signed-off-by: Fabian Kammel <fk@edgeless.systems>
Co-authored-by: Otto Bittner <cobittner@posteo.net>
* Wrap KMS deployment in one main chart that
deploys all other services. Other services will follow.
* Use .tgz via helm-package as serialization format
* Change Release type to carry chart as byte slice
* Remove KMSConfig
* Use json-schema to validate values
* Extend release.md to mention updating helm charts
