Easier management with the HashiCorp Vault Identity System

HashiCorp Vault’s Identity system is a powerful way to manage Vault users. It takes an abstract and agnostic view to the source of third-party identity information, but provides flexible ways to tie this information to Vault authorization grants. In this talk, Jeff will explain: - The design of the Vault Identity system - The power this system gives users - The design decisions, trade-offs, and features of the Idenity system - And the future roadmapped features of Vault that will build on this Identity system, including the long-awaited Namespaces feature. All of these features are driving toward the eventual ability to delegate administration of Vault to less technical users.

Transcript

Thanks. Hi there. Hi everyone. Really happy to be here. I wanted to talk today about something I think most people here, even if they are Vault users, don't know about and that's why the subtitle of this talk is "What and Why." Because there are a lot of things we build into Vault and it seems like there's about a year lag before people actually start to really use them. And Vault's identity system is one of those things. It's been around for a bit. It's actually used for some things right now, but most people don't even know that it exists.

Alright, first. What? Or what? So let me get super meta here for just a moment. What does identity mean to you, right? What is identity? Who are you? What do you do? What tribes do you belong to? Right, tribes, things like are you a university alumnus? Are you fluent in Dutch? Are you a contributor to Vault? Do you play rugby? Or it might be—are you a web server? Are you a database admin? A sys op? Are you a full time employee or a contractor, right? So, you have lots of tribes you belong to that we identify.

And really all this comes down to is, who are you? That's what those questions really all answer. You are kind of the sum collection of your parts. So, a random set of bytes is not who you are. You are a person. You're a machine. You're a service. You're not just your Vault token.

And in the real world, we categorize all the time. We organize and tag things. What's your role, your type, your function? What are your tribes? And we're good at it. We have things like database tables and they're relational. We can map between things. We have directory services like LDAP and Active Directory and all that kind of fun stuff. And that's all there to help us make sense of the people that we are and the people that are around us and the machines around us and all those kinds of things.

Why Vault needed a new identity system

But Vault's original approach to handling the idea of who you are is very token-based. It's this token-based approach. So, it's very simple. You have a token. Your token has policies, and you can go pretty far with this paradigm, but it does have limits. Shouldn't you have policies? Shouldn't your tribes? Why is it focused on just your token? And to illustrate this, I have an example here.

This is a little bit of a contrived example just because makes it easier to explain, but you can have many mounts inside a Vault. Here there are two GitHub Auth mounts and I can connect and I can authenticate with the same information on both and there might be two of them that are up there and I'll get a token from each one. It has policies X and Y. And a policy, if you don't know Vault very well, a policy is what gives you access. It's the authorization part. So, you authenticate to Vault. You get policies on a token and then, those policies give you authorization to access resources.

And we can do something slightly different. So, the difference between the previous slide and this one [2:57] is now you see the one on the right is showing policies Y and Z. So, we have X and Y coming from one. Y and Z coming from another. So, I can authenticate to one and I can get one set of policies. I can go and authenticate to the other one. I can be the same person on GitHub and get another set of policies.

But I'm Jeff on GitHub. That's who I am, right? GitHub knows this, but Vault doesn't. And why shouldn't I just have policies X, Y, and Z. If I want to do something with policy X, I have to authenticate through the left side. If I want to do something with policy Z that policy Z gives me access to, I have to go through the right side. Why can't I just get all of those policies together?

I am more than just my tokens. Vault doesn't understand who you are, right? It doesn't know. Right now it just says "okay, you're a token. You have policies, that's it." So, we've been working really hard to sort of identify not just how we can fix this, but also why do we need to fix this? What are the use cases? And I'm going to talk first about what we've done and then, I'm going to talk about why we did it.

So, for about a year, we've been integrating an identity system into Vault and every Vault system now, it's under Identity. It shows up as a secret mount. And yes, it's been a while. We've been working on it for a long time. We've been pretty busy with other stuff at the same time. We've added a bunch of other things. So, it's been ongoing.

