The Journey to Vault 1.0

Transcript

We’re super excited to announce the 1.0 availability of Vault. When we started Vault, almost four years ago now, the problem we started to look at was—how does an organization have a central place to define where all their secrets live?

As opposed to what we tend to see as a sprawl of secret material, from application source code to config management to configuration files to plaintext all over the place, you have the sprawled scenario of sensitive credentials living everywhere. And what we really tried to decide was—is there a way for us to bring that all central with Vault and at least provide a way to encrypt it, a way to have access control, authorization, and auditing, so we know who did what when.

So that was where we started with Vault. And along the way, what we realized was there was this much larger challenge in security, which is—how do we start to think about providing a middleware or a platform that we can start solving other security problems within the data center?

From static to dynamic secrets

So—although where Vault started was—how do we take static credentials, usernames, passwords, API tokens, certificates, and just put it inside of a central vault?—what we quickly found is, there are all these other use cases. For example, a challenge was applications putting encryption keys inside of Vault. And, from Vault, the application would fetch an encryption key, and the expectation was the app is doing some sort of cryptography to protect its own data.

It turns out that it’s a bad assumption that these applications get the cryptography right, or that they don’t end up leaking keying material, or that they’re actually smart enough to handle the full key lifecycle of versioning and rotation and decommissioning.

So we ended up introducing board capabilities to do things like encryption as a service with Vault. And this has now become a top use case for us—how do we stand up and provide Vault as a service to applications, such that they can leverage Vault to do data encryption, data protection, signing of transactions, verifying the authenticity of communication within their data center?

And from there we really expanded into looking at—how do we get away from static credentials entirely? This is really the core of the idea behind dynamic secrets: Instead of taking static along with credentials, just putting it in the Vault, how can Vault generate those credentials, automatically rotate them, and create this moving attack surface for us? So we’re not worried about—what if the static credential happens to get leaked? The goal of this dynamic secret capability is that when we request a credential from Vault, we generate one on the fly.

Over the years, Vault has expanded to support almost every common NoSQL database, every common standard RDBMS, messaging queues, cloud platforms, and much more.

Achieving Vault's core mission

As we talk about what’s important to us with Vault 1.0, it’s a few things. One is us feeling like—have we achieved Vault’s core mission of providing a way that developers can store their credentials, but then integrate them with their applications, their CI/CD workflows, and be able to deliver those credentials in an automated way? That we’re not slowing down the agility of application delivery.

That was the core mission. And I feel like, along the way, what we really encountered was—how do we scale that up to meet the enterprise’s needs? Part of that is challenges of multi-data center replication, part of that is real-time disaster recovery replication, part of that is more intelligent policies, with things like Sentinel.

As we look back on everything it took to get to 1.0, it’s both about feature completeness, but it’s also about ecosystem integration, about hardening and enterprise-readiness. But we feel like finally with the 1.0 release, we feel comfortable saying we’ve achieved all of those milestones.

We’re very excited to have hit this point, and excited to share Vault with all of you.