Having secrets sprawled throughout your system in plain text creates several roadblocks to application security. Learn what secret sprawl looks like, and how you can overcome it.
When we talk about secret sprawl, what we're first talking about is secrets themselves. What are secrets?
We talk about secrets as anything that gives us access to a system or allows us to authenticate or authorize ourself. Examples of this are a username or password, an API token, TLS certificates—any of these things we can provide to a database or to a cloud to authenticate ourself and then authorize us to perform actions—to read and write data from the database, to read or write from S3, so on and so forth.
These things are very sensitive because if I—as a third party or an attacker—get access to one of these secrets, I can use it to authenticate and authorize myself and do something that I shouldn't be doing. These mechanisms are really critical. Anyone who gets ahold of the mechanism can then authenticate whether or not they actually should be doing so or they're trusted.
That's what a secret is.
Now when we talk about secret sprawl, what we're really talking about is the distribution of these things. They're sort of all over. They're littered about our infrastructure.
What we classically see is: You have a database username and password that's hard-coded into the source code of an application. It's in plaintext in the configuration file. It's in plaintext in config management. It's in plaintext in version control. It's in a Dropbox and it's in a Wiki. It's sprawled all over our infrastructure in different places.
Challenges of secrets management
The challenge with sprawl is a few-fold:
So, secret sprawl comes with a number of different problems but it's really a lack of visibility and a lack of control, so this doesn't give us good answers when something happens. When we talk about secret management, the goal is to solve that.
The solution to "secret sprawl"
The first level answer is centralization. We need to move from stuff living everywhere—all over the place in different systems—to living in a single place where it's tightly access-controlled, tightly audited, it's encrypted so that it's not anyone who has access to version control.
Even if you have access to a system like Vault, we have fine-grain access controls restricting what secrets you have access to on a need-to-know basis. In this sense, now we have good answers around: If there's a breach, we have audit logs of who had access, and when did they have access. We can change it in a central place and distribute it to our infrastructure. It simplifies a lot of the lifecycle around this credential management.
Those are the challenges of secret sprawl and why focusing on centralization and using formal secret management reduces the risks associated.
Automating Multi-Cloud, Multi-Region Vault for Teams and Landing Zones
Adopting GitOps and the Cloud in a Regulated Industry
Portable CD pipelines for Nomad with Vault and Dagger
So My Credentials Have Been Leaked...Now What?