But a lot of it also is that we really like to bake things in our mind before we add it. So, we put out the original parts of it, then we thought, okay, what do we need to fix? What needs to get changed? Originally, it actually went into enterprise only because it was only something that enterprise features used.

And then, that gave us a little bit of opportunity to sort of change some things we wanted to change and then now it's, as of 0.9, it's in fully open source. So, as I said, it's already there. Every Vault installation that's 0.9 and above has Identity. You just don't really see it at this point.

Vault Identity design goals

We had some design goals. One of them is reuse your organizational work. You already know about the people in your org. You might have LDAP or Active Directory. You might be using Okta or One Login or something like that. Somewhere, somehow, your people are already enumerated. They're already out there. We wanted to minimize the impact of another system, another place to categorize. We wanted to make that as easy and trivial as possible.

Another is trust the third parties you already trust. You are already going to Vault and saying, "Okay, based on this third party assertion, I want to give someone a token with these policies." That's what Vault does, right? That's how you get access to it in the first place. And that can be AWS, it can be GCP, it can be Azure, if you're using clouds, it could be Apple, it could be LDAP, it could be GitHub. There are lots and lots of ways you can do it. And it's pluggable. You can make up your own.

So, you already trust those orgs, so why not trust them for Identity information as well, right? They already know who you are. You're already using that same information to authenticate.

A simple workflow. We wanted to make it pretty easy. And part of what we thought about was, most people, if you're a very small shop, you're probably doing a lot of things manually when someone new joins the company. So, you might have to do things in more of a manual fashion. So, it should be something that you can do through our user interface or UI.

If you're part of a larger organization, you probably, when a new account is created, you probably have provisioning scripts. You have to give access to a bunch of different machines, maybe to source code repositories, add them to LDAP groups. So, it should be something that should be very easy to add into that, to integrate into provisioning scripts.

The last (design goal) is be Vault-y. I have a slide coming up that kind of explains what I mean by that, but we wanted to sort of look at it as—does this, internally to the team, feel Vault-y? And what that really means is the following...

Being Vault-y

It starts off with no magic. When you are writing a security product, when you are using a security product, you don't want surprises. You want to understand it. That's how you can trust it. If you know what it's doing, then you can feel like "okay, I know how it's going from point A to point B. I understand the mechanism involved, even if it's complex, it's still understandable. So, I can trust this thing." So, no magic is kind of a nice thing when you're talking security.

The next one is be declarative. That's a HashiCorp thing more than a Vault thing specifically. But we like things to be something that you can codify. Like infrastructure as code, policy as code, all this kind of stuff. We like things that you can map out.

Next up is avoid foot guns. So, we think about this a lot on the Vault team. Doesn't mean we always get it right, but we think about it. For those that don't know, a foot gun is a feature added to a product that makes it easier for the user to shoot themself in the foot. I don't know if that's too American, I don't know what the origin of that is, but basically, the idea being: if a gun is too easy to fire, you put it on your hip and you're trying to show off and it goes off and you shoot your foot. Things should be safer than that. You should try to make it hard for someone to actually do something that terrible.

And finally, avoid soft fails. So, soft fails might be something that you're not familiar with. But basically, a hard fail is something like—no, you're not allowed to access this. I'm definitively telling you no, that's not allowed. A soft fail is when you don't know because let's say the network is down. You have no idea. Someone is coming to you and saying, "I want to perform this function." And you're like, "Well, I don't know if you're authorized." That's a soft fail.

This is actually a really big problem in security and if you've ever had to deal with the public internet and certificates on the public internet in the last four or so years, CRL, certificate revocation lists and OCSP, which is the online certificate status protocol. Those are basically going the way of the dodo, and the reason is because of a soft fail problem, because what happens is if you can't reach a server to get the CRL or if you can't reach the server to get the OCSP response, you don't know what to do. So, in order to get around this, they implemented caching. Caching is usually three days and then they hard fail at six days.

So, if it's gone for six days, you're like, "Okay. I don't know what to do." Six days is a long time. Think about the damage someone can do if they get ahold of a certificate and you try to revoke it and it takes six days for people to actually figure out about that. You can make a lot of APIs calls in six days.

