First of all, why is this "Part -1"? It is because this part introduces this blog series and goes through the exam objectives. I will follow this part with "Part 0" which will be a crash-course in Vault where I will show many of the concepts that will follow in the actual exam objectives in later parts. I will end this part with a more detailed explanation of what Part 0 will be, now on to the content of Part -1:
Terraform is by far the most popular product to come out of HashiCorp, but the second most popular product surely is Vault? In essence, Vault handles your secrets. This might not sound revolutionizing, but there are many features that make Vault a popular choice for secrets management. The official Vault developer page defines Vault as this1:
What is Vault?
Secure, store, and tightly control access to tokens, passwords, certificates, encryption keys for protecting secrets, and other sensitive data using a UI, CLI, or HTTP API.
In a similar spirit to how Terraform works, Vault also has a type of plugins that integrate with many external systems for both authentication and secrets management. I will already spoil what I think is the best feature of Vault: short-lived dynamic secrets. Imagine your application must be able to create resources in Azure every now and then. With Vault your application can ask for a pair of credentials with the exact RBAC-permissions in Azure to perform the job. After the job is completed the credentials are invalidated and will no longer work. There is no need for long-lived credentials anymore. This is to be taken with a grain of salt, of course. There will always be some secrets that must be long-lived, in this case secrets related to Vault itself. I will not cover all of these nuances in this blog series, but I will end the series by discussing the pros and cons of Vault and compare it to other tools and different approaches to secrets management.
If you setting out on your journey towards the Vault Associate Certification, then perhaps you will want to read through my blog series on this topic. Perhaps you have read my previous blog series on the Terraform Associate Certification? Then you will find this blog series to be structured more or less the same, except here I will strictly follow the exam objectives part by part.
Vault Associate Certification exam objectives
The official list of exam objectives consists of ten parts. I will briefly go through each part here, and in the following blog posts in this series I will tackle one part at a time.
1. Compare authentication methods
- Describe authentication methods
- Choose an authentication method based on use case
- Differentiate human vs. system auth methods
This part concerns authentication methods, or auth methods for short. This is how you tell Vault who you are in order to gain access to perform actions in Vault. You, as a human user, and machines in the form of your applications and infrastructure, can both authenticate to Vault. There are many available authentication methods and you need to be familiar with a few of these for the exam.
2. Create Vault policies
- Illustrate the value of Vault policy
- Describe Vault policy syntax: path
- Describe Vault policy syntax: capabilities
- Craft a Vault policy based on requirements
Once you have authenticated to Vault you will receive a token with associated policies. These policies determine what you are allowed to do in Vault. Policies are written in HashiCorp Configuration Language, or HCL for short. If you are familiar with writing Terraform configuration then you already know the syntax for writing policies in Vault - the only difference is the blocks and arguments you will use.
3. Assess Vault tokens
- Describe Vault token
- Differentiate between service and batch tokens. Choose one based on use-case
- Describe root token uses and lifecycle
- Define token accessors
- Explain time-to-live
- Explain orphaned tokens
- Create tokens based on need
As mentioned in the previous part, once you are authenticated you will receive a Vault token. The token is what you will send with each request to Vault, either implicitly using the Vault CLI or explicitly as a header when using the Vault REST API. There are a few different variants of tokens, and each token has some important metadata determining how long the token will live, how many times you can use it, if you can renew it, and much more.
4. Manage Vault leases
- Explain the purpose of a lease ID
- Renew leases
- Revoke leases
Tokens, and something known as dynamic secrets, both have leases. A lease is metadata related to the token or dynamic secret which provides information on time duration, if the token can be renewed, and more. I mentioned this already specifically for tokens in the previous part above. This part makes this concept more concrete and also introduced dynamic secrets.
5. Compare and configure Vault secrets engines
- Choose a secret method based on use case
- Contrast dynamic secrets vs. static secrets and their use cases
- Define transit engine
- Define secrets engines
Secrets is what Vault is all about. Secrets come in many forms, and depending on what type of secret you want to work with you will be using a secrets engine designed for that type of secret. Think of a secrets engine like a resource provider in Terraform. If you want to create Azure resources with Terraform you would use the Azure resource provider. Likewise, if you want to work with credentials in Azure with Vault you would use the Azure secrets engine.
6. Utilize Vault CLI
- Authenticate to Vault
- Configure authentication methods
- Configure Vault policies
- Access Vault secrets
- Enable Secret engines
- Configure environment variables
Throughout this entire blog series I will demonstrate the use of the Vault CLI. However, this part focuses specifically on the use of the Vault CLI. This part will go through a few things related to the Vault CLI that might not come up naturally in the other parts of this series.
7. Utilize Vault UI
- Authenticate to Vault
- Configure authentication methods
- Configure Vault policies
- Access Vault secrets
- Enable Secret engines
Apart from the Vault CLI there is also a Vault UI. This part will take a look at how some of the things covered in the previous parts can be performed in the UI. No new concepts will be introduced.
8. Be aware of the Vault API
- Authenticate to Vault via cURL
- Access Vault secrets via cURL
Underneath both the Vault CLI and the Vault UI there is the Vault API. In this short part we will cover the basics of how to communicate with Vault using the API with cURL. There are a few important parts to cover related to how we craft our API requests. As the title of this part hints, you do not have to be an expert on the use of the API, but you should be aware of what is required in order to use it.
9. Explain Vault architecture
- Describe the encryption of data stored by Vault
- Describe cluster strategy
- Describe storage backends
- Describe the Vault agent
- Describe secrets caching
- Be aware of identities and groups
- Describe Shamir secret sharing and unsealing
- Be aware of replication
- Describe seal/unseal
- Explain response wrapping
- Explain the value of short-lived, dynamically generated secrets
This will most likely be the heaviest of all the parts when it comes to content. In all the parts prior to this one we more or less skip over how to set up a Vault cluster or what actually goes into a Vault cluster. This part will go through the architecture of a Vault cluster, and the steps required to set up a cluster.
10. Explain encryption as a service
- Configure transit secret engine
- Encrypt and decrypt secrets
- Rotate the encryption key
This final part concerns the topic of encryption as a service. We will encounter the transit secret engine that provides a few different features for application developers: encrypting and decrypting data, signing and verifying data, generating hashes and HMACs of data, act as a source of random bytes, and more. The transit engine is also mentioned in part five, but I will skip talking about it in that part and instead introduce it in this part.
This series will continue with Part 0
As mentioned in the first paragraph of this post I will do a Part 0 after this post that will go through Vault at a high-level, touching many of the concepts that will be covered in later parts of the exam objectives. The reason for this is because it will be difficult to get an appreciation of some of the concepts in the early parts of the exam objectives if you don't already have the complete picture of Vault. So think of Part 0 as a Hello World of Vault! I will also go through how to set up a Vault development server which will be required to follow along all the parts of the exam objectives.
Enough of the introduction, see you in the next part!
-
This quote comes from https://developer.hashicorp.com/vault ↩
Top comments (0)