Welcome back. As we continue our exploration into secrets management in Vault.
In this particular video, we're gonna talk about the APP role, which is an authentication method.
We're gonna set it up, we're gonna authenticate against it with a make believe application, and we're gonna access secrets. And then we're gonna review some of the more secure methods for distributing the keys that an application would use when it's authenticating to vault
Visa vee the APP role authentication method.
What is this app? Parole method intended for unused for It's really when you're authenticating applications and services. Right? Early on, we were using the authentication method of user pass, and through that, we were able to get our token.
But if you are running a Jenkins machine, let's say, for example, and that needs to communicate with vault to retrieve certain secrets or you have kubernetes the master. It wants to retrieve secrets from vault, which it would then inject into docker containers or
any of the many other applications. A docker container itself
will want to retrieve certain secrets from vault so that it knows how to connect to the back end persistence database, for example, these kind of applications that are running the services right. These aren't human beings. How are they going to authenticate? That's the APA rolls sweet spot.
And it does so by looking at in managing two pieces of information. One is the role I d.
So you register. You give the name to an application, and that application has its own role, i D. And then the other key piece of information is a secret i d. And that secret i d can be multiple. So the secret ideas associated with the role I d.
You need both of these pieces of information to authenticate with the application off
method, which is kind of like a take on the Shamir's secret sharing with the whole ceiling and unsealing right where you needed multiple keys to unseal in and recreate the master key. In this case, you need multiple keys in order to have that app authenticate
with vault and then get its token and continue to to
do whatever necessary interactions that the policy allows it to do.
Here's a diagram, courtesy of Hash Corp that does a good job explaining the application process and how comes together. You have an administrator over here on the left. They're going to go ahead and set up the the different the off method itself.
They're going to define a particular
application, which gives him a role I d. They're going to generate a secret I d. Than they will be delivering the role I d end the secret i d. To the application and service in some way will go through those a little bit more detail here than the When the application starts up, it
reaches back devolved and says, Here's my role idea. Here's my secret I d. And then vault, of course,
returns this token itself, which the apple then using in subsequent conversations with vault.
So let's hop or two the command terminal and the first thing we're gonna want to do is enable I'm logged in his roots again involved Token. Look up! Am I have all these great privileges I wanna go ahead and Mabel the off
AP role because it is not enabled by the fault on the Dev Server so enable half role
included in the polito Rory. You will find a policy for called Daily Digest a policy file. Very simple. So let's go with the Here's Here's the scenario, right? Um, que the fellow who makes all those great gadgets And it is an amazing hardware engineer
has decided to get into software and into creating mobile laps
because Agent M wants to be able to send daily digests to all her secret agents that are out in the field. And so what she said is, I'm gonna put these daily digests. It's gonna be a secret involved because we want to be very secure and how he managed this and who gets access to this.
is what's necessary for the agents out in the field to read Agent EMS, Daily Digest permissions. And so we want to create the vault policy
for the Daily Digest. And so we'll just call this policy itself Daily Digest, and we will pointed to this file.
And the next thing we need to do is update the APP rule off method with information about this particular application that our Buddy Cube
has created during his software endeavors.
So here we are going a right app roll, and then I'm gonna call us the Daily Digest Reader call that the name of this particular application and there's a few different parameters that need to be provided into this command.
We're going to go Daily Digest. So there were saying Whenever you make a token, you're gonna have these particular policies. Then we can specify the T TL off tokens to be one hour and it can be renewed the token.
But we're going to say that there's a max
of four hours so you can renew this one our token, but four hours launches four hours old. Forget about it. And then the name of this particular role is going to be queues Digest reader app.
And so with that done, I want to take a little pause because there were a few important parameters there. And if you're following along in the get hub page, you'll see I included a link for this particular section to the APP parole ap I documentation and don't intend on going through it.
But here you confined full
breakdown of all the different parameters that can be passed to the APP. Roll off. A authentication methods in is, um when you're defining a new Aperol, so this will allow you to do a variety of things such as
limiting to certain ciders. So saying you can Onley Not only do you need to have secret I d in the role i d but their request incoming needs to be coming from certain i p address. I peed Address ranges, right. Things you can do to
further lock this down as you need it. So definitely take a look at this
when you're building out in adopting the APA roll off method.
Okay, So back to our fictitious example With Q and his app lets say way have the message the Daily Digest message of the day from Agent M. And so let's put that into this key vault location that Agent M has decided to store all her digests
Daily digest. This is the key. So the key is going to be the message in the value of the key for today is gonna be take the bloody shot a very famous quote in one of the, um, double 07 films.
And at this point, we have everything set up that we need to start simulating as if we were the application. But we're gonna need to get a little more information So let's go. Vault read. And let's figure out what is the, um,
for the Daily Digest reader application.
What is the role? I d right. We need two things. We need the role idea in the secret 80. So there's the rule. I d take a little mental note of that copy paste that yours is going to be different cause this is a uniquely generated I d. For every server and every role different haps, you're gonna give them different names. They're all gonna have a different role. I d.
And then finally, what we want to do is generate the actual secret i d. We're going to do this little differently and that we're gonna force vault here to give us Ah secret I d Give me off app. Role rule
And now we have a secret. I d
as well. So we have the route i d. The role idea. Excuse me. And the secret I d.
With both of these things in hand, our application. Let's assume that it it knows both of these somehow some way, right? It acquired the role idea would be the kind of thing you could have persisted to a local credential store, for example. So if you're in Jenkins Ah, all these different
things, even even a mobile app, for example, has
the ability Teoh store certain information credentials in in a secret manner, Not fully top secret level, confidential right toe, not a full blown HSM, but it it's stored in a secret manner. So we're gonna assume that both of these pieces of information have been shipped.
Secret idea Good practice with Secret I D
is to create a different secret idee, per instance. So if in this case Q created ah mobile application, he could give a different secret. I d to each agent and they each have, ah, the app installed on their own phone. And it each phone has its own separate secret i d.
But they're all using the same role I d because they are the same application
interacting with vault.
So let's go ahead and get ourselves a token. It's gonna follow a little different approach here. We're going to use the moth app role log in extension, giving it the role I d is gonna be from appear.
And then, of course, the secrets
here we go, We now have a token so we can save evolved token. So we're gonna simulate some of the commands Once the mobile app lets say, has this token and it's established the session and it wants to connect and discuss things with vault specifically is gonna go vault
k v get Let's get, uh,
good old agent EMS Daily Digest Secret.
And sure enough, there it is. Um, and just to verify a few things here,
I can't even do a vault token. Look up and we can see. Here's the details of this particular token. It's associated with both the default and Daily Digest policies as well as other information.
So I kind of lost over
that. The two points in terms of we can have the role idea already defined on the app, or if you have a server right having the role I d defined in an environment variable or potentially even on the file system, that's OK, but because we need to different things
in order to authenticate with vault right, the APP needs both the rural idea and the secret I d.
So we want to make sure, though, that one of those has kept very much more confidential, specifically the secret i D. And here's where we start getting into that problem of how can we get the secret I d to a new server in a way that we we trusted her? How can we securely
go through the process of secure introduction and then do this introduction
in a manner? Well, we just talked about response wrapping as a method to
perform and in exchange, select amounts of key security information over maybe channels that we don't trust quite a bit, right? We're trying to give it to a trusted authority. We wanna watch. We want to make sure things were going well,
so let's go ahead and walk through this process.
But let's go ahead and let's do it using the, um, the secure wrapping method.
Specifically, how would we do that? So let's let's regenerate the, um,
Okay, so here's a new secret I d. That that's been generated, and our mission right now is how can we get this to the mobile phone? Maybe there's an initial pairing process or something like that. One thing we could do is actually wrap it so where
we last example. When we used response wrapping, we were just wrapping an access token within an *** excess token. In this case, rather than wrapping the authentication token, let's just try and wrap the secret I D. And this is a way that we can transfer this out to those agents. Maybe this is a,
ah server running a particular process. It's a micro service that needs to access vault directly,
as opposed to going other models of of getting information into these micro services. Maybe it's it's a jink and server that's going to be doing deployment or or some other kind of a C I server that's going to be doing deployment. And he needs access to a lot of the secrets. So we're gonna use the vault command,
right? And we're gonna contact this specific area
or a new assists wrapping rap,
and then we're going to say Secret I d equals. So what we're saying is wrapped this key value secret secret I d equals
sorry about that misspelled rapper. It's actually wrapping
cysts, wrapping rap secret I D. And so what this has done is it's given us of wrapping token again.
But in the cubbyhole of this wrapping token is actually not another authentication token. Rather, is this key value pair so we can demonstrate this by going vault on rap
token in this case lasting five minutes, by the way, as we can see and we will paste in the wrapping token here and the value is not a token and access token, rather, it is the secret I d. So our application
we could be sending this wrapped token to our application, giving in a minimal amount of time to go through the unwrapping process.
And then the secret idea itself can be held in memory of the application. So every time it boots, we send it over a rapt response using this strategy rather than trying to persist both the secret I d and the rule i d.
Two disc or store it in some text file or something like that.
It was a very powerful approach to managing secrets and starting the process of secure introduction and really limiting the exposure. You have to secrets, using a variety of methods in terms of minimizing the amount of time
having auditing going on on the audit logs on the back end off vault, right? We didn't set up a not a device in this particular example, but on production environment, you definitely would want to do that. And you could do it such that it really monitors the wrapping and more importantly, the unwrapping processes and the time
between the unwrapping. And
does somebody try to do on unwrap procedure more than once, Right. This should really flag some kind of alert because in all reality systems shouldn't be attempting to do the unwrap once when their first coming up. This could be a sign that
somehow somebody is compromising, or at least trying to compromise and get into your vault in some way.
So what did we cover in this particular video here? Well, we learned about the APA roll method. What is useful for We had the fictitious Agent EMS Daily Digest application. We use the command line in interface to simulate what another
AP, where there is a Web app or a mobile app would do to communicate with vault in retrieve secrets.
And then finally, we applied some of our prior learning and used to the response wrapping technique as a mechanism to even more securely distribute the secret I. D. That would be used for that initial introduction in handoff allowing this application to communicate with vault.
Looking back a little bit further. What did we discuss in this entire module? Well, we talked about secret version ing. We learned about the cubbyhole Secrets engine. Then we talked about response wrapping, which builds on top of the whole cubbyhole secrets engine paradigm.
We set up the AP pro off method and we've brought everything together by using the response wrapping as a method of secure introduction Visa vee, the APP role authentication mechanism.