That's one reason that Vault is really our PKI back and we design it to use very, very short-lived certificates and then just rotate them a lot and that way you don't even need a CRL. If you can have a three-day CRL, just make your certificate valid for two hours and get a new one after two hours. Done.

Soft fail is a really big problem. So, that's something that we think about a lot. We want to not have soft fails involved.

The design decisions for Vault Identity

The design of Identity. It's three fundamental things.

• One is, an entity: that's a thing, a person, a service, that uniquely identifies something in the system.

• Then, we have a group. A group is very simple. It's a collection of entities or other groups. That's all that it is.

• Then, we have an alias. Alias is another (alternate) name for an entity or a group.

An alias, for instance, I am Jeff Ryan GitHub. So, that's an alias for my entity. And I am part of the Vault team on GitHub in my organization. That's an alias for a group. Pretty simple.

To give an idea of how this works, let's say that you start out with a GitHub Auth mount and I log in, my auth is approved. Great. Thumbs up. Now what? Normally we would say the GitHub Auth would say, for this user, they get policies foo and bar. And now that we've been plumbing identity through all these different backends, now it will say "here are the configured policies," if any and you may not even need to anymore and we'll go into that. And the entity alias is Jeff Ry and group alias is Vault Team.

Before we go further, I want to explain something real quick. For those that don't know. So, you might be looking at this and saying, "Okay, so you just go into your database and you add a couple tables, you add some relations. Dead simple."

Vault storage, Vault basically will run on anything. You can basically have pretty much any storage system be the backing store for Vault. And because it's encrypted, then it's fine. You can put it wherever you want. But that means that everything is super complicated. We don't have a database. We can't do relational queries. If we want to do something where we want to be able to run queries, we have to load all that into memory and put it into an index.

And we have constraints like DynamoDB I think caps out at 400 kilobytes per key. So, there are a lot of constraints that we have because of this approach. And that approach I think is one of the reasons that Vault's really successful. People can use the storage that they're already familiar with. We're not forcing them into a different storage, but it also means that we have a lot of constraints.

So, when you're looking at some of these things thinking why did it take you a year to put this in? Well, a lot of it is that we have to figure out things like, "Okay, how do we take potentially thousands of these entries or tens of thousands of these entries and short them out into 400-kilobyte buckets and actually make that fairly performant on login or on Vault start up time."

Okay. So, back to this example. So, we've logged in and now in Vault's core we say, "Alright, go up to an entity. If it exists, great. Perfect. If it doesn't exist, please create it. Create an entity that has some ID." I'm using A, B, C, D there just to be clear as it plumbs through. It's actually a UID is the ID.

"And for the aliases in that entity, we have an alias from GitHub that says Jeff Ry." That's my GitHub handle. And the next step goes and does a group. So, it says, "Okay, upsert a group," that asterisk. I'll explain there. So, upsert a group and it generates a group ID, makes an alias for it and then, also, make sure that this entity is a member of the group. And every time that you log in, it will actually update your memberships for that entity. Like, if you log in again and I'm no longer a part of that group, then it will take me out of those groups.

And the final thing is that then, we finally get out token and along with the token UID and any policies that might have come from, like foo bar, I should have put that in the diagram there. But along with that, you get an entity that's baked into the token. So, entities and groups are internal resources. They're things for which Vault is the source of truth.

Aliases are defined by external resources. They're claims that are made by third parties. They're identified by third parties. So, I log in with an API token to GitHub. GitHub comes back and says that's Jeff Ry and here are the teams that they're a part of. That's a claim that GitHub is making.

So, basically, you have an entity and you can have any number of aliases that you want where you go across, it can be across different mounts of the same type. You could say, "Hey, we're using both LDAP and we're using certificates. So, I want to actually make aliases pointing to the same entity for both of them." And you can actually do that. So, regardless of how you log in at that point, you're always mapping back to the same entity.

Trade-offs

