Cubbyhole Secrets Engine

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

4 hours 53 minutes
Video Transcription
in this video, I'm going to introduce you to a new secrets engine called the Cubbyhole Secrets Engine and will figure out why you want to use it. What it's behaviors are as it's a building block for some of the subsequent lessons in this particular module.
Well, what is a cubbyhole here? We have a nice picture of elementary school. I went to the school in the US This is pretty standard and typical kindergarten first grade kind of classroom setting. You can see also hard work and desks and all that fun
these things. Here in the back of the wall, is little square boxes. These air called cubbyholes and every kid is told. Put your backpack in the cubbyhole, some books, your lunch pails, whatever it because not everything is gonna fit in the desk. And they don't want junk flying around, and each individual is given a cubbyhole
well involved. It's a similar process, but you're not putting your lunch pail in there. Obviously,
you're using it as a short term locker, and every token that is assigned and distributed has its own area, its own cubby hole that it can use to store secrets and the secrets in that cubbyhole are only accessible by that particular token, and they only exist
for the lifetime of that token. So once the token expires
or it gets revoked, all of the secrets and content put into that cubbyhole are deleted. So it's almost like an in memory kind of a transient way of managing secrets, which is very different than the key value secret store, where we looked at how you can control access to policies
but many different people with many different authentication tokens.
As long as they're associated with the right policies and they have the rights, they can see the secrets that exist in that key value store. So let's jump over to the command line and play with this cubbyhole in its most simplistic form.
The moment I'm already logged in, I'm going to do the vault token. Look up command. Here, you can see I'm the root user. So she with the root policies,
let's go ahead and create a new token. And we haven't worked with the vault token sub command, but it's pretty straightforward. I'm gonna create one. I want the command, the token to be created, such that it's associated with the default policy because, as you would imagine, the default policy. This cubbyhole
is inability that people associated with the default policy have the rights to interact with.
I want to set some restrictions, however, on this token, like maybe let's say, ah, use limit is two so it can only be used twice. Give it a time to live. We could say two minutes a very limited T t l. And then you can specify a display name if you want.
Let's call it a limited
use token.
And so this gives us the token value here and for the next two minutes, this is going to be a nice token to use. So in order to ensure I'm running the next few commands with that token, as opposed to with the the Route token, which my default is set to right now
I'm going to specify vault Token equals
and then I'll give it the vault command so we'll save vault right. Let's go to the cubbyhole. Let's just create a secret, call it daily and will go the message. This'll message will self destruct. Yes, I realize that is not a James Bond that is a mission. Impossible,
but let's go ahead and use that. So we've done the token. We've set the message. Let's go back now and read that particular secret read Cubbyhole Flash daily.
Sure enough, we can get the message back now. We set the access to two and in two minutes. So let's try it one more time and we have an air. Let's do a quick exercise to prove that the root user himself would not have the ability to access this particular
secret because it is associate with cubbyhole. In just one particular token,
I'm gonna clear the screen. Let's go back to create, gonna create another token. In this case, there's a token I d Let's go with the right operation. We're going to write same message. New token. I d.
Okay, we wrote it. So now if I go involved token, look up, right. I am the root user and let me perform the read operation
the Cubbyhole. But I'm not going to specify a token so that I'm performed this operation as the user. And sure enough, there's no value found because the items in that cubby older only for that particular token and that wraps up this very short and brief lesson on cubbyholes. Secrets engine.
We will be leveraging the secrets engine in the future
Modules here. Uh, what did we learn, though? Well, we learned a few new things as well Beyond just the cubbyhole secrets engine, Right? We talked about creating a limited use token and some of the parameters that we can provide because keep in mind, the short of the life to the token,
the shorter the life to the access control were thinking about security here.
And if we have short times toe live, even if a bad actor is able to get their hands on these different tokens what they expire quite quickly, that's gonna put them in a very much of a different disadvantage when they're trying to perform anything malicious, exploit any sort of data, lex filtration or whatever they may want to do.
Then we did talk about storing secrets in the cubbyhole
for the particular token. And finally we proved out that the tokens can expire through either the timeto live or use limit. In our case, we said it's a very low use limit of two. Well, glad you could make it through this quick video. I look forward to exploring vault further and coming videos
Up Next