* variant: move into internal/attestation
* attesation: move aws attesation into subfolder nitrotpm
* config: add aws-sev-snp variant
* cli: add tf option to enable AWS SNP
For now the implementations in aws/nitrotpm and aws/snp
are identical. They both contain the aws/nitrotpm impl.
A separate commit will add the actual attestation logic.
* fetch latest version when older than 2 weeks
* extend hack upload tool to pass an upload date
* Revert "config: disable user-facing version Azure SEV SNP fetch for v2.8 (#1882)"
This reverts commit c7b22d314a.
* fix tests
* use NewAzureSEVSNPVersionList for type guarantees
* Revert "use NewAzureSEVSNPVersionList for type guarantees"
This reverts commit 942566453f4b4a2b6dc16f8689248abf1dc47db4.
* assure list is sorted
* improve root.go style
* daniel feedback
* rename to attestationconfigapi + put client and fetcher inside pkg
* rename api/version to versionsapi and put fetcher + client inside pkg
* rename AttestationConfigAPIFetcher to Fetcher
The implementation would recreate the gcp instance template (including all instances and state disks) whenever the image tfvar changes.
Fixed by ignoring lifecycle changes on the instance templates.
Fixes 8c3b963
* client supports delete version
* rename to new attestation / fetcher naming
* add delete command to upload tool
* test client delete
* bazel update
* use general client in attestation client
* Update hack/configapi/cmd/delete.go
Co-authored-by: Daniel Weiße <66256922+daniel-weisse@users.noreply.github.com>
* daniel feedback
* unit test azure sev upload
* Update hack/configapi/cmd/delete.go
Co-authored-by: Daniel Weiße <66256922+daniel-weisse@users.noreply.github.com>
* add client integration test
* new client cmds use apiObject
---------
Co-authored-by: Daniel Weiße <66256922+daniel-weisse@users.noreply.github.com>
* sign version with release key and remove version from fetcher interface
* extend azure-reporter GH action to upload updated version values to the Attestation API
* api: rename AttestationVersionRepo to Client
* api: move client into separate subpkg for
clearer import paths.
* api: rename configapi -> attestationconfig
* api: rename versionsapi -> versions
* api: rename sut to client
* api: split versionsapi client and make it public
* api: split versionapi fetcher and make it public
* config: move attestationversion type to config
* api: fix attestationconfig client test
Co-authored-by: Adrian Stobbe <stobbe.adrian@gmail.com>
* add SignContent() + integrate into configAPI
* use static client for upload versions tool; fix staticupload calleeReference bug
* use version to get proper cosign pub key.
* mock fetcher in CLI tests
* only provide config.New constructor with fetcher
Co-authored-by: Otto Bittner <cobittner@posteo.net>
Co-authored-by: Daniel Weiße <66256922+daniel-weisse@users.noreply.github.com>
During upgrade all custom resources are backed up to files on the
local file system. Since old versions are also backed up, we need to
reflect the version in the name.
* 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>
Resource names are only unique per kind+ns. Without this patch it
might happen that there are two resources with the same name
in different namespaces. Upgrade might fail in that case.
* The check would previously fail if e.g. `apply` did not upgrade the
image, but a new image was specified in the config. This could
happen if the specified image was too new, but a valid Kuberentes
upgrade was specified.
* ci: fix variable expansion in e2e-upgrade call
* e2e: do not verify measurement signature
* cli: upgrade check show cli upgrades
* only check compatibility for valid upgrades
* use semver.Sort
* extend unit tests
* add unit test for new compatible cli versions
* adapt to feedback
* fix rebase
* rework output
* minor -> major
Co-authored-by: Otto Bittner <cobittner@posteo.net>
* minor -> major
Co-authored-by: Otto Bittner <cobittner@posteo.net>
* dynamic major version
Co-authored-by: Otto Bittner <cobittner@posteo.net>
* remove currentK8sVer argument
* bazel gen & tidy
* bazel update
---------
Co-authored-by: Otto Bittner <cobittner@posteo.net>
Previously the content of files status and upgrade within the
cloudcmd pkg did not fit cloudcmd's pkg description.
This patch introduces a separate pkg to fix that.
The new command allows checking the status of an upgrade
and which versions are installed.
Also remove the unused restclient.
And make GetConstellationVersion a function.
* Remove deprecated fields
* Remove warning for not setting attestationVariant
* Dont write attestationVariant to config
---------
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>
This fixes a bug where `upgrade apply` fails if only the image is
upgraded, due to mishandling of an empty configmap.
Making stubStableClient more complex is needed since it is called
with multiple configMaps now.
* 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>
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>
* 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.
