DEV Community

Danny Perez
Danny Perez

Posted on • Originally published at


managing passwords and other secrets across teams

A few years ago, I was helping a company get its secrets in order. There were secrets stored in Google Docs, in Chef, in git, in an OSX image stored in git, in email, in a file manually placed in a Jenkins instance somewhere near you. It helps to split out your solutions by common use cases rather than use one tool for everything so here's 4 things that your org might need a safe and secure way to do (because odds are they aren't right now). Disclaimer: I have no affiliation with any of these companies mentioned below.

  1. Have a way of sharing credentials internally including non-technical users. Use something like LastPass Enterprise, 1Password Teams to share things like admin logins and billing credentials. These services also come with an extension for most browsers to auto-fill your passwords on all your sites and you can still share them with groups.
    Things like database credentials aren't a great fit here, and belong closer to the machines that need to read them where your engineers can interact with them.

  2. Have a way of securely storing & sharing sensitive files including non-technical users. LastPass lets you save files, perfectly fine for things like zips containing SSL certificates and that kinda thing. It's not a good fit for sending things like sensitive PDFs.
    Google Drive/Dropbox work up to a certain extent, but lack good auditing features to know which files were shared with what users. Egnyte & Accellion offer paid services for this particular type of use case (and you'd probably have compliance/regulatory requirements) before you really need it.

  3. Have a safe way of sending secrets to someone else (not to a group). Some of your users will likely be sending over slack and then deleting the message - this is a terrible solution - but I'm also guilty of it - its just too easy. is a useful site that lets you send secrets using a one-time use link (and they can have a passphrase, and expire too). Vault can do "response wrapping" which lets you share a secret without you ever seeing the secret - not very user-friendly, but more dev-friendly.

  4. Have a way of storing machine-facing credentials somewhere thats not on your computer. This is where using tools like Vault or AWS Parameter Store make it super-easy if you're working in a cloud environment on a larger team. You can also go barebones and store them in git using git-crypt or using AWS KMS to encrypt secrets locally. You can always use Encrytped Data Bags from Chef, Ansible Vault, or Puppet hiera-eyaml if you're using one of those config management systems.

The last thing is figuring out a decent authorization scheme so that you know who has access to what. That largely depends on how well you can define "who", the different types of "access", and "what" are all the permutations of things people can have access to.

Top comments (3)

gwllmnn profile image
Grégoire Willmann

Thanks for the article.
If you have the infrastructure, bitwarden ( seems like a promising tool to securely share passwords between members of your team.

jeroka profile image
Esteban Rocha

I have been using KeePassXc, but this one looks very promising, thanks!

intricatecloud profile image
Danny Perez

Bitwarden definitely fits the bill, its great that you can host it yourself. Thanks for sharing

Timeless DEV post...

Git Concepts I Wish I Knew Years Ago

The most used technology by developers is not Javascript.

It's not Python or HTML.

It hardly even gets mentioned in interviews or listed as a pre-requisite for jobs.

I'm talking about Git and version control of course.

One does not simply learn git