Encryption as a service is a feature provided by the transit secrets engine in Vault. This secrets engine allows outsourcing and centralizing the encryption and decryption of data for applications. In this post we will see how to configure this secrets engine and perform some operations with keys to encrypt and decrypt data. This is the last part of my Vault associate certification blog series.

How do you run Vault in production? How do you start a Vault server not in the development mode? What are storage backends and secrets caching? In this part we will touch on a lot of different topics, everything related to the architecture of Vault in some way. We will conceptually see many topics that are important to be aware of for the exam.

So far we have seen how to use the Vault CLI and the Vault UI. Underneath the surface there is an API. No surprise there! In this post we will take a brief look at how to use the API when interacting with Vault.

So far in this course we have exclusively used the Vault CLI to interact with Vault. If you fancy a graphical experience there is the Vault UI. In this post we will look at how to perform some basic operations in the UI.

As a Vault operator you would spend a lot of time writing Vault CLI commands to enable secrets engines, auth methods, create policies, and more. We have already seen many Vault CLI commands in this course so far, but in this part we take a more systematic approach to work with Vault through the CLI.

Secrets engines are the reason why we use HashiCorp Vault in the first place. Generally, secrets engines store, generate, or encrypt data. There are secrets engines that handle static secrets, such as usernames and passwords that does not change very often. There are also secrets engines that handle dynamic secrets, which are generated as needed and expired when no longer needed. In this post we’ll see a how to work with secrets engines and the motivation behind them.

When we get a token or a secret out from Vault we are really just leasing it from Vault. We can renew a lease, revoke a lease, or find out the details (metadata) associated with a lease. A lease is sort of an object that exists inside of Vault. However, there are differences between leases for tokens and leases for secrets. In this post we’ll continue talking about tokens, this time through the lens of leases. In the following post we’ll hear more about leases through the lens of secrets.

Vault tokens make up the core authentication method in Vault. We can work with tokens using the token auth method, or we can use other auth methods in order to obtain a token. In the end, tokens are what Vault understands. In this post we will look at tokens and their various properties and metadata.

Vault policies put restrictions to what actions a user or application can perform inside of Vault. After successfully authenticating to Vault, a user or application is given a Vault token with one or more policies attached. In this post we will learn the motivation behind policies and learn how to craft our own policies in HashiCorp Configuration Language (HCL).

Authentication methods provide ways to prove your identity to Vault in order to obtain a Vault token. A Vault token is the only way to authorize operations in HashiCorp Vault. In this post I will dive deep into the topic of authentication methods and look close at a few of the common authentication methods that are available.