As with all things, there are trade-offs to the approach that we took. So, one is that syncing is a really, really hard problem. I don't know if any of you have probably dealt with having to write syncing software, but basically the more things you have to sync against and the more that they can change in a given time and all sorts of other things make syncing a really hard thing. It's full of soft fails and it's really hard to know what do when for instance, you have one piece of data and you see that something has changed, but maybe it's changed in a way that you think is wrong. There's all sorts of stuff that comes with writing a syncing software.

That's why there are entire products that are built around syncing clients between directories. So, syncing is a really hard problem and we opted for simplicity and scriptability. So, we said, "Look, we could spend oodles and oodles and oodles of time writing another client to sync a local store against Active Directory or you already have scripts to do that. You already know how to do that. Just make it so that you can write a couple extra lines in your provisioning script and you're done."

So, you just work it in there and it's done and meanwhile, you're not going to have to have Vault spitting out errors in your log saying, "Hey, I don't know what to do now because I hit this error when looking at this record versus that record and it doesn't match and what do I do?" And then, have a bunch of new API endpoints to tell Vault what to do in those cases. It's not simple anymore. Right? Suddenly, it's very complex. There are tons of soft fails. So, we opted for this very simple approach. It's very understandable. It's much simpler in design. Good for security.

We don't create group aliases automatically. We're thinking of putting in a config option for this, but I had a little asterisk on that slide a little while back and the reason is because if you have 100 groups, but you only care about three of them in a Vault and they automatically populate, now you have 100 groups in a Vault, most of which you don't want. So, we're probably going to have a way to toggle that, but for right now, if you're trying to play around with it, you have to actually create the group aliases first and then once it's created there and it sees that alias exists, it'll start doing the mapping for you. So, just a little trade-off.

And the final thing is, as I said before, we don't have a database backing us. We have to do everything in a very K/V kind of way. It's not designed to be a directory service. There are some queries. They're fairly limited. We can expand that over time as needed, but it's really not a directory service. You want a directory service? Run LDAP. Run Active Directory. Run any of those. It's just not the same thing.

I don't have the structure of the entities and the groups here, but we actually have metadata that's a part of it and you can do some things to the metadata, but like we're still kind of working that through and figuring out what the use cases are. So, it could get more complex over time, but we want to really wait for customer feedback, and get some of things I'm about to talk about out the door.

Why Identity gives Vault so much power

So, why? Second part of the talk. That was the what. Now is the why. And I apologize. I'm going very fast, but I only have 35 minutes, so trying to make sure I can get a lot of state dumped. So, primarily, it lets us build a whole bunch of really useful things. There are a lot of things for which we had the ideas for them years ago and we couldn't make them work with just tokens. And we couldn't make them work with just policies. And I'll talk about some of them as we get to those examples, but we kept coming back to the idea that if Vault doesn't know who you are, not just a token, but doesn't know who you are, then we can't provably say that a particular user is doing this operation or authorizing this operation.

We do have some of these things that are useful. Some already exist. So, let's talk about some of these existing features.

User management of policies: This goes back to this redux of this approach from the beginning where I have token A with policies X and Y coming from one mount. Token B with policies Y and Z coming from the other. So, now, we can go to this approach where you don't even configure policies on the auth backend.

You just say, "Okay. From there, Jeff Ry," and maybe in Jeff Ry's entity inside Vault we'll assign policy X directly. He always gets policy X whenever he logs in. And then I'm a part of two groups and so we look and say alright, so Jeff Ry has policy X as part of his entity and belongs to two groups that have policies A and B and Y and Z. So, when I log in, my full set of policies is A, B, X, Y, Z and none of that was configured in the auth backends. It's easier management.

Enterprise MFA: We have an MFA system on the enterprise side that if you've only seen what's in the open source, the open source one was put in very, very early. It was a PR from a company and it's very, very limited in what it can do and how it works and you have to bake it into every single backend. The enterprise MFA system works on any path in Vault. So, it doesn't matter what kind of operation it is. It doesn't matter if it's a login path or not. So, it's a very, very flexible system and it supports, I think, four or five different types of MFA right now.

