This commit allows the disabling of the caching cluster reader used by
the status poller while waiting and/or checking the health of resources.
Potentially reducing the memory usage of the controller on large scale
clusters, at the cost of an increase in direct API calls.
The feature can be enabled using
`--feature-gates=DisableStatusPollerCache=true`.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
You can re-enable caching by starting the controller with the argument
`--feature-gates=CacheSecretsAndConfigMaps=true`.
Signed-off-by: Hidde Beydals <hello@hidde.co>
- Update Go to 1.19 in CI
- Use Go 1.19 in base image
- Update controller-gen v0.8.0 (v0.7 fails with Go 1.19) and regenerate manifests
Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>
The existing fuzzers are converted into the Go native format. This
works well with most fuzzers, apart from the one that fuzzes the
controller.
That specific test depends on funcs and vars that are defined on
suite_test.go, which is not supported when building fuzzers leveraging
Go native fuzz for oss-fuzz. That test is therefore ignored when
executed with make fuzz-native. But, all tests are covered with
make fuzz-smoketest, in order to support oss-fuzz.
Once the controller is rewritten we can revist this and ensure that
fuzzers does not require envtest nor embedded CRDs.
Signed-off-by: Paulo Gomes <paulo.gomes@weave.works>
This temporarily disables the integration tests as we are waiting for
the CNCF to provide us with GCP credits.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This adds a SOPS GCP KMS key source which makes use of the latest GCP
client, and supports both injection of master key credentials and a
default client making use of environmental runtime values.
The implementation fully replaces SOPS', and is covered with
compatability tests.
Signed-off-by: Somtochi Onyekwere <somtochionyekwere@gmail.com>
This relicenses all of our SOPS implementation code to MPL 2.0, where
Apache 2.0 was previously used due to code being written from scratch.
By making this license change, we are better capable of contributing
the changes upstream.
In case there is doubt about validity of DCO sign-off to make such
changes: all code where Apache 2.0 license applies were authored by
myself. In addition, Apache 2.0 is compatible with MPL 2.0[1][2].
[1]: https://opensource.com/law/11/9/mpl-20-copyleft-and-license-compatibility
[2]: https://blog.gerv.net/2013/02/relicensing-when-do-you-have-to-ask/
Signed-off-by: Hidde Beydals <hello@hidde.co>
As patch has been merged upstream, and `keyservice.LocalClient` does
now accept the `KeyServiceServer` interface.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This adds a new Token type which can be used to configure an
azcore.TokenCredential on a master key. Due to this introduction, the
server only has to go through the AADConfig once.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This adds a new ParsedIdentities type which can be used to parse a set
of age identities just once, instead of parsing them for every Decrypt
request.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This adds a new GnuPGHome type which can be used to create a new
contained GnuPG home directory. The type is self-validating, ensuring
it adheres to e.g. permission rules set out by GnuPG, and allows for
importing keys from armored bytes and files.
Because of this introduction, the decryptor service no longer has to
write data from a Secret to a temporary file, but is instead able to
directly import them into the keyring from the Secret entry's bytes.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This revises the PGP keysource implementation, removing bits of code
that were not actually in use, or not viable in combination with how we
work with keys. In short:
- crypto/openpgp implementation has been removed. As it is unable to read
the keystore created by newer versions of GnuPG. Given we import user
provided keys _with_ GnuPG, this was basically dead code.
- All capabilities around fetching public keys from a server have been
removed.
- "Jailing" of GnuPG shell-out is now handled in `gpgExec`, in addition,
arguments for encrypt and decrypt execs have been revised to ensure
they e.g. do not instruct to use the agent.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This ensures we signal early that we will be unable to fulfill the
request, instead of letting the underlying keysource implementation
run into mayhem. Which can be problematic for e.g. PGP, which has
assumptions about things being located relative to the given home
directory, resulting in possible unexpected behavior if an empty path
is given.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This ensures data used for decryption is not exposed widely after
constructing the Server, and prevents a bypass to the default server
fallback.
Signed-off-by: Hidde Beydals <hello@hidde.co>
These bits of code have a history of accidents around the fallback
behavior. By simplifying it, the fallback should generally always work,
unless you put in instructions to take another route.
Signed-off-by: Hidde Beydals <hello@hidde.co>
The original keyservice implementation was forked from SOPS, keeping
the prompt capabilities intact. However, since the implementations have
started to grow, it is better to remove this capability and resort to
a hardcoded `false` default for the fallback server. As the controller
is never expected to have an interactive TTY/shell.
Signed-off-by: Hidde Beydals <hello@hidde.co>
To please the older Azure SDK, the upstream SOPS implementation base64
URL encodes data before encryption, and decodes it afterwards. With the
new SDK, this has changed, requiring us to do the opposite to ensure
compatibility.
Signed-off-by: Hidde Beydals <hello@hidde.co>
Add integration tests to ensure compatibility between our own Azure
keyservice implementation and upstream.
Tests are enabled to only run for `main`.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This solves a regression bug introduced in `v0.22.0`, which caused the
keyservice to not properly fall back to the default for Azure Key Vault
decryption requests.
A couple of nitpicks that I ran into while inspecting the code have
been adressed as well.
Signed-off-by: Hidde Beydals <hello@hidde.co>
- github.com/Azure/azure-sdk-for-go/sdk/azcore to v0.22.0
- github.com/Azure/azure-sdk-for-go/sdk/azidentity to v0.13.2
- github.com/Azure/azure-sdk-for-go/sdk/keyvault/azkeys to v0.4.0
- github.com/ProtonMail/go-crypto to v0.0.0-20220113124808-70ae35bab23f
- github.com/cyphar/filepath-securejoin to v0.2.3
- github.com/drone/envsubst to v1.0.3
- github.com/fluxcd/pkg/apis/kustomize to v0.3.2
- github.com/fluxcd/pkg/ssa to v0.15.1
- github.com/hashicorp/vault/api to v1.4.1
- go.mozilla.org/sops/v3 to v3.7.2
- golang.org/x/net to v0.0.0-20220225172249-27dd8689420f
- google.golang.org/grpc to v1.45.0
- k8s.io/api to v0.23.4
- k8s.io/apiextensions-apiserver to v0.23.4
- k8s.io/apimachinery to v0.23.4
- k8s.io/client-go to v0.23.4
- sigs.k8s.io/cli-utils to v0.29.3
Signed-off-by: Hidde Beydals <hello@hidde.co>
This updates to the `github.com/Azure/azure-sdk-for-go` SDK, which is
the (apparent) successor of the previous SDK, and allows for easier
configuration of credentials through the `azidentity` package.
Signed-off-by: Hidde Beydals <hello@hidde.co>
- Ensure key source follows upstream SOPS contracts as closely as
possible (e.g. `MasterKey` interface).
- Prevent unnecesary FS operations by allowing token creation and
and authorizer configuration to be factored from file bytes.
- Ensure a limited number of configuration option is taken into
account, excluding e.g. file path references.
- Ensure server maintains backwards compatibility with previously
supported "global" Azure configuration, _without_ relying on file
assumptions and/or inspections (but rather, server configurations).
Signed-off-by: Hidde Beydals <hello@hidde.co>
If implemented, the kustomize controller will be able to retrieve a
secret containing a VAULT TOKEN and use it to decrypt the sops encrypted
master key. It will then use it to decrypt the data key and finally use the data
key to decrypt the final data.
Signed-off-by: Soule BA <bah.soule@gmail.com>
We do not support encrypted PGP private keys hence the prompt function
logic can be reduced to signaling an error.
Signed-off-by: Aurel Canciu <aurelcanciu@gmail.com>