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. Have a way of sharing credentials internally including non-technical users. Use something like , 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. LastPass Enterprise 1Password Teams 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. & offer paid services for this particular type of use case (and you’d probably have compliance/regulatory requirements) before you really need it. Egnyte Accellion 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). which lets you share a secret without you ever seeing the secret — not very user-friendly, but more dev-friendly. Vault can do “response wrapping” Have a way of storing machine-facing credentials somewhere thats not on your computer. This is where using tools like or 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 or . You can always use , , or if you’re using one of those config management systems. Vault AWS Parameter Store git-crypt using AWS KMS to encrypt secrets locally Encrytped Data Bags from Chef Ansible Vault Puppet hiera-eyaml 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. to get tips and lessons learned building applications on AWS. Sign up to my mailing list Originally published at www.intricatecloud.io on October 17, 2018.
