Temporarily add the attestationVariant key to the service
values during upgrade. Normally this should not be
modified during upgrade. However, since the field is introduced
in v2.7, we need to add the field manually.
This is the first step for deprecating app registrations on Azure.
The user-assigned managed identity (uami) should first gain all permissions that are currently held by the app registration.
* cli: give Azure uami all permissions previously given to app registratio
* docs: document required owner role for user-assigned managed identity on Azure
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
* create and update maa attestation policy
* use interface to allow unit testing
* fix test csp
* http request for policy patch
* go mod tidy
* remove hyphen
* go mod tidy
* wip: adapt to feedback
* linting fixes
* remove csp from tf call
* fix type assertion
* Add MAA URL to instance tags (#1409)
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
* conditionally create maa provider
* only set instance tag when maa is created
* fix azure unit test
* bazel tidy
* remove AzureCVM const
Co-authored-by: Thomas Tendyck <51411342+thomasten@users.noreply.github.com>
* encode policy at runtime
* remove policy arg
* fix unit test
---------
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
Co-authored-by: Daniel Weiße <66256922+daniel-weisse@users.noreply.github.com>
Co-authored-by: Thomas Tendyck <51411342+thomasten@users.noreply.github.com>
This command symlinks all binaries into the current working directory (or the path specified by the first argument)
* bazel: command to prepare development workspace
* bazel: set malt3 as codeowner
* 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>
* build: correct toolchain order
* build: gazelle-update-repos
* build: use pregenerated proto for dependencies
* update bazeldnf
* deps: tpm simulator
* Update Google trillian module
* cli: add stamping as alternative build info source
* bazel: add go_test wrappers, mark special tests and select testing deps
* deps: add libvirt deps
* deps: go-libvirt patches
* deps: cloudflare circl patches
* bazel: add go_test wrappers, mark special tests and select testing deps
* bazel: keep gazelle overrides
* bazel: cleanup bazelrc
* bazel: switch CMakeLists.txt to use bazel
* bazel: fix injection of version information via stamping
* bazel: commit all build files
* dev-docs: document bazel usage
* deps: upgrade zig-cc for go 1.20
* bazel: update Perl for macOS arm64 & Linux arm64 support
* bazel: use static perl toolchain for OpenSSL
* bazel: use static protobuf (protoc) toolchain
* deps: add git and go to nix deps
Co-authored-by: Paul Meyer <49727155+katexochen@users.noreply.github.com>
* Add missing flag to miniConstellation
* Add config merger to miniConstellation
* Soft fail if config can not be merged
* Remove config flattening
* Release spinner stop lock when stopping finished
---------
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
Co-authored-by: Nils Hanke <nils.hanke@outlook.com>
This is a measure to detect cases where an aTLS handshake is performed but the long running call is interrupted, leading to a retry of the init call.
Whenever the grpc connection state reaches ready, we know that the aTLS handshake has succeeded:
> READY: The channel has successfully established a connection all the way through TLS handshake (or equivalent) and protocol-level (HTTP/2, etc) handshaking, and all subsequent attempt to communicate have succeeded (or are pending without any known failure).
Applies the updated NodeVersion object with one request
instead of two. This makes sure that the first request does
not accidentially put the cluster into a "updgrade in progress"
status. Which would lead users to having to run apply twice.
* Move storage clients to separate packages
* Allow setting of client credentials for AWS S3
* Use managed identity client secret or default credentials for Azure Blob Storage
* Use credentials file to authorize GCS client
---------
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.
* replace tf destruction with new command
* move iam destroy cmd
* fix typos
* exit post test on error
* [remove] test failure on iam destroy
* Revert "[remove] test failure on iam destroy"
This reverts commit 99449c0cc0.
* [remove] test failure on terminate
* Revert "[remove] test failure on terminate"
This reverts commit 99c45bbc54.
* gofumpt
* 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.
* `upgrade apply` will try to make the locally configured and
actual version in the cluster match by appling necessary
upgrades.
* Skip image or kubernetes upgrades if one is already
in progress.
* Skip downgrades/equal-as-running versions
* Move NodeVersionResourceName constant from operators
to internal as its needed in the CLI.
* introduce handleImageUpgrade & handleServiceUpgrade
* rename cloudUpgrader.Upgrade to UpgradeImage
* remove helm flag
* remove hint about development status
Previously the chart's values were not set, relying on the
values that are already present in the cluster and reusing
those. This does not work as e.g. the image values
are only set while loading the charts. Also, the templates
are not rendered correctly without all values set.
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.
* Generate kubeconfig with unique name
* Move create name flag to config
* Add name validation to config
* Move name flag in e2e tests to config generation
* Remove name flag from create
* Update ascii cinema flow
---------
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
* AB#2787 add debug logging to iam create command
* AB#2787 add test logger
* AB#2787 reword log
* separate debug output with empty line
Co-authored-by: Daniel Weiße <66256922+daniel-weisse@users.noreply.github.com>
---------
Co-authored-by: Daniel Weiße <66256922+daniel-weisse@users.noreply.github.com>
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.
Version validation checks that the configured versions
are not more than one minor version below the CLI's version.
The validation can be disabled using --force.
This is necessary for now during development as the CLI
does not have a prerelease version, as our images do.
So far the masterSecret was sent to the initial bootstrapper
on init/recovery. With this commit this information is encoded
in the kmsURI that is sent during init.
For recover, the communication with the recoveryserver is
changed. Before a streaming gRPC call was used to
exchanges UUID for measurementSecret and state disk key.
Now a standard gRPC is made that includes the same kmsURI &
storageURI that are sent during init.
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.
* update constellation-os to constellation-version references
* update nodeimage to nodeversion in CRD type name
Signed-off-by: Fabian Kammel <fk@edgeless.systems>
Co-authored-by: Malte Poll <mp@edgeless.systems>
These backups could be used in case an upgrade
misbehaves after helm declared it as successful.
The manual backups are required as helm-rollback
won't touch custom resources and changes to CRDs
delete resources of the old version.
* Update module github.com/talos-systems/talos/pkg/machinery to v1.3.1
* Rename talos-systems/talos to siderolabs/talos
Co-authored-by: Paul Meyer <49727155+katexochen@users.noreply.github.com>
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.