But we can use Identity here. So, this is a little thing showing how this is done [19:16]. Every mount involved has a mount accessor, which uniquely identifies it, is never reused. So, we're just getting the accessor from there, that's just a little command 'Vault auth list.' Get down JSON, do a little JQ magic. Then, we write an MFA method. We give it the mount accessor. So, that's the part of the alias that's tying it to that mount. So, we say this alias is for a mount and a name. And then, the format of the username is alias.name@myorg.com. So, what that's saying is when someone is required to use MFA to hit up an endpoint, then we take their token, we look at the entity, and from there, we take the mount accessor that's configured, we look at the alias that's attached to that and then, we use the alias name @myorg.com is the name to send off to Okta to push.

So, it's a pretty easy way. It's essentially a one-liner. You just have people start logging in and then, you have a one-liner to add an MFA method that you can use all throughout Vault because we know who these people are. Then, even if they log in multiple times, it's not tied to a token, they just keep logging in and it's there.

Whether to allow access via Sentinel: If you're a Sentinel user, we have this all baked in too. Things like Identity.entity.name is Jeff or sys ops. And there are reasons not to use name, which I'll talk about later. ID is always safer, but just as an example, you can do this in Sentinel right now.

And finally, control groups: If you don't know what control groups is (and you don't), it's something that's been in Vault for a while. It's even less well-known than Identity, I think, but it's basically multi-person authorization. So, the actual name of it is named after the GDPR requirement for multi-person authorization of various actions, which is called control groups in GDPR. And the idea is—here's like an ACL that kicks off a control group. So, it's saying if you want to write that value—in secret or foo—do a create or an update. Then you have to get two approvers and they can be from the managers and the leads group. You're not tying it to a token. You're not tying it even to a particular person. You're tying it to some member of those groups. That gives you a much broader array of people that can authorize a particular thing. If you don't know how control groups work, go look it up. It's pretty cool.

