---
title: 'HashiCorp Vault Tutorial for Beginners - What, Why and How'
source: 'https://youtube.com/watch?v=klyAhaklGNU'
video_id: 'klyAhaklGNU'
date: 2026-08-19
duration_sec: 1750
channel: 'TechWorld with Nana'
---

# HashiCorp Vault Tutorial for Beginners - What, Why and How

> Source: [HashiCorp Vault Tutorial for Beginners - What, Why and How](https://youtube.com/watch?v=klyAhaklGNU)

## Summary

This video provides a comprehensive introduction to HashiCorp Vault, a secrets management tool. It explains why secrets management is necessary, how Vault centralizes and secures secrets, and details its architecture, including secret engines, authentication methods, and audit devices.

### Key Points

- **Introduction to Vault and Secrets** [00:02] — Vault is a secrets management tool. Secrets are pieces of information used to log in and authorize with services, such as username/password credentials or API tokens. Both human users (engineers) and system users (CI/CD pipelines) need secrets.
- **Common Use Cases for Secrets** [01:36] — Applications need secrets to access databases (MySQL, Elasticsearch), external APIs (Facebook, Google, Stripe), and other services. If these keys are compromised, user data can be leaked, leading to loss of trust and disaster.
- **Other Types of Secrets** [02:35] — Secrets also include SSH keys for server access, TLS certificates for secure communication, and certificates for internal systems like Kubernetes. All sensitive data that should not be accessed by malicious actors are secrets.
- **The Problem of Secret Sprawl** [04:02] — Secrets end up everywhere: on engineers' local computers, in shared password files, in Confluence pages, in CI/CD pipeline environment variables, in configuration files, and even hardcoded in source code. This is called 'secret sprawl'.
- **Two Huge Problems with Secret Sprawl** [06:30] — First, there is no visibility into who has access to which secrets or who has accessed them, leaving no audit trail. Second, secret rotation becomes challenging because you don't know all the places where a secret is used.
- **How Secret Management Tools Solve the Problem** [08:42] — Secret management tools centralize secrets in one secure place. They encrypt secrets at rest and in transit, provide access control, and offer auditing capabilities to track who accessed what and when.
- **Dynamic Secrets Feature** [12:07] — Vault can create short-lived credentials that expire after a validity period. This minimizes security risk if credentials are leaked, and allows for pinpointing the exact client that was compromised.
- **Encryption as a Service** [15:21] — Vault can encrypt data in a database, handling the entire lifecycle of encryption keys. This protects personal identifiable information (PII) even if hackers break into the database.
- **Vault Architecture: Core and API** [18:46] — Vault has a core that manages most of the work, and a layer of Vault API. All requests, whether via UI or CLI, go through the API. Vault is path-based.
- **Secret Engines** [19:28] — Vault has different secret engines for different types of secrets, including key-value store, database secret backends, AWS, PKI, SSH, and Kubernetes. These engines create temporary credentials for clients.
- **Storage Backends** [22:10] — Secrets are stored in storage backends, which can be a relational database, HashiCorp Consul, or a cloud-managed database service. High availability and replication are crucial to prevent data loss.
- **Authentication Methods** [23:06] — Vault uses authentication methods to authenticate clients from different systems, such as AWS, Kubernetes, LDAP, or Active Directory. It trusts these identity providers to identify entities.
- **How Clients Fetch Secrets** [25:12] — A client sends a request using a specific auth method, gets a token with an associated policy, and then uses that token to fetch secrets from a secret engine. The token is short-lived and expires.
- **Audit Devices** [26:39] — Audit devices keep a detailed log of all requests and responses to Vault, creating a trail of who has done what. This can be sent to a file or a syslog server.
- **Pluggable Architecture** [27:50] — Vault has a pluggable architecture where you can connect different auth methods, audit devices, secret engines, and storage backends, making it flexible and easy to integrate with different platforms.

### Conclusion

Vault centralizes secrets, provides encryption, dynamic credentials, and auditing to solve the problems of secret sprawl. Its pluggable architecture makes it flexible for integrating with various platforms and services.

## Transcript

Hesh cor volt but before we understand what volt is and what it does we first need to understand why was it created in the first place so what problem does it solve and then talk about how it actually solves the problem and once we
have that foundational understanding then we're going to look at how volt Works what are some of the unique features it has as well as look at Vault architecture and how it's design designed to do its job so let's get into
designed to do its job so let's get into it vault is essentially a Secrets management tool so the question is what are the secrets and why do we need to manage them secrets are generally pieces of information that we use to login and
authorize with different services like username and password credentials or a username and password credentials or a token to connect to an API and so on and there are two types of users who need those secrets to log into Services human
and system users for example I as an engineer need to access kubernetes cluster to administer it or troubleshoot some issues and cicd pipeline which is a system user needs access to the cluster in order to deploy and run pods inside
or another example me as an engineer would have my user credentials to access AWS account but terraform needs its keep PA or roll credentials to provision infrastructure on AWS but a very common
and large use case of secrets between systems is when our own web application may need access to myql database for example or maybe another database like elastic search in addition plus our application may be using social media
logins from Facebook Google so it needs API keys from Facebook and Google apis maybe we're using an external payment service instead of implementing your own like stripe so our application will need to have stripe API key to make API calls
to it again this will be a key to identify our application with stripe service so you can guess that anyone other than our application to get hold other than our application to get hold of any of these keys and use them for
evil purposes would be extremely bad for our application because our user data will be leaked our users won't trust us anymore and it's going to be a disaster now there are many other secret types like let's say we have a fleet of
servers we're configuring automatically with enable and we provide enable with SSH keys to access those servers again if someone else got hold of those SSH keys and accessed the servers they can basically do whatever they want on those
servers and completely mess up our infrastructure or think about TLS certificates we need to create certificates for our applications and certificates for our applications and get them signed by CA so we can provide
a secure connection to our application for our users where the communication between front end and backend is encrypted and secure especially if we are sending user login or payment data or if we are exchanging any Keys between
front end and back end or we may have certificates within our systems like in IO for example to generate certificates for all pods in cence cluster in order them for better security so all the sensitive data that we would absolutely
sensitive data that we would absolutely not want anyone with evil plans to get not want anyone with evil plans to get hold on to are secrets that we need to protect access to so as you see we have sensitive data and access credentials
for so many systems and services that other services or human users need to use now the question is where do we keep those secrets and how do we make sure only the right people or system systems have access to them well that's exactly
have access to them well that's exactly where the challenge those Secrets end up everywhere Engineers may have some Secrets locally on their computer like AWS user access keys to connect to adabas account or SSH
keys or PM files to connect to servers or cube config file to connect to commus Cluster in many projects you may have Cluster in many projects you may have some kind of keypass files sh shared
around by team members so when a new Junior engineer asks hey I need access to the dev database to test my code changes where do I get those credentials they may get this password file or even worse get a link to a Confluence page
which has a list of database credentials for each environment in plain text which actually happens in real life and is a huge security failure of course or we may even have secrets stored more securely like in CSD pipelines
environment variables so our gitlab CI pipeline or Jenkins pipeline will have a list of all services like Docker registry AWS credentials kubernetes cluster credentials SSH Keys etc for all the services it needs to connect to
during the pipeline execution and now you need to of course worry about who has access to the section of the CSD pipeline settings that allows you to see the values of those environment variables now what about all secrets
that our web application needs to connect to databases and API endpoints and so on we may have some external configuration files with database credentials and API tokens that get passed by against CS pipeline or
sometimes they get set directly on the server as operating system environment variables or config files and finally in another worst case scenario we may have API keys or credentials hardcoded in plain text in our application source
code which end up in git repositories and in the commit history of the repositories which again happens more often than you would think or hard-coded access credentials in plain text in enable puppet or terraform scripts so
basically whether securely stored or completely insecurely managed those secrets are spread everywhere all over platforms and servers Engineers computers and so on and this is called
secret sprawl there are two huge problems with secret sprawl first of all you have no visibility of who has access to What secrets like what are all the
places where we have myql database credentials and who has access to those places it's really hard to know when those credentials are literally just spread around everywhere if we have secrets in G repository either in code
or pipeline configuration again who has access to the repository itself like everyone in the organization specific teams specific team members and on top of that we actually have no visibility of who has accessed or used What secrets
of who has accessed or used What secrets so if a specific secret was compromised we wouldn't even know that it happened and even if we found out we wouldn't know what leaked the secret was it an engineer's laptop was it the source code
was it the application itself or the server who knows so there is no audit trail of who has accessed and used the secrets and the second problem of secret sprawl is let's say stripe API key was stolen what do we do in this case we
need to delete the old key and create a new one right to make sure that the old stolen key is not active anymore or is not usable in which case we would need to update all the systems and places where the stripe key is used so we need
to update the application and say here's a new strap key from now on use this one so the application actually continues to work and again when you have no visibility and no proper handling of all the places where different credentials
are used the secret rotation becomes challenging or even if we simply rotated the secrets proactively like change the database credentials once in a while just to keep all the passwords and tokens fresh and updated it will still
be a challenge to take these new credentials and find all the clients who with this new credential and that's exactly where the secret management tools come in to solve the problem of secret sprawl and all the side effects
of it and vault is one of those secret management tools along with some other examples like AWS Secrets manager or Azure key Vault and so on so what do
these secret management tools do exactly they centralize the management of secrets so instead of having them spread around we take all the secrets from Confluence Pages server operating systems configuration files engineers
local computers and put it in one Central secure place however just dropping the secrets all in there so we have everything in one place is not enough so this is what these tools provide first of all instead of plain
text all secrets are encrypted at rest so while it's stored inside the Vault but but also in transit what does it mean well the secrets need to be accessed by clients right so when database credentials are sent from Vault
to our application so that our application can use it to connect to the database the credentials need to be encrypted when they're sent from Vault to the client in transit this means even if someone caught the credentials while
in transit they still won't be able to read them so that's another security layer and as Engineers learn continuously in our defic cobs boot camp security is layered so it's not one giant wall that you build around your
giant wall that you build around your system it's layers of walls like peels system it's layers of walls like peels of onions so that if someone hexs into one layer they basically have to overcome the next one and the next one
the more layers you have the harder it is for malicious actors to steal your is for malicious actors to steal your data or secrets and at any point in time get access to something that allows them to access ACC your entire system and
because security is layered the story and use cases of Secrets management tools continues now we have secrets in one place encrypted add rest and in transit now we want to control who can access which Secrets right so which
access which Secrets right so which humans and system users can access what secret stored in the central place and for that those tools have access control like not every service needs access to database or stripe API key right so we
configure granular access management to make sure that Engineers as well as applications only have access to those secrets that they explicitly need so now
instead of everyone in organization that has access to cicd pipeline seeing the secrets configured there now you need explicit access to the secret to see it
in Vault and on top of that we have auditing so we can see what secret data auditing so we can see what secret data was retrieved or accessed by web server at what time what credentials were accessed by different Engineers so
building so if someone breaks in and steals something you can see what happened exactly you have a trace that was left that tells you exactly what happened in which order at what time so basically we're moving from having
everything spread around with no visibility to having them in one central place with tighter control over them and visibility ility on how and when those visibility ility on how and when those secrets are
with Tide access control so humans or applications can access the secrets securely but what happens once the application actually gets the secret out of Walt what if the application can't keep that secret safely what if some
Junior developers edit some log lines for debugging that just logs out the entire information with the sensitive data to the console happens more often than expected in real life if we have a lock collector and processor those logs
will be sent to a central storage and then off to a log visualization tool so now those secrets are exposed to anyone who can access the log storage or log visualization tool so how can we secure the secrets even after they get fetched
by the application that's where the dynamic Secrets feature comes in the basically instead of using static credentials like username and password credentials like username and password or API keys that don't expire Vault lets
you create short lived credentials with short expiration period like valid for 10 days or maybe even one time use these are created dynamically when the application or any client requests the secret and expires after the validity
period this means now even if the application leaks the credentials into locks it's not a big issue because by the time they end up in locks dashboard or someone finds them and tries to use them for bad purposes they may be
expired already so with short-lived exess tokens security risk is minimized even if someone gets access to the token and it is still valid they will have a
very short window to hack into systems with that credential and in hacking usually hackers need to probe around for a long period of time to get into systems so limiting the time in which they can do damage already reduces a
risk tremendously now from an auditing point this is also very interesting because with Dynamic Secrets every client will get its own unique short live credential so if we have five clients who access database credentials
they will all get their shortlived unique credentials so if that database credential gets leaked we will know exactly which client was the the vulnerable source and this is important because now you know there is a specific
microservice or application or client that needs to be secured because it is exposing sensitive data and of course that credential needs to be rotated only for that application we don't need to rotate the exos credentials for any
other client which is a huge Advantage for operations because revoking credentials to a system like rotating credentials off a database would usually usually cause a short outage for the clients who are accessing this database
so we are preventing this outage for all other clients who didn't have any issues so the ability to isolate that incident and pinpoint the exact client that was and pinpoint the exact client that was compromised is a huge benefit in Secrets
secrets we also have regular data which are not considered Secrets but still need to be protected these are personal data of our users also called pii or
personal identifiable information which basically means information that you can basically means information that you can use to uniquely identify someone and lots of applications store your personal information right your birthday email
address phone number maybe social security number and so on now these aren't considered secrets so you wouldn't store them in Vault or a will be stored in a regular database
along with other application data but there are security implications of the pii being exposed now you may be thinking why is that a big deal if this kind of information gets exposed because a lot of them may be public already well
hackers can actually use this information to craft very convincing personalized emails or messages for fishing attacks for example in many regulations and penalties if a company does not properly protect their users or
c customers Pi so that means if you're storing personal identifiable information this data also needs to be secured now of course we have database credentials to secure access to them which already is one layer of security
but you will hear me say this again Security in layers and that's where Volt's feature of encrypt as service comes in again very straightforward and simple idea we can encrypt data in a database using volt where volt will
handle the entire life cycle of the encryption keys and encrypt the data securely so now we have database credentials stored in Vault encrypted or maybe issued as Dynamic shortlived credentials but in case hackers still
manage to break into the database again as I said a client was compromised and the credential was stolen they still won't be able to see the data because it's encrypted instead of plain text so they would actually need to get the
encryption key from vault in addition to be able to decrypt and read the data stored in the database so even with the database credentials they won't be able to access that personal user information now this is actually one small lecture
in a pretty large Secrets management chapter of our def Sops boot camp which is a massive program which covers everything from security in software development to devops pipelines Cloud security kubernetes security compliances
code gitops and tons and tons of more important Concepts that's why it's no wonder why def secops or devop Engineers with security skills are so highly demanded and hugely well paid because it's a vast knowledge of very important
skills that all the large companies desperately need if you want to know what def cops is all about and what skill set it covers you can grab the detailed devops curriculum from below that you can use to learn about this
important Concept in engineering hope you find it useful now back to how Vault works you understand what Secrets management tools are why they exist and some of the additional use cases that Vault specifically provides now the
question is how does Vault actually do all of this how does it work how does it store the secrets how does it manage access to those secrets and provide the feature of dynamic Secrets as well as encrypt as a service well at the core of
Vault we have What's called the core which has all the components for managing most of the work that vault is doing and to talk to that core there is doing and to talk to that core there is a layer of volt API and vault is apid
driven so whether you are talking to it via UI or CLI all requests go through the API now for storing different types of Secrets Vault has different what's
called secret engines or secret beckons which is part of that volt core the simplest one is key value store which is a generic Secret store where we can store arbitrary static Secrets like username and password API Keys database
credentials and so on but remember I mentioned the dynamic Secrets feature well for those there are other types of Secret backends for example Vault has various database secret beend which will dynamically manage secrets for different
dynamically manage secrets for different databases like MySQL Oracle postgress and so on on the official documentation you can actually see a full list of database secret backends there is also rbit mq for dynamic credentials for
rbit mq for dynamic credentials for message cues we also have AWS so if we have applications that need to access S3 bucket for example but we don't want to give static I am credentials to our applications instead we can define a
role and then dynamically generate short Le credentials as needed another common use case is pki or public key infrastructure for certificate management which is a very complex process for operations Engineers so we
often have very long lived certificates like 5 10 years because Engineers do not want to go through the process of generating and rotating them with Vault we can programmatically generate the certificates so in practice people can
use shortlived certificates maybe couple of days or maybe even hours we also have SSH secret backend for generating the SSH Keys dynamically so you don't have a SSH Keys dynamically so you don't have a single SSH PM file for your entire fleet
of servers instead you can create one SSH key for each one of them so in case a PM file gets compromised it doesn't affect all your servers but rather that incident can be isolated for that one specific server that the pimp file
belongs to there's also secret backend for kubernetes for generating kubernetes service account tokens so Vault basically ties in the mechanisms of these different tools like AWS am service database exess management
kubernetes arbc so it uses the existing mechanisms of those tools to create temporary credentials for the clients so it basically acts like a broker of authentication between the client and all these different services so Vault
interacts with these tools to create those temporary credentials and would return them to client and that's why you have a specific secret engine for each tool and the way it works is once you install and set up volt you have the
core of Vault installed and then you can enable different secret backends that you need now these secrets need to be stored somewhere right like physically stored in a location and these are storage backends this can be a standard
relational database like my SQL or pogress it could be hash Corp console it could be a cloud managed database service and as I mentioned in Vault we only store Secrets the actual sensitive data which are credentials so the volume
of the data is not as large as the standard application data so we don't standard application data so we don't need large database but we do need High availability and replication of data to make sure the data isn't lost because if
the credentials are only stored in volt and if we lose those credentials then we're going to be locked out of our systems okay so we have different types of Secrets stored in some storage backend database now these secrets need
to be securely accessible right so basically we need secure login mechanism into Vault we need a way to authenticate with VA to provide an identity like hey
I'm Nana from devop Team or hey I'm ec2 instance from AWS account with this ID or hey I'm pod from KU cluster with this name and we also need authorization like
can I please get credential for the postgress database or can I please access the S3 bucket called this name or can I get the stripe API key and for this Vault uses so-called authentication
methods or authentication backends Vault uses these to authenticate clients from different systems to fetch the secrets for example we may use AWS authentication plugin so if AWS resource like ec2 needs access to a secret from
volt it can authenticate via AWS plugin we also have kubernetes o plugin if kubernetes component like pod needs to access Secret in volt it can use kubernetes off plugin for human user we may use something like LF or active
directory o plugin to prove our identity the idea here is that instead of volt identifying each specific entity like KU P an AWS ec2 server or a human user by
itself it uses a system that it trusts like kubernetes AWS LP and so on to identify these different entities and this is generally how identity provider
concept works so Vault trusts kubernetes AWS and then kubernetes and AWS provide their components with a stamp of identity that these components can present to Vault to identify themselves like kubernetes gives its pods or
Services identity saying this pod is for my cluster or AWS gives its services identity so kubernetes and AWS are essentially identity providers for Vault and that's why we have the term so in order to log in to Vault a client which
can be human user or application can send a request using a specific off method at a certain path because everything in Vault is path-based and Vault will use that off method to authenticate the client if this is
successful then client will get a token as a response and that token has Vault policy associated with it which basically defines what permissions that client will have using the token so what Secrets they can access at which path
practices of course this token is short lft it's a dynamically generated credential so it expires after a certain validity and that means the client has validity and that means the client has to Rel log in or reauthenticate to renew
the token so now when a client wants to fetch some data from a secret engine in Vault it will send a request along with the token that it received when it authenticated with Vault so for example with a key value store which is the
simplest secret engine client makes an API call to vault at a certain path Vault will check the token and the policy that defines whether this client actually has permission to access the secret at this path and if successful
Vault will basically send back the actual key value pair of the secret and same way as secret beckons you can enable any of these o beckons that you need after you have installed and set up vault and finally we need the audit
Trail right we want to track who has accessed what when how many times and so on this is the visibility of who is using the sensitive data in case of any secrets being exposed or compromised and you probably already guessed we have
audit backends for those called audit devices so audit devices are the components in Vault that keep a detailed log of all requests to volt and the
responses because every operation with vault is an API request response when using audit device the audit log contains every interaction with the Vault API including the errors so Vault connects to an auditing backend which
again is an external system that you can plug in and streams out request response auditing to it to create a trail of who's done what or who is doing what in Vault who is fetching the secrets who is updating the secrets generating Dynamic
secrets and so on and this audit log can be a simple file or CIS log and you can actually send audit info to multiple audit backhands so as you see Vault has
this pluggable architecture design where you have the core and then you can connect or plug in different off methods or audit devices secret engines or storage backhands to it and this type of architecture makes it easier to
architecture makes it easier to integrate Vault with different platforms and services so this makes Vault flexible in that sense so with vault in place the way it works now is Vault manages clients that are authenticating
against different set of identity providers we then log the exess in different trusted sources of log management tools we store this secret data in any durable system and we can store either static or dynamic Secrets
using different secret backends so I hope now you understand clearly what vault is and the secrets management Concept in general my main mission is to break down these seemingly complex Technologies into such simple
explanations that you are just much more excited and motivated to learn them for your engineering career and that's how I designed all our educational programs which you can browse on our website if you're interested with that as always
thanks for watching and see you in the next video