Ensuring Database Security in the DevOps Pipeline with Dynamic Secrets

The traditional “vault-and-forward” method for secrets management means a user or application authenticates to the vault and then gets access to the secrets they need. The fundamental problem is once those secrets are out of the vault, it is extremely difficult to ensure their safety.

In the case of an application, the ways Secrets can be leaked is almost infinite. There is the code your team writes, commercial or open-source code that you add, as well as libraries, plug-ins, and extensions that are required. Any of those pieces may get access to the secrets and not properly protect them.

They may leave the secrets in memory, duplicate them to the hard drive, save them to a database, expose them to users or other applications, or even include the Secret in the logs. Even if all the code is secure, then you have to worry about the server configuration and potentially even network configuration where vulnerabilities that may be present.

People can come back later to access the applications, databases, or tools the secrets are protecting

If humans need to get involved with the secrets, then of course they might write them down or put them in an insecure spreadsheet or even share them with other people outside of the vault. This is even assuming they are not doing anything deceptive. With all of these secrets, they have standing access to come back later (maybe even after they leave the company) to access the applications, databases, or tools the secrets are protecting.

Of course, our response to this is that we need to rotate the secrets. But that causes another set of issues and questions your IT team needs to answer. How often do those secrets get rotated? Who is going to do the rotation, both in the vault and the target? How do we track and manage all of this?

A different approach is to use ephemeral, or dynamic secrets. The idea being when DevOps tools, applications, databases, or humans need to access the vault for secrets that provide access to a target, the vault generates short-lived secrets with fine-grained access control. If these secrets are leaked, then any would-be attacker is limited to what they can do by the fine-grained access control and they’ll have a limited time to do it because of the short timeframe before the secrets expire. Not only is this far more secure, but it removes the hassle of trying to track and rotate secrets.

DevOps Secrets Vault is designed to securely store and manage your secrets for applications, databases, and DevOps tools. It integrates with AWS, Azure, and GCP to create and deliver dynamic secrets. Read more about dynamic secrets for IaaS platforms here.

Beyond the IaaS providers, another place dynamic secrets is valuable is with databases. Because most databases don’t have the ability to generate dynamic secrets or have an API, DevOps Secrets Vault provides an engine to enable this ability.

When the dynamic Secret is “read,” the DevOps Secrets Vault engine will create a temporary user in the database and provide those credentials back to Ansible. The idea is very similar to the IaaS use case, but now the policy is SQL access to a given table. When the time to live (TTL) is up, then the engine will delete the user.

The engine provides the additional advantage of working on a different network but allows the use of port 443 TCP outbound connections only on the firewall, which most users will already have enabled for web connections.

DevOps Secrets Vault supports dynamic secrets for MySQL, PostgreSQL, and Oracle databases, with MSSQL coming soon. To try this powerful cloud DevOps tool, download the free version today.