The Vault roadmap (and things they're thinking about)

Alright. So, it lets build a whole bunch of really useful things as I said. Some already exist. Some don't. I'm going to talk about some of the things that we're going towards that we're sort of like waiting on Identity to actually be ready to go for us to be able to actually put this out there.

And big caveat right now—HashiCorp doesn't give timelines as a policy in engineering. We don't give timelines and people say "when will this come out?" It's usually soon. So, the closest I'll get right here is I'll say things that are roadmapped. They are committed engineering efforts that we are working on versus thinking. Things that we are thinking about that we don't necessarily have roadmapped yet, but that are kind of on our radar where we've been waiting for Identity to really take hold before we can do it. So, no timing guarantees on any of this. That said, some of these things will appear soon.

Template ACLs with Identity information: So, for instance, delegating control over K/V space to a user—path secret and entity.id. Now, when someone logs in, they can always write to that part of that K/V store, and they get access to it. Just using their entity. It doesn't matter which token they have. You don't have to create a policy for it. It just works.

And you can do it even easier, but the security implications, that secret entity.name. Here's the security implication and this is why I'm bringing it up because it's something that you have to be aware of. Right now at HashiCorp as of a couple months ago, there were actually two Jeff Mitchells. We have 250 people at the company and we have two Jeff Mitchells. So, if you're relying on just name, Identity will force that name to be unique at any given time, but if I were to leave the company, then the other Jeff Mitchell could just become the same name, right? Because you can reuse it.

The ID will never change. The ID will never be reused. So, if you want to be sure, this can be very nice and very easy to say just use the name, but if you ever have a case where you might actually reuse a name, you should always use the ID. Bit of a security tip.

Delegating control over a K/V space to a group: What this will do is it will say, "For this given path, I want to test to make sure that this person is in a group. So, there's the ID. Then, if they're not a part of the group, it gets denied. If they are part of that group, then fill in the ID as that part of the path. So, we can test for name, you can do it for ID. So, this is a way to give access to a space to a particular group using ACLs, using Identity.

And you could do this kind of stuff pre-Identity, but you needed huge numbers of policies. For every group that you wanted to create, you'd start having to create policies and then go and change the policies every member of that group had for their particular entry in an auth backend. It quickly got to be madness and you could end up with thousands of policies to do this kind of thing. Any of that configuration doesn't cross auth mounts. So, if you wanted to actually to do this across auth mounts, you'd have to do it in each of those every time something changed and it just was a nightmare. So, it technically could be done, but nobody would do it. It was terrible. And this is a roadmap thing. This is coming.

Namespaces: This is actually, I think, the first time we're talking about it publicly. So, you're finding out here first. Namespaces are coming. This is a road mapped item. These are basically mini Vaults. They're sandboxes. So, you can see at the bottom, you have a default or root namespace. And then, you can have other namespaces that come off of it. You can actually have children of children of children if you want. And each of them have their own policies, mounts, tokens, and identity entries. It's gonna be cool. The team is like so excited to get this out. We've been waiting for it for forever.

Tokens locked to namespaces or child namespaces: As I said, that's part of what is in each namespace. And Identity groups can pull in entities and groups from other namespaces. So, that's something that Identity can do that you can't do with tokens. There are lots of reasons for this. We actually thought about a model where Identity itself was actually global and it gets really complicated and I'm not sure I have time to explain it, but basically, if you do cross namespace entities because of the way that the aliases work and trusting third parties, if you have admins in child namespaces that are allowed to administer their own mounts, they can actually kind of swap in whatever they want.

So, basically, we had to take that out. We had to say like "alright, we can't actually do it this way," but groups—you can actually just reference other Identity groups or other Identity entities and say, "you know what? If they want to make a call into my namespace, give them these policies that are assigned by this group." So, you can actually kind of do it.

Namespaces right now, if you're using ACL you can reach into children, but you can't go up the chain and you can't go across. So, this is a way you can actually reach into any namespace as long as they have authorized you. They've created a group locally, that admin, and said you know what? You can have policies. Just give me your entity ID or give me your group ID.

Plugin parameter flexibility: This is basically just a way of saying make Identity information available to backends. And this is partly roadmapped and partly things that we're still thinking about and it requires a bunch of various enhancements. So, in Vault 0.13, I think then as of now, if you're writing a plugin, you can make a query and you can get back entity information about whoever's making the request, and you can use that for things like keeping track of unique users if you need to do something like that. Which is nice.

You don't get the metadata yet because we just haven't figured out a use case and we haven't been asked and there are lots of other things where it's like okay, do we expose certain parts of information to the backends or not? And a lot of it comes down to if you don't think a plugin is trustworthy, don't install it. As with many things. But we're still kind of thinking through that.

But something I call the cert cert loop, which is really just a thought exercise more than anything else—the idea is let's say you're using a SPIFFE subject alternate name. So, you create a certificate initially, you pass through an application. The application uses that cert to do mutual TLS auth to get a Vault token. Then the auth backend says "I'm going to encode in the alias. I'm going to encode the alias name for this token in the entity. I'm going to encode your SPIFEE URI SAN."

So now, you have a token that has that. Now you have a certificate that has that as well. Then, you're authorized to go to a PKI backend in Vault and you're authorized to go and generate new certificates for yourself as long as the URI SAN is the same as the alias for your entity.

So, now you are using a cert that was given to you initially to get a Vault token, to get a cert, to get a Vault token, to get a cert, to get a Vault token, to get a cert. So, anyway. Like I said, this is a thought exercise, but it kind of shows what we're looking at. The reason I kind of like thinking about it like that is that it kind of shows that you really need both parts of it. You need to be able to say "how do I use Identity in a meaningful way, within a plugin to be able to get the behavior that I want and then, how do I do it as part of the authentication workflow as well?" And the authorization workflow. So, using Identity to get policies and then, using Identity to control plugin behavior. So, these are the things we sort of think about.

Then, we can say, okay, based on that, what are these use cases that are more realistic that we actually want to enable. Of course, we always very seriously take customer feedback and user feedback on GitHub and mailing list, everything else.

So, some customers use Vault tokens and lookups as a way of authenticating to resources. And we've heard this a few times. So, the general idea here is they'll say "okay, I have a token and I would like to go and mint a child token that has a subset of my policies with just one single policy. And then, I pass that token and I give it to a third party web server. That web server then calls Vault and says do a look up on this token and does it have this policy attached? If so, I'm authorized."

It's cool, but it's not lightweight. You're making multiple calls to Vault every single one of these times. And on top of that, it's really resource intensive inside Vault. So, writing a token, generating a new token is actually pretty resource intensive because again, not a database, so we have to write a data entry for the token, for its access, for its parent, and for its lease at a minimum. So, that's at least four writes. If you're using replication, then that turns into more writes because we have a write-ahead log. So, it's actually very expensive to keep on authenticating to Vault over and over and over.

So, we have things that exist out there called JWT and OIDC. They're fairly well-understood ways of asserting identity. They're signed. They can have expiration times. They can have start times. They can do all these nice things.

So, another thing that we're thinking of is can we allow controlled minting of tokens to contain identity information. So, essentially, Vault sort of becomes a proxy. And there are actually other products that are out there where all that they do is they proxy third party information into that product and to turn it into a JWT or OIDC token.

But the key difference here is that Vault is sort of half your source of truth and half not, right? So, Vault is using third parties that you already trust to come in and mint the identity information. Then, you're turning around and saying okay, now that you've ingressed that identity information and you refresh it every time I authenticate and it gets refreshed I believe every time you renew. Now that you have that information plus whatever an administrator has said, "hey, I want to go and add extra metadata or I want to create extra groups and assign membership."

Now, you're actually turning around and saying "now I'm gonna make Vault the source of truth for this kind of delegated authentication, or delegated authorization." So, you sort have Vault acting in a dual role there. But the nice thing is because JWTs carry a signature, they carry an expiration, you can say, "I want to do an authentication right now and I don't actually need it to live very long. I only need it to live for like 15 seconds. So, you know, let me just go and get a jot. I'll authenticate over here and then, I have a long running connection."

Or you can say, "there's a max lifetime set by the administrator of 15 minutes on a JWT, but I'm going to make calls over and over, so give me one that's good for 15 minutes." Then Vault can say or really anything can say, "Vault checked with GitHub and said 'yep, I am Jeff Ryan GitHub' and now Vault is encoded in here and check it out here. I'm a member of the sys ops group. Check it out."

Vault's path to delegation

Alright. So, wrapping it all up. Hopefully, I wasn't going too fast because it's one of those things where it's very easy to spend a lot of time talking about it, but there's also a lot of information I kind of wanted to dump. So, I was kind of trying to make sure I got through all of it. But Identity is this thing that, as I said, we've been building in for over a year and it's increasingly integral to Vault.

That's not just because of the features it enables, but because of the workflows it enables. So, yes, it enables things like in namespaces to have cross namespace groups. It enables things like the ACL templating that we looked at, but it's also policy management. It makes a lot of policy management way easier. So, we've really been trying to focus on, as we built this, how do we address delegation?

Delegation is one of the most asked about features like in all of Vault, basically. People have said to us pretty much since Vault's inception, how can we do delegation? How do we delegate administration? How do we delegate management? So, we've really been thinking about that specifically for a long time now and Identity is a big part of that. Once you actually know who someone is and once you can assign permissions to people or to things instead of just to tokens, then you can enable a lot of really good workflows around delegation.

Then, we have things like the ACL templates, which Identity is also very much enabling. That's another part of delegation. You can say anyone in this group has permissions and control over this part of a K/V space. That's a part of delegation.

The stuff we're doing with namespace is a big part of delegation. Even delegation of authentication. The idea that you can pull an OIDC token out of Vault using the information it verified, that's another part of it. So, delegation has been very much on our minds because that's something that people ask us about all the time and so, this is a big and crucial part of it.

And as you saw from the things that are coming up, we have lots of exciting things on the way that Identity really enables. And those are things you'll be hearing about more and more, especially probably namespaces, I'm sure we'll have a talk about that at some point. But this is kind of a very key part of where Vault is going and a key part of how you'll use Vault in the future and get away from only being known by your tokens. As the sign said before, I'm more than just my tokens.

So, thank you very much.