Plugins Part 1

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 »

Video Transcription
in this lesson, we're going to talk about the vault concept of plug ins.
When we look at the vault architecture diagram
and I'm taking reference to plug ins,
I'm gonna talk about three different kinds of plug ins and how they fit into the overall vault model.
Specifically, secrets, engines, that type of plug. And these are the things that store generated. Encrypt the data
we're going to review off method plug ins, these air the things used to perform authentications against different data sources and in different methods in ways.
And finally, we're gonna talk about audit device plug ins and how we get vault toe log data to different sources so that we can keep track of and make an accounting for all the different operations that are performing. Specifically, it's going to be looking at logging all of the authenticated interactions with vault.
So if you have the depth server running from a prior lesson, I ask that you kill it now and then we're going to start it over again. So it's fresh. Ali in memory data is cleared and we have a clean slate, and I'm going to jump over to a separate terminal window.
Don't forget. As a first step, we want to be sure to export the vault address. Since we are in debt mode and it's not doing TLS.
What I'd like you to do now is run a command called Volt Plug in. This is used to manage the different plug ins register and de register off the bat. We can see from the output that the plugging catalog is divided into three types off database and secret databases. A special offshoot of Secrets Engines
will be exploring those a little bit.
And then we talked about off and, of course, the secret plug ins here.
In fact, if we jump over to the get hub page, we can get a full breakdown, this link to the secrets engines from the Hash Corp documentation that shows us more details about each and every one of the different secrets engines over here on the left.
I encourage you to give that a look over. We will be experimenting in later lessons with some of the
different secrets engines, but certainly we will not have time to cover and use all of these different secrets engines in this entire training. If we take a look at the life cycle of the secrets engines we see there's enable disable move in tune.
We're gonna go ahead and work with the 1st 3 Tuning is for particular types of secrets engines that have the concept of timeto lives based on the secrets that the secret engines themselves are generating, having a limited life and at least expiration. And so tune is the mechanism you're going to use toe,
configure, tune and tweak
the time to live for those kinds of secret engines
moving back to the command line.
Let's go ahead and enable the secrets engine.
If I go vault. Blufgan list secrets.
I see a variety of options. So far, we've been using the Key Value Secrets engine, and so that's registered with vault. Using the term KV.
Let's take a look at the secrets engines that are currently enabled in the Vault Dev Server Fault Secrets list.
We can see 34 Excuse me, cubbyhole Identity secret and assists
secret and you can see the type Cavey Cubbyhole Identity will be covering cubbyhole and identity and later lessons and more in depth. For this example, we're gonna work with the key value secrets engine.
If you ever have question about any one of these particular secrets engines and want some more details from the command line, Vault has 1/2 help command that will be very useful when you are exploring the different things. Excuse me involved
So in this case, I want to say and explore and understand further. What's it? The path secret I run vault help you get a nice description reiterating to me, This is the key Value store, giving me some information about the key ValueAct back end. This pattern is continued with other areas and pads with involved as well.
If we were to go path help
assists, which is a default mounted path. We get a whole lot of information because that's the path used for managing the vault servers, system level information. Getting back to our main objective. Let's go ahead and enable secrets Engine
baby by running the vault. Secrets enabled Cavey command.
And so what this did list
is it enabled the secrets engine, but it enabled it at the path of Cavey as opposed to at the path of secret with involved every mountain engine authentication mechanism. All these different plug. It's they get mounted with a path, and that path has to be unique
to one particular engine. But you can have multiple instances of the same engine mounted two different paths. So if I want amounts to a specific path,
enabled the Cavey engine. But let's attempt to enable it to a path called secret. And we can see here. This is already enabled.
We're gonna get an air because we can only have one path. And this is where the vaults path routing mechanism. It looks up to determine when I get an incoming request, where do I hand it off to which plug into invoke under the covers? You'll notice that I use the dash path arguments. And by doing this, I'm able to mount a secrets engine
to a non default location. When that I specify.
So we're gonna go ahead and play around with this a little bit more. Um, let's try and mount the same key value store engine, but to a different path. In fact, moving forward. I'm going to try to add some flavor to these examples when we talk about secrets and managing secrets, and instead of the generic food bar
and some of those user one type stuff.
Let's let's think about James Bond and Double 07 He's He's the master Secrets, right? The British spy that's very famous in countless movies and books and comics. And so let's create a storage area that's going to be used in our vault instance to manage the keys
and the key values that we want a store on behalf of James Bond, who is Agent Double 07
And if we attempt to organize our key vault engines using some hierarchy to our paths that that's certainly a good idea when we grow our vault server and we have to have lots of different secrets engines, and we want to create some level of organization to them.
But if we try to do it and mounted to a sub path underneath secret, that's not going to work because secret Slash has already been mounted to the key vaults secret engine, so anything below that
path cannot be mounted as a secrets engine. However, if we change our path up and maybe we decide okay, let's create a specific key vault engine for the episode of Skyfall in that particular James Bond mission
is gonna work. And then we say, You know what? We want to create a separate key value engine for his other mission. More recently, Spectra. In fact, we can use the description tag and at a little bit of ah, more information for ourselves,
just for internal documentation.
Assed to what? The point is off this key value store secrets, engines. And so we have the description there, and they're both enabled. And we want to give this just a look. Make sure everything worked secrets list. And here we go. We can see we have the double 07 skyfall.
We have double 07 Spectra, which has the description because we passed and use that argument.
We sell of secrets and then Katie, which is mounted by default.
Another thing that could certainly happen in the course of using vault, as as you mount different secrets, engines and off message and so forth to particular locations. You may want to move that if you change your mind or wanna reorganize the structure and the way you are the hierarchy of mounting your secrets engines.
So we're gonna go through that real quickly.
That's also using the vaults Secrets Command and is using the move operation. So we're gonna move double 07 skyfall to double 07 gold and I
Sure enough, the secrets engine has been moved. And if we go ahead and wanna verify that we do a list and see now there is no longer a skyfall. But there is a double 07 GoldenEye
rounding out the key commands for vault secrets engines. Let's go through the process of disabled. We've done a enable we've done a move. Now let's do the disable. And similarly, it's gonna be the vault secrets. But now it's a disable sub command, and then again, you're going to give it the path to the secrets engines as its mounted.
And in this case, I want to go ahead and I'm gonna disable
the golden Eye Secrets engine when you disable the secrets engine. Um,
first of all, we're not we're not seeing a confirmation that it existed, but we do know it existed for something to note is that any secrets related to that secrets engine are lost, and if there are any dynamic secrets secrets with a lease and a time to live that were distributed by vault.
Those will also be automatically revoked and destroyed. So when you do disable the secrets engine, if you really want to make sure you understand the implications of doing so.
Up Next
Plugins Part 2
Basic ACL Policies
Basic ACL Policies Lab
Entities, Aliases and Groups Lecture
Entities, Aliases and Groups Lab