5 best practices for secrets management
Dec 03, 2018
HashiCorp solutions engineering VP Jon Benson gives his top 5 best practices when using a secrets manager like Vault.
VP Worldwide Solutions Engineering, HashiCorp, HashiCorp
When you're looking at best practices for a secrets management solution, there are a number of ways that you can provide a safe and secure method for your users and applications to retrieve the secrets that they need to access the different systems that they need access to.
» 1. Centralizing your secrets
The first and probably the most important is centralizing your secrets. Right now, many secrets sit in version control systems like GitHub, like Bitbucket, like GitLab. They're sitting in Excel sheets, on Post-It notes under your keyboard.
What you want to do is centralize those, and the value you get out of centralizing those is it's easier to build governance, auditing, and security around who accesses those secrets, when they access those secrets, etc. By centralizing those into one place, you're able to much more easily manage the security around that.
Now common ways that this has been done in the past is putting them in databases. You're putting them in a KV store, which works fine in that you're centralizing them. But it's very hard to put access around it. So within Vault, we built not just a place to centralize those secrets in the KV secrets engine, but also a way to build access control around it.
» 2. Access control lists (ACLs)
Step two, now that you have your secrets centralized into one place, is ensuring that who's accessing those actually should be accessing those secrets. So building out proper ACLs of humans and machines, applications, who should be able to access what, and providing an easy way for them to gain access to the secrets that they need. So step one, centralize. Step two, make sure that you have proper access control around the secrets.
» 3. Dynamic secrets
Step three and step four, probably at the same time, is dynamic secrets and encryption as a service, both equally important. Dynamic secrets is the notion of providing temporary credentials to unique individuals or entities. So if I am a human or I'm a machine, and I need access to a database, or to AWS, or to Microsoft Azure, I want to be able to go to my central place, show my credentials, and retrieve those.
Now rather than handing out static, shared secrets that web app one and web app two that you spin up the next day have the same shared secret, I want to give each of those individual entities their own dynamic, temporary credential, so that if all of a sudden I shoot the node in the head the next day and it's gone, or my auto-scaling group takes it down, I want those credentials to be automatically cleaned up. Vault is a secrets management solution that will manage all of the different secrets that it hands out temporarily and clean those up after their TTL expires.
» 4. Encryption as a service
Now after you move on from dynamic secrets, and dynamic secrets can be any sort of credential you need access to, database credentials, IAM credentials across all the different clouds, etc.; encryption as a service is an important thing to do. When we talk about encryption as a service, it's providing a solution that allows you to encrypt data in transit and at rest.
By doing so, if someone were to get in your network and they grab data being passed around between applications, or they grab and get access to a database, what you're able to do is ensure that that's encrypted. And your encryption keys are, again, centralized in that secrets management solution so you can provide proper access control around who's gaining access to those keys. You're not exposing them outside of the secrets management solution. But you provide a nice and easy way for your developers to off-load the cryptographic operations rather than having to solve it on their own.
» 5. Auditing
And lastly, what you're looking to solve for is, how do I audit that? How do I see who accessed what? By implementing dynamic secrets, we know that every secret used was uniquely created for the requester. And we have that same requester who had authenticated into Vault, so we can see in the audit logs when they authenticated to retrieve this secret. You can see when the secret was actually used in the underlying subsystem that the credential was created for. For encryption as a service we can see who was accessing an encrypt or a decrypt operation. It gives us complete visibility into everything that's going on in our infrastructure.
In addition to that, because we have dynamic secrets, we're able to early-revoke some of those credentials that were handed out. So rather than having to roll every shared secret and taking production systems down, you can say, for this user or for this business unit, or for what have you, you can revoke all the different secrets. They just have to request new ones and you're on your way. It's a much safer way and risk-averse way to implement your secrets management solution.