The forked implementation did not have OpenPGP anymore, as it never
really worked. However, the upstream version still does but now allows
it to be disabled.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
As the forked code has been contributed upstream in a modified format.
We continue to inject our own default credentials in the key server if
none are provided by the Kustomization, to ensure we do not shell out
to `az`.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This updates `go.mozilla.org/sops/v3` to the `v3.8.0-rc.1` release of
`github.com/getsops/sops/v3`.
This (finally) allows us to drop our forked key sources, as they have
now been contributed upstream in a slightly modified form which still
allows us to maintain control over the used credentials in isolation.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
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>
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>
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>
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>