Plugins Part 2
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
took a little longer to cover the plug ins that I had anticipated to. This lesson picks up right where the last lesson left off. We have the vault of server up and running. We've mounted and created a key value store at Double 07 Spectra and we are sitting in
being as we've covered, mounting the secrets engine type plug ins and managing mills.
Let's go and take a look at the off methods, which are another type of plug in
referring back to our get home page. I have a link to the off methods
here. You can see the variety of different ways that off methods of off methods that vault supports for authentication.
And as you can see, we're gonna use in a second here, too, involved commands. It has evolved off command and, of course, to enable and disable the different
types of off methods. So let's go ahead and see how are deaf. Server is set up in the sense of the different off methods.
We're in the vault off command. It shows us a variety of sub commands. Amongst those is the vault awful list. This gives us an insight into the various off methods that have been enabled on the death server, and we see only one. That's the token based authentication. Of course, when the deaf server started, it provided just the root token. And we could
use this authentication message to
generate additional tokens, which are then distributed for used authenticate. But let's go ahead and see what other kind of options we have for authentication methods that air by default installed,
I use the vault plug and list off. It's showing me all the off plug ins that air installed on this instance of vault, and I'm gonna go ahead and we're gonna play around with the user pass
authentication mechanism. It's It's the most simplistic. If you provide a user name and password, it's pretty self contained.
And as a first step, we're gonna go ahead and we're going to enable
use your pasts
We're running a variety of these fault commands manually right now, as we change the configuration of our death server in a production environment, these will probably be scripted as part of your server provisioning process, so the server is going to get created. The vault binary is going to be installed, and then they'll be certain scripts that run
to configure and enable the various
secrets, engines, off messages and so forth that you have in your vault. So please keep that in mind that this practice that were going through and exploring and learning is not exactly how you're gonna want to be doing it in a production riel world environment.
And with that said, Let's go ahead and now view the variety of off message. And sure enough, the user path user pass off message has been enabled.
First thing we want to do is let's perform an operation, create a user account,
going with our theme of James Bond and double 07 Let's make the user J Bond double 07
And there's a few other provisions and parameters we need to provide one. Creating the user account. We want to give it a password. So let's go with, uh, shaken.
And then we want to assign a policy in that policy,
or policies are going to be driving the capabilities that this account has when it's been authenticated and when it's interacting with vault. So we're going to cover policies in more detail in coming lessons. But for now, let's just use the default policy
with that. A success. Let's go ahead and log in to vault,
using the user passed off method,
and we need to pass the user name token, which is gonna be we're gonna authenticate his James Bond double 07
And our password is going to be shaken.
Success. So now we are no longer authenticated and performing interactions with the vault. Using that route user, which was based off of that route token and our capabilities, they're gonna be limited to what we are provided. Visa vee the default policy.
Let's talk about one more kind of plug in involved, which is the
audit plug in these air. The mechanisms. The audit devices, where you're gonna spit out the logs so as
interactions air taking place by authenticated users and their retrieving passwords changing system configurations. We're all getting it audited. And there's a few different types of
plug ins and ways that you can spew this audit output. It's all in a Jason format. Another important note is the audit lugs themselves, make an effort not to include sensitive information, and we're going to explore this firsthand in fact,
the sensitive information gets encoded using an H Mac
so that it's not Somebody can't just walk up to the file and look at it and say, Look, it says you updated your password and it also says what the new value of that password is right there in the autumn logs. That would be a huge security vulnerability.
And in this example, we're gonna go ahead and enable the file type audit log. So shoot back over to your terminal.
One thing we need to do at this point is re authenticate using the route token. Because this user, James Bond, he doesn't have the rights or abilities to enable the audit plug ins.
In order to do that, I'm gonna go back to the death server, and I'm gonna copy and paste the route token.
We're going to use the vault log in command again.
But our method is gonna be the token method
were prompted for the tokens. So I'm gonna paste that in here and now we're logged back in using the route.
So let's enabled the audit
faults audit enabled. We're gonna enable the file
audit log, and we need to provide one additional parameter here, which is the file path. So I'm gonna just dump this into my current working directory and it for the current working directory of the Vault server itself, which is the same directory that this client session is in.
We're gonna call it the Vault audit dot log.
Let's go ahead and create a secret so that we can look at the audit log and see the outcomes of performing the action.
In this case, let's go and make key value secrets. Let's give James Bond for his Spectra mission. Some details about the location and the city is going to be in Mexico,
So that's been written their blitz cat vault audit log
and we can see a whole lot of output. As noted previously, it's in Jason. I'm going to pretty it up a little bit, using the Jake you utility by by piping at all,
and we can see our most recent
activity that took place here was performing the operation of creating the local location, creating the secret here recorded the I P address talks about the token who was the client, which in this case is is the root client, So take a look at the logs. If you want, this would be
the kind of thing you can dump it to a file and slurp it in with Splunk or some other log management utility.
There are a few other audit devices that you can use, and we're not going to dive in deeper to these such a CIS log and then sock. It's one thing to note you can have multiple audit
engines enabled at the same time gives me out of devices enabled at the same time. But it is a blocking process when you only have one. So, for example, if you have the file audit device running and something is a miss with your file system, such that vault is unable to right the
to that file and write the contents of the audit log,
the vault operations itself will halt. So if you ever come across a situation where your vault server is just not being responsive, take a look at the audit logs. Make sure they're all healthier. Rather, the audit devices to take a look at the audit logs, take a look at the audit devices and make sure that vault is able to write the audit information
to the variety of devices that have been configured
before. We close out with this lesson.
Let's have a quiz and pull on some of the information we've learned previously in this module
which things cannot be defined in a server configuration. Vile. We talked about that in the last lesson. Give it a second. I'm going to jump to the answers.
Okay, so we want to talk about things that cannot be configured in the configuration file,
the port that the Volts ever listens to. We've actually configured that and done that firsthand. We used a 200 the database vault for used should use for secret storage. We talked about the different storage back ends we've been We played around with file. We didn't set up database, but we talked about that. Looked at the documentation there.
Whether or not the Web you I should be enabled.
We actually created and reviewed ah server configuration file that had to explicitly enable the web. You I because it is not enabled by default.
What are the secrets engines to enable on Start up. This is not something that's in the server configuration file, and we talked about how you wanna use some sort of answerable playbooks or chef recipes, or whatever sort of automation you're using to provision or server
to execute of Right of the vault enable commands when provisioning your vault server.
That's not information in the server configuration file. In fact, the paths, the different plug ins that air enabled and the access paths all that information gets encrypted and stored in the encrypted storage back end.
Separate vault server hosting unseal keys. So this is something that you can specify. We talked about the auto unseal and some of the mechanisms off, either pulling from key management, key vaults, cloud provided key vaults, custom HSM or even
doing an autos unseal such that the
keys themselves air pulled from another vault server. This is also something you can set up in the server configuration file. Of course, these are key vault finally authentication message. The vault servers should support those air not specified in the server configuration file. Right. That's when you need to do
to use the vault off, enable command
to set up the different authentication methods for your vault server,
and that wraps up this lesson
just to recap. We reviewed the different types of plug ins. We explored a variety of the default plug ins off secrets. We talked about the audit devices as well, and we went through the process of enabling, disabling and moving. And we even talked about tuning different plug ins. Overall, this is the end of the module, and in the module
we talked about a lot. We covered a lot of ground, and so walking away from this, you should have a
a renewed appreciation for vault at a high level, how the vault server is structured and architected the nuances of the the ceiling and unsealing process to get all that data that gets stored and persisted and keeping encrypted and access it only under certain circumstances.
Various mechanisms that you can use to configure the individual vault servers and
where they're responding and how they're talking to different things using the server configuration files and then finally, the types of plug ins and how you can manage the plug ins performing the variety of vault commands.
So I look forward to seeing you back in future modules where we're really gonna continue toe, finalize building our base knowledge on the vault, application the server and then apply that knowledge into creating some RIA World lab and hands on examples using vault.