- A combination of sops[1] and AWS Parameter Store might be a good candidate for (4)
- (5) can be solved with AWS SSO / OIDC (also: platforms that offer OIDC, usually support that feature for free, and a variety of them can be configured via Terraform)
- For (6), there are solutions like Atlantis[2] for Terraform, but I am not familiar with alternatives for Pulumi and Ansible. Might be a good idea to spend some time and build a pipeline with whichever CI/CD platform you are using (bonus: GitHub Actions supports OIDC auth with AWS as an IAM role[3], no secrets nor credentials required!)
- For (7), you can create a separate AWS account and manage it with AWS Organizations (or not)
- For (8), 1pass[4] for any credentials that requires username/password combo (non-tech/breakglass account). Groups can be created to limit certain credentials to subsets of users
[1] https://github.com/mozilla/sops
[2] https://www.runatlantis.io/docs/repo-level-atlantis-yaml.htm...
[3] https://docs.github.com/en/actions/deployment/security-harde...
I never understand why people go all in on cloud based password stores or identify for that manner
You can encrypt sensitive configuration fields with tools like `mozilla/sops` [1], which will reach out to your KMS or secrets manager of choice to encrypt/decrypt sensitive fields on the fly.
This way, you are minimizing the splitting of state across secrets managers and your code. Your configuration is stored at code, code reviewed, and versioned, which has devops and security benefits of its own.
https://github.com/mozilla/sops
https://github.com/android-password-store/Android-Password-S...
Both are extremely useful secrets oriented git tools with support for things like PGP encryption. Both will encrypt with multiple keys too, making sharing relatively easy. The android pass app even manages SSH keys for pushing and pulling. There may be good inspiration in those repos, or even code you can borrow.
Also, thanks so much for making this: it is elegant and lovely. Keep it up!
Various IaC ecosystems have integrations for it. It's probably the best way to store secrets for Nix-based deployments, and there are also docs and integrations that pair it up with Kubernetes and Terraform.
Idk how many companies are really using keygroups, though. Probably in some of them, the repos are public and can tell you that.
i want my password manager to be decently transparent, because if i misunderstand its failure modes that’s a big deal.
anyway, i’m using SOPS now [1]. it comes with a different set of tradeoffs (doesn’t integrate with keyrings quite as well as GPG does), but it’s way more transparent and pluggable. i generate distinct pubkey/privkey pairs per logical user and i can grant any subset of keys access to specific secrets. so e.g. my desktop and laptop can decrypt my banking secrets, but my phone cannot. i have a nightly backup cronjob which has to run unattended: i encode my Backblaze API key to the `duplicity` user’s privkey, and can safely check the encoded key into public repos and such. it’s simple and easy to grok. more so than pass, IMHO.
Also, sops (https://github.com/mozilla/sops) works with gpg and so with Yubikeys.
Nice article, covers the basics well. Credential files seem like simplest way to go and are secure enough for most local uses. For anything more involved a secrets manager is probably required. I've been using Linux for a long time and hadn't heard about `keyctl`, thanks for mentioning it. A more flexible solution might be https://github.com/mozilla/sops
There is a Google Cloud KMS keyring (for typical usage) and a GPG key (for emergency/offline usage) set up to handle the encryption/decryption of files that store secrets for each application's deployment. I have some bash scripts that run on CI which are essentially just glorified wrappers to `sops` CLI to generate the appropriate `.env` file for the application, which is put into the container by the `Dockerfile`.
Applications are already configured to read configuration/secrets from a `.env` file (or YAML/JSON, depending on context), so this works pretty easily and avoids depending on secrets being set in the `ENV` at build time.
You can also, of course, pass any decrypted values from `sops` as arguments to your container deployment tool of choice (e.g. `helm deploy foo --set myapp.db.username=${decrypted_value_from_sops}`) and not bundle any secrets at build time at all.
Edited to add link to https://github.com/mozilla/sops and to also mention my surprise at that Mozilla is behind SOPS. :)
For example you can use sops (https://github.com/mozilla/sops) to store encrypted secrets in Git, using AWS/GCP KMS to encrypt/decrypt them (or encrypt/decrypt the encryption key), and have infrastructure automation that gets the secrets from sops and exposes them to applications as environment variables.
For standard password style secrets used by Ops, we use Team Password Manager. Which we chose about 5 years ago because it was self-hosted, the database was encrypted, and it had fantastic audit capabilities.
# Something in lines of this...
# TODO: Make sure the keyrings are on tmpfs, too.
# Something like export GNUPGHOME="/run/gnupg" && mkdir -p "$GNUPGHOME"
gpg2 -v --import <(echo "$GPG_PRIVATE_KEY")
gpg2 --decrypt --output /run/secrets/credentials.json lib/credentials.json.gpg
ln -s /run/secrets/credentials.json lib/credentials.json
If you host in the cloud that offers a KMS (AWS, GCP, Azure), a slightly advanced alternative is SOPS: https://github.com/mozilla/sops (you can use that with GnuPG as well)
For smaller orgs and projects, Mozilla Sops is really great:
https://github.com/mozilla/sops
It encrypts your secrets at rest using Google KMS, Amazon KMS, and various other cloud provider key services. You can then put those secrets into your code repository, cloud file storage, etc. and give your build pipeline a service account with the ability to decrypt the secret files.
Scales like crap, but is quick and dirty when you need it.
It supports GCP/AWS KMS, so as long as my GCP user account can read the keychain, I can decrypt the secret. Very simple and does the job.
It can be versioned if you use git, access controlled via the KMS access privileges, and easily plugs into other tools because it uses YAML. Simplicity is the killer feature.
BTW Mozilla's sops [1] is quite interesting. I've been testing this for a while now.
The initial trust problem boils down to trusting the API that controls the provisioning of your infrastructure. Failing that, you have to ask a human to manually authorize new nodes to retrieve secrets (that's how puppet approves new agent certs).