Secrets¶
Enola manages “secrets” (e.g. API keys, other tokens, passwords, etc.) by delegating to an external secret manager. The following ones are currently supported:
pass
¶
We recommend using pass
with GPG, ideally on a YubiKey that requires “touch” to decrypt secrets.
Enola will store all of its secrets as YAML inside the pass secret named enola.dev
, i.e. in ~/.password-store/enola.dev.gpg
.
This secret manager is used when pass
is available on the PATH
and $HOME/.password-store/enola.dev.gpg
exists.
On first use, you have to manually enable it once e.g. using pass edit enola.dev
with a first secret (in YAML syntax).
YAML¶
An insecure unencrypted plain text (YAML) file ๐ญ is used if pass
is not installed and available on the PATH
.
This file is must be in an OS specific configuration direction; on Linux it’s ~/.config/enola/azkaban.yaml
.
JVM Properties¶
If the secret is not found in the aforementioned managers, then JVM properties (AKA java -D...
) are checked.
Environment Variables¶
If the secret is not found anywhere else, then Environment Variables are checked as a last resort.
When setting Environment Variables to “secret” values, be aware that all child processes can see them.
Other¶
Support for other secret managers may be added in the future. Please open an issue if you need a specific one; like:
- GNOME Keyring
- KDE Wallet
- Support
age
(orrage
), withpassage
; for TPM, SE and YubiKey - macOS Keychain, on Apple’s Secure Enclave
- Cloud KMS (various)
- Windows
Which one is used is currently automatically determined. This may be made more configurable in the future.
Tests¶
Because Bazel changes $HOME
, the integration tests running under Bazel (BAZEL_TEST
) will read secrets from the file to which the ENOLA.DEV_AZKABAN
environment variable points. Launch such integration tests like this, as the test.bash
script also does:
bazelisk test --test_env=ENOLA.DEV_AZKABAN=/home/YOUR-UID/.config/enola/azkaban.yaml //java/dev/enola/common/secret/auto:tests
Note that Bazel will reduce the visible environment variables,
so if you quote $HOME
it would be expanded “too late”. It’s simplest to just use the full path to your home directory.
To run integration tests in an IDE, add this environment variable in the Bazel Test launch config. (Alternatively, when manually launching individual tests, you also just set a JVM property or environment variable, because it will ultimately fall back to those secret managers, even when running tests.)
In configuration UIs of IDEs such as IntelliJ, be careful NOT to accidentally include quotes!
PS: Note that this mechanism (erm, work-around) means that Bazel won’t be aware of changes made to this “external” file,
so it will not re-run tests using new or updated secrets if (only) the content of azkaban.yaml
change. TODO: Find a
smarter way by somehow making the external secret file part of Bazel’s build dependencies…
PPS: We test for the presence of secrets and skip tests if the required secret is not available.