* Reduce external dependencies of kubecmd package
* Add kubecmd wrapper to constellation-lib
* Update CLI code to use constellation-lib
* Move kubecmd package to subpackage of constellation-lib
* Initialise helm and kubecmd clients when kubeConfig is set
---------
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
* cli: move internal packages
Signed-off-by: Moritz Sanft <58110325+msanft@users.noreply.github.com>
* cli: fix buildfiles
Signed-off-by: Moritz Sanft <58110325+msanft@users.noreply.github.com>
* bazel: fix exclude dir
Signed-off-by: Moritz Sanft <58110325+msanft@users.noreply.github.com>
* cli: move back libraries that will not be used by TF provider
Signed-off-by: Moritz Sanft <58110325+msanft@users.noreply.github.com>
---------
Signed-off-by: Moritz Sanft <58110325+msanft@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
* bazel-deps-mirror: upgrade command
This command can be used to upgrade a dependency.
Users are supposed to replace any upstream URLs and run the upgrade command.
It replaces the expected hash and uploads the new dep to the mirror.
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
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.
