How do client applications authenticate themselves against Vault?

Transcript

This is, in some sense, the million dollar question for Vault. What would be bad is if we centralize all of our secrets in a system like Vault, and anything that can reach Vault or talk to it over the network could request anything it wants out of it.

Instead, Vault requires anyone connecting to it—whether a human operator, or an application—first login, and authenticate themselves against Vault, so that Vault can establish the identity of either the operator, or the application communicating with it—so that it can distinguish, are you a web server, are you a database, what level of permissions should you have?

This question, how does a client login against Vault, becomes critical.

Vault trust model #1: Platform integration

In practice, there are really two fundamental approaches of doing it. The first one is what we call platform integration. The way platform integration works is I have, let's say, a web service that's running on top of Amazon, and that web service needs some way to connect and authenticate against Vault.

The way we get this to work is a three-way trust relationship. Vault starts by being configured to trust the underlying platform, let's just say Amazon. The underlying platform then provides a credential to the underlying VMs—in the case of Amazon, it might be providing an IAM token on launch to the machine through a metadata URL, and then the web server provides that token to Vault, and then Vault is able to complete the chain. It basically can use that token to call back against Amazon and verify the identity of the caller.

In this way, we're building a three-way trust loop:

1. Vault trusts the platform,
2. the platform launches and provides a credential to the application,
3. the application provides that credential to Vault, which can be verified against the platform, completing the loop.

This platform-based integration works with all of the major cloud providers, systems like Kubernetes and Nomad, where there's this platform piece that's being threaded through to provide identity to the underlying application.

But what do we do when we don't have that? What if we're operating on a platform that doesn't thread through some form of identity—say bare metal, or for example, a VMware-type environment—where we're not getting something from the underlying platform?

Vault trust model #2: Trusted orchestrator

The alternate approach can be categorized as what's called a trusted orchestrator. The way that works is similar to when you onboard at a new company. The first day I show up for my job at HashiCorp, I don't have any login credentials, right? I'm not a member of HashiCorp yet, I'm just a random outsider.

What usually happens, is get met by someone in HR, and that HR person says, "Okay, well you have a job offer, and this is your name, and you're expected to be starting today, and your picture matches what you look like, here's your initial login credential." From there on, I can change my password and change my credential, but I was securely introduced to the company by someone in HR who already works for the company. In that sense, the HR person is a trusted agent of the company.

The way this translates to Vault is we have a trusted orchestrator, which is acting like the HR person. This trusted orchestrator is already authenticated against Vault, and it's hitting something like VMware and saying, "Please provision me a VM." When that VM comes up, the orchestrator expects it, we just asked for a VM to be provisioned. It's kind of like checking against that job offer in a sense.

Then the orchestrator connects and SSHs in, or injects a credential that that new machine can use to authenticate against Vault. It's like providing that initial credential.

Then from there on forward, that credential that just got injected is used to talk to Vault. Now we've securely introduced this new thing and provided a credential it can use to talk to Vault longterm.

Vault authentication models in a nutshell

There are these two fundamental models:

• Is there some ability to integrate with the underlying platform, and expose some sensitive token, or credential that we can thread through, and then Vault can establish a trust chain?

• Or, do we leverage a trusted orchestrator like Terraform, or config management tool, which is already trusted and has a relationship with Vault, and is injecting a credential that we can then use to authenticate this application?