4 ms·

What are recommended tools for team wide secret management?

by jsilence 7y ago

endymi0n 7y ago
We‘re using gopass ( https://www.gopass.pw https://www.gopass.pw )
- janikvonrotz 7y ago
  Btw. this is a go implementation of pass https://www.passwordstore.org/ https://www.passwordstore.org/
  - rapnie 7y ago
    The git repo [0] says "All Rights Reverse Engineered" at the bottom. Is that just a joke, or has it actual meaning? [0] https://git.zx2c4.com/password-store/ https://git.zx2c4.com/password-store/
janikvonrotz 7y ago
For small teams use keybase https://keybase.io/ https://keybase.io/ for gpg key management and pass https://www.passwordstore.org/ https://www.passwordstore.org/ to manage secrets.
Kovah 7y ago
I can recommend using Ansible Vaults, and 1Password in addition to that. Ansible is quite helpful because all project secrets are stored in the local vault which is actually version controlled. The password for the vault can be found in 1Password.
tialaramex 7y ago
Although suggestions in this sub-thread are good, prioritise reducing shared secrets first. You can't eliminate them from most projects today, but try not to have more than you need. Use public key crypto in more places so that systems can ask "Was one of these authorised public keys able to authenticate?" (that list of keys isn't a secret) rather than "Was one of these secret passwords used?" For something like all of the engineering group need access to the same test account in your production system: Consider whether some customers might want to share access to an account too ("Disney Global Team" definitely wants this and even "Sally Smith" might if Sally's entourage of agents, managers and assistants are handling a famous person's "personal" account) -- and so add a feature for each of those engineers to have their own login credentials for the account instead of a shared secret, then it reduces to a secret management problem for individual engineers. While considering secret management also give a thought to HR termination checklists. Maybe sharing a single password is easier than building new shared account features for the product, but what happens when somebody leaves for their dream job? Gonna just trust that they won't tell? That's not a sustainable plan.
cjhanks 7y ago
I personally believe secrets management is not done in software. Systems should be fully constrained by networking logic. If you need to hide certain authentications; create expiring DNS records derived from a secret hashing function, have the source of the secret algorithm pre-installed, and then delete after connecting. Then disable inappropriate logging.
fanf2 7y ago
I use regpg which is a wrapper around gpg to make public keyrings easy to manage and share via git, with auditing features for checking consistency between recipients of encrypted blobs and the keyring. Plus a few helpers for working with encrypted secrets more safely. I would prefer not to base it on gpg but there weren’t any better options that I know of. https://dotat.at/prog/regpg/ https://dotat.at/prog/regpg/
drcongo 7y ago
We use EnvKey for managing server secrets. It's designed specifically for doing this so it's much less friction than trying to use something like a password manager for the job. Highly recommended. https://www.envkey.com https://www.envkey.com
gingerlime 7y ago
plugging envwarden[0] - free and open-source, and works with Bitwarden (also open-source) to manage your server secrets. Since we already used Bitwarden on our team, utilising it to also manage our server secrets was a no-brainer. [0] https://github.com/envwarden/envwarden https://github.com/envwarden/envwarden

What are recommended tools for team wide secret management?

endymi0n 7y ago

We‘re using gopass ( https://www.gopass.pw https://www.gopass.pw )

janikvonrotz 7y ago
Btw. this is a go implementation of pass https://www.passwordstore.org/ https://www.passwordstore.org/
- rapnie 7y ago
  The git repo [0] says "All Rights Reverse Engineered" at the bottom. Is that just a joke, or has it actual meaning? [0] https://git.zx2c4.com/password-store/ https://git.zx2c4.com/password-store/

janikvonrotz 7y ago

For small teams use keybase https://keybase.io/ https://keybase.io/ for gpg key management and pass https://www.passwordstore.org/ https://www.passwordstore.org/ to manage secrets.

Kovah 7y ago

I can recommend using Ansible Vaults, and 1Password in addition to that. Ansible is quite helpful because all project secrets are stored in the local vault which is actually version controlled. The password for the vault can be found in 1Password.

tialaramex 7y ago

Although suggestions in this sub-thread are good, prioritise reducing shared secrets first. You can't eliminate them from most projects today, but try not to have more than you need. Use public key crypto in more places so that systems can ask "Was one of these authorised public keys able to authenticate?" (that list of keys isn't a secret) rather than "Was one of these secret passwords used?" For something like all of the engineering group need access to the same test account in your production system: Consider whether some customers might want to share access to an account too ("Disney Global Team" definitely wants this and even "Sally Smith" might if Sally's entourage of agents, managers and assistants are handling a famous person's "personal" account) -- and so add a feature for each of those engineers to have their own login credentials for the account instead of a shared secret, then it reduces to a secret management problem for individual engineers. While considering secret management also give a thought to HR termination checklists. Maybe sharing a single password is easier than building new shared account features for the product, but what happens when somebody leaves for their dream job? Gonna just trust that they won't tell? That's not a sustainable plan.

cjhanks 7y ago

I personally believe secrets management is not done in software. Systems should be fully constrained by networking logic. If you need to hide certain authentications; create expiring DNS records derived from a secret hashing function, have the source of the secret algorithm pre-installed, and then delete after connecting. Then disable inappropriate logging.

fanf2 7y ago

I use regpg which is a wrapper around gpg to make public keyrings easy to manage and share via git, with auditing features for checking consistency between recipients of encrypted blobs and the keyring. Plus a few helpers for working with encrypted secrets more safely. I would prefer not to base it on gpg but there weren’t any better options that I know of. https://dotat.at/prog/regpg/ https://dotat.at/prog/regpg/

drcongo 7y ago

We use EnvKey for managing server secrets. It's designed specifically for doing this so it's much less friction than trying to use something like a password manager for the job. Highly recommended. https://www.envkey.com https://www.envkey.com

gingerlime 7y ago

plugging envwarden[0] - free and open-source, and works with Bitwarden (also open-source) to manage your server secrets. Since we already used Bitwarden on our team, utilising it to also manage our server secrets was a no-brainer. [0] https://github.com/envwarden/envwarden https://github.com/envwarden/envwarden