How do developers, operations, and security typically use Vault?

Transcript

There are a number of different people who interact with Vault on a day-to-day basis, many of whom don't necessarily even know they're using a Vault system. They generally come in three varieties.

1. Developers

First, an application developer who's writing an application that either leverages Vault to store or retrieve data, or otherwise leverages a process that uses Vault, that leverages a system that sits on top of Vault and uses Vault to orchestrate its security workflow.

In our larger Vault enterprise environments, many times application developers don't even know they're using Vault. They're interacting with some other kind of API or system that sits on top of Vault that leverages the capabilities of secrets management, encryption as a service, and identity and access management within Vault to handle security tasks.

This is ideal for one really simple reason: As an application developer, you focus on—how do I securely store and retrieve data. So you invite the possibility of something called a side-channel attack. A side-channel attack is an attack where an adversary—a hacker—comes in and navigates around the cryptography that's used to protect data. They effectively circumvent the protections that exist to stop someone who isn't allowed to access data from accessing that data. Application developers, it's ideal in many cases if they don't necessarily know how to use Vault. If they do want to use Vault, they need to understand how the API in Vault works or the security tooling and infrastructure that surrounds Vault as a whole.

2. Operations

Other persona that tend to interact with Vault include whoever is setting up, deploying, and ultimately managing Vault. This is more of the DevOps-like function or SREs that are interacting with Vault on a day-to-day basis. For them, the experience is, again, heavily reliant on automation. Once you stand Vault up and start getting up and running, the times when you really need to access and manage Vault are when you're adding on new methods for authentication or otherwise configuring new types of secret engines for allowing you to store, retrieve, and access information that's sensitive and ultimately protected within Vault.

In that model, the focus is really more on how does one set up automation systems to handle routine curation and management of Vault. Then additionally, when they want to, how does one configure Vault to work with newly added components within their infrastructure?

3. Security

Then finally, there's the third persona, and that's generally anyone who cares about security as a whole within your infrastructure. How does one who is managing not just Vault, but an entire ecosystem of security tools, meant to protect a project, a team, or an enterprise leverage Vault within their infrastructure? They're probably not going to be interacting with Vault on a day-to-day basis, but the focus of what Vault is supposed to be doing there for them is minimizing that reputational risk that comes with something like a data breach or cyber attack.

In that model, it's less about on a day-to-day basis logging into Vault and managing Vault. It's more about being assured that Vault has the correct architecture necessary to protect against their threat profile and threat model.