managing passwords and other secrets in a bigger team

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. onetimesecret.com 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.

It’s been hard to figure out what best practices are when it comes to doing devops on AWS. I’d like to help you figure it out too. Sign up to my mailing list to get tips and lessons learned building applications on AWS.

Originally published at www.intricatecloud.io on October 17, 2018.