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
Welcome back to vault fundamentals.
In the last module we interacted with the product. We set it up, we saw running, We poked on it using a variety of methods and we stored secrets in the product
in this module, we're gonna take a step back from wearing the role as an individual that uses vault to store keys and take a look at the product more from an operators perspective or an architect's perspective specifically will look at the overall component architecture, design off vault itself.
We'll talk about data ceiling and unsealing process.
We're gonna cover build server configuration files, which an operator would be very interested in.
We're gonna talk about the different plug ins that are available by default with vault and explore the capabilities of those different kind of plug ins.
In this particular video, we're gonna walk through the vault architecture, step through each one of the big parts, and then we're gonna examine hands on the Dev Server itself and even review vaults. Ap I explorer Here we have an architecture diagram that was provided by ASCII Corp. It gives an overview
of the logical parts
that are running when you have the server process. A vault server up and listening, right? We know that it has an http AP I. We interacted with that using curl, using the command line interface and then indirectly when using the Web graphical user interface.
It was then subsequently making calls to evolved
using the http a p I
we didn't talk much about storage, and obviously this is like any kind of a database. The data itself needs to be persisted in stored in some some manner right beyond just temporary eso. Anything that goes in the storage back and whether that's a file system, whether that's in memory
or whether that's a cloud storage provider,
that it data has to be encrypted by vault
because logically recognizes in the design. All these parts here, where it's doing all these things, handling the secrets, handling configurations off the server itself, they all sit in a logical barrier. Think of it like a cryptographic steel around it. So any information and mike it
exposed involuntary in volatile memory or anything of that nature
goes to the storage back in. We want to make sure that it's encrypted,
therefore, keeping the overall security of the entire concept of using vault so that some snooper couldn't come in through a back door and just subvert all these layers Here, look at the storage information and derive and decrypt all the great secrets that we have gone
coming back to the top.
If we analyze how the incoming requests are handled, we have core,
and that has some very simple roles and responsibilities. And then, based on the incoming path, the rest path,
it's gonna route that request in different ways. Starting over here on the right. If those requests don't have some sort of an eye token, identify are associated with them, something that lets vault know who is the requester that's been identified or and particularly authenticated, then
first thing bolts going to do is say, you know what? You need to authenticate it.
I'm gonna. It exposes and makes available various methods to authenticate. And ultimately, as a result, if you successfully authenticate with whatever account you do, so the token store is gonna provide a token. And that token is like your session cookie that you use when you're interacting with vault
moving to the left. Incoming requests. We sent a lot of requests to dash secret
right? And the reason that all worked out in those prior examples is because the secret path was mounted and associated with the key value secret engine and you can. We could have taken that key value path and mounted it to a different location.
There's a lot of other secret engines that we're going to explore and use, and they'll be mounted at different locations. And so the path routing logic understands. How do I handle this incoming request by pass it off to an off method? Do I send it off to the secret engine? Or last minute at least? Do I need to send it off to the secret system? Back end areas?
This is where we have system information
configurations. We ran the example command of the curl enquiring for sys info that cysts slash path all gets routed over here, and there's a whole lot around the system back in. Of course, you have to be approaching vault authenticated as a user that has the rights and entitlement.
Have you read and even modify that system back and type information.
Other significant components. When we're looking at the logical architecture of Balt, our audit devices.
Every interaction that we performed in the last session reading a ticket, writing a ticket updating ticket, it was all logged. Those interactions get logged in,
put in piped out to an on the device to be just a simple file. There's a lot of other lot of devices that we're gonna look at. But the big point about this logical piece here
is that it provides those checks and balances so you can determine if there's bad behavior based on the logs and the activity logging the year. See? So we've hit on a lot of the big points when we look at the vault. Architecture Torque installer Token Store is where we have the authentication tokens
stored Policy Store manages and upholds the different policies Exploration manager, all secrets that vault itself dynamically generates.
It's going to give a particular least time so all of those things are going to expire, and so putting it all together. But I'd like to do now with our newfound knowledge of the overview of how vault is logically, Architected is come back to our death server and examine the set up, which is just a default set up that hashtag or put,
but examine it a little bit deeper.
So we can really bring some appreciation to how all these parts are applied Pulling from our last session. If you still have the vault server running, I would recommend that you you kill it and then just restarted here. I'm going to start a new instance of the vault server.
Of course,
in depth mode on. And then I'm gonna open another terminal which will be used for client access. Let's take a look at vault and
the server that we have opened running, we have have to get the token
is the root talking. Every time you start the vault server, restart the vault server. This tokens going to be a little bit different.
So here's the authentication method right, you see, is through the you I but we're doing a vault off. I'm gonna go ahead and sign in here. When we last looked at the u I, we were talking about this this little interaction here, um, this is the seal. I guess if you don't have an actual terminal that you can get to, you can run the CLI commands
via the Web interface through this command
Consul. What I want to run is a particular command called the A P I command and what that is doing here. Close this now. All said in the lower area, it brought up all sorts of details off how we're interacting with vault in the AP, eyes that are exposed on this particular instance of the Volzer
based on the different paths, right?
So in a sense, this is looking at that path routing component. And how does it determine where it's gonna author what Or forward, which kind of requests? We have the slash off and we see there being forwarded to two different token authentication engines, right? We look at secret. This is what we were interacting with before.
This is here's different details on the configurations of the secrets engine that keep a key value secrets, engine
data, secret data path, right? That was a path we used quite a bit.
There's some other concepts we haven't gotten into yet, but I wanted to introduce this. So if you ever have confusion and one kind of debug wire certain requests being handled in a particular manner, this is a great way to get a insight into how the path routing decision making is being done and
how those different requests are going to be sent and managed.
Jumping back to the client Consul, take a deeper look at the death server itself by running a few vault commands. I'm gonna run a new command called Vault Secrets
and you can see it has several sub commands enabled. Disable list move tuned. This is the command that were you use to actually enable and disable the secrets engines. So when we use the Dev engine what? Guess what? I forgot.
Export the vault address. So let me export. Set up that environment, variable.
Here we go. Now with the list out the secrets engines, we can see these were set up by default by the vault when it was on the dead version on Dhere is the different things in ways that the secrets are set up. We have cubbyhole. We have secret sash, which we've worked on before.
I'm gonna give this thing a little more space. The wrapping makes a little confusing.
Assists. This is going to be directing to the system in points for the box we were looking at over here right, the system back end. And then, of course, we have the authentication methods and token and so forth, which are not considered secrets, and so they're not listed out here. But if we look at, um,
vault off
list is giving us an overview Here, look, Here's the different routings for the different authentication walls. This point, the only one set up is token based authentication.
Let's take a look at vault policies. We mentioned that What are the policies?
The default Steph server is very simplistic. You have a default policy and route When it started up, we're gonna expand and create custom policies and get a little deeper and that. But hopefully you're seeing how all these concepts there's logical concepts that sit over here in the vault architecture diagram.
They map to different commands
that we can then analyze when we're looking at vault,
for example.
So get fault audit. We talked about audit.
So there No out of devices enabled on the death, sir.
So in a sense, it was a little misleading. Everything we did was being logged. It was just being logged to Devin. All right, we're gonna set up Samata devices in later sessions of this training. I hope you learned a little something. See how the parts come together. Obtained an appreciation for the architecture. Just to recap. We talked about
the vault architecture of the main parts, the pieces
we explored, the Web AP I specifically using that a P I Documentation Command and this kind of an interface to understand the path routing we looked. It ran a few different vault commands that you can use to assess the way different aspects of the architecture heart configured on a particular vault server.
Up Next