Engineering · 3 MIN READ · DAVID MONTOYA AND ISMAIL AHMAD · AUG 31, 2022 · TAGS: Cloud security / Tech tools
We take protecting credentials seriously, and database (DB) credentials are no exception. They’re juicy targets for attackers and often hold the keys to all your sensitive information. Making sure they’re short-lived, rotated, scoped, auditable, and aligned with zero trust principles is central to boosting an organization’s security posture.
As you may know from our previous post, 5 best practices to get to production readiness with Hashicorp Vault in Kubernetes, we’re long-time users of Vault, which specializes in credential management and offers a large plugin ecosystem for different databases.
Sounds like a slam dunk right? Not so fast. As we began to explore using Vault to manage credentials for our Google-managed CloudSQL instances, we found ourselves stuck between two less-than-ideal out-of-the-box options, forcing us to compromise on operational complexity or, worse, security. Caught between a rock and a hard place, we dug deeper and built a new tool to meet our requirements. We think it’s broadly useful for organizations using Vault and Google CloudSQL.
And now, the good news: Expel is excited to open source a new Hashicorp Vault plugin. It brokers database credentials between Hashicorp Vault and Google’s CloudSQL DBs and it doesn’t require direct database access (via authorized networks) or that you run Google’s CloudSQL auth proxy.
If you’re wondering how that’s possible, the plugin uses Google’s best practice for authentication via IAM rather than a standard database protocol. Sound like something you could use? The plugin codebase can be found in GitHub.
Why build a custom plugin?
To better understand why we built this plugin, let’s look at some of the challenges posed by using Vault’s default database plugins to connect to CloudSQL instances. Per Google’s documentation, there are two primary ways of authorizing database connections.
Option 1: use CloudSQL authorized networks
Google allows users to connect to CloudSQL databases using network-based authentication. To improve the security posture of your DB, Google recommends enabling SSL/TLS to add a layer of security. This requires users to manage an allowlist of IP CIDRs and SSL certificates on both the servers and clients for the databases they wish to connect to. As you can see, this gets tedious quickly. Imagine you have hundreds of CloudSQL databases… no one wants to manage that many firewall rules or certificates.
Option 2: use CloudSQL Auth proxy
Google’s recommended approach for connecting to CloudSQL instances is to use the Auth proxy. Its benefits include:
- Uses IAM authorization instead of network-based access control (no more firewall rules!)
- Automatically wraps all DB connections with TLS 1.3 encryption regardless of the database protocol
As we started exploring approaches for connecting our Vault instances to CloudSQL databases, we contemplated using the cloudsql-proxy (but shuddered at the operational complexity of running such a specialized sidecar along with our Vault servers).
Developing a Hashicorp Vault plugin
So, how exactly did we end up writing our own Vault plugin? As we researched options, we landed on a GitHub issue that referenced an interesting new Go connector for CloudSQL. The Google Cloud team had recently released a generalized Go library for authenticating to CloudSQL databases the same way that their auth proxy does. Being Go developers, our interest really piqued–could we use this new library to get the best of both worlds (low operational complexity and security best practice)?
By creating a new Vault plugin based on Google’s Go connector, we were able to integrate Vault with CloudSQL databases all while taking advantage of Vault’s existing capability to create and manage database credentials. The plugin simply initiates the database connection using the new Go connector for CloudSQL instances and then delegates everything else to the community-supported Vault database plugin.
How to use it
Ok so you’ve made it this far. You understand what problem the plugin is solving and how it’s solving it. Now let’s talk about how you use it. A step-by-step guide to building and deploying this plugin can be found here.
Although “building a new way” often seems daunting, our journey with Vault and CloudSQL was rewarding and we hope our plugin will be useful to others facing similar issues. As we continue our journey, watch this space for future posts describing how to employ Vault as a database credential broker for workloads and audit across the stack.
Finally, have a look: we’ve posted a step-by-step guide on GitHub detailing how to set this up in your environment.