Server Configuration File

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
let's continue our journey through the vault concepts in this video, we're gonna be talking about the server configuration file. Specifically, we're going to take a closer look at the Dev Server's configuration.
We're gonna review configuration file. Resource is, then we're going to examine the simple configuration file used in a prior video.
There's a few things that server configuration file does for us.
It configures http information, for example, what are the I p addresses that the server itself is going to be listening on what the ports that it's gonna be listening on. How is the TLS? It's configured. So when you're using https, right, the certificates that the TLS is gonna operate under
what is the certificate it's gonna provide? What is the private key that
itself is gonna use, like you would do in a normal Web server? In fact, enabling the Web you I as not a default behavior? And these are things that the configuration file specifies. Of course, we talked about unsealing the vault and the auto unseal stanza in the prior lesson,
So that's something else that's gonna be managed in the configuration file. The storage back ends the final major point
of the server configuration file in. That's specifying where is this data? The data that was encrypted and shed a bit more light on the server configuration aspect of things. We're gonna toggle over to the logging consul again. The terminal launch boat once again. Except this time, we're gonna do it in Devon mode.
And now we're gonna take a closer look at some of the outputs we know about this product a little bit more right
when he's showing things up here.
AP I dress again. We see this is not TLS, right? Not https Cluster address. Clustering is not something we've set up, Not something we're going to talk about in this lesson. Definitely something to explore further. When you're getting into
a production grade vault system, the storage back in this case is in them. So when we're using the DEV mode and we're creating secrets and writing secrets,
they're only stored in memory. And every time we kill that server process and started up again,
all the store, the secrets that we had stored previously are gone. It's fresh. It's brand new. Using the default configuration. Let's take a deeper dive into the actual documentation on the server config files themselves.
And in order to do that, return to the get home page that we have for this tutorial
drill into the fault. Constance number four subdirectory and take a look at the vault configuration docks. I have a link to those right there in the get up file for you, and it's just going back to the Hash Corp site. From this point, we can see the different things that a server configuration file can define. And the server configuration file once again
outside of vault itself. So this configuration file itself is not encrypted.
There's a few things to note, so there's the listener attributes. Really. It's just gonna be TCP because that's all that vault supports at this point.
But in addition to that, you articulate the address in which the server's gonna listen the port that it's gonna listen to and a variety of other
parameters when you're setting up a high availability environment. Um,
TLS, right? So far we've been saying TLS is false and our configurations and that's how Davis, but by default, TLS is true. And so you need to point to TLS or two figured file, and then the key file that being the private key file
and you can have specific specify other details such as minimum version of TLS that's going to be accepted and a bunch of other parameters that you can certainly feel free to explore. We did talk about the seal stands already, so I'm not going to touch on that.
Moving on to the storage Sansa, however I think is, is pretty important. This is where we're telling vault all that data when you persist it when it's at rest. Where you gonna put it? It's gonna be encrypted, Sure, but where you gonna put it? Are you gonna put it in a file? There's a file storage system, right? Are you gonna
to stall it and store it in as your cloud storage If you're gonna put it in a Cassandra database?
One thing to know when you're looking at the different storage types, especially when you start evaluating into a cluster and high availability mode, not all of them support high availability. So obviously the file storage type, which is just persisting the vault encrypted data toe file mounted location that does not support
through the high availability Consul is a very common paradigm used
and sure enough, it does support the high availability paradigm as your does not support high availability. So when determining what is the storage back in that you're gonna want to use in your vault, whether or not you're gonna have high availability is going to be a key consideration. When you are selecting the storage back in that you want to use
you could do a relational database Post crest.
It does support high availability. Take a look at these different storage types in memory is what Dev is using. No high availability, right? It's It's all in ram on one single machine. Fact, not really a good idea other than when you are doing development and testing things out. And let's go ahead and look at the example configuration file
that was included in the get Hub repository,
the same configuration file that we previously used when we were starting a vault and manually going through the initialization process and the unseal process. Here it is simple. Config dot s h dot hcl Excuse me, It Z config file is defined using the Hash Corp configuration language. It's pretty simple, pretty easy to read.
You can see in this case we are using the file storage. In fact,
the data from our launch of the vault was put into a directory called Data. That's going to be in the same working directory that you were in when you launched the vault server, which is probably gonna be the 04 Vault Concepts directory You can poke around in there if you want.
I'm not going to spend the time. Keep in mind all that data, all that material, it has been encrypted, right?
Using a S 256 bit encryption,
I had to articulate that the u I is true. So this is that web. You I it is by default, not enabled. And then I set up here. Ah, basic listener wanted to articulate that support is a 200 just because that's what we've been using. And I disabled TLS because that's also the paradigm we've been working with.
And that sums up our simple configuration file.
It also provides you a good walk through with the different reference materials for vault and understanding. What is the role off the configuration file
and so What do we do in this exercise? Well, we started up the death server and we took a good look and a good guess of what that configuration file might be saying, based on the output produced when the server itself started, we took a review through the reference documentation on the materials and contents of a configuration file. And then we took a look at the
simple configuration file
that was used in the previous lesson for the unsealing.
Up Next
Plugins Part 1
Plugins Part 2
Basic ACL Policies
Basic ACL Policies Lab
Entities, Aliases and Groups Lecture