The Transit secrets engine allows you to send cleartext data to Vault to be encrypted. Vault will encrypt the data with the referenced encryption key, which is stored locally, and returns the ciphertext to the application. The application can then store the encrypted data wherever it needs, such as a database or cloud-based storage.

Although the encryption keys in the Transit secrets engine are exportable, they are generally kept in Vault. This strategy ensures that even if an application is compromised, the encryption keys are NOT stored locally, therefore increasing the organization's security posture.

Check out this tutorial on how to use the Transit secrets engine.

More information about the Transit secrets engine

This question tests your ability to understand how templated policies work as well as following the principle of least privilege, meaning only providing access to the paths required. In this instance, only the policy:

path "kv/team/{{identity.entity.id}}/*" {

 capabilities = ["create", "update", "read", "delete"]

}

path "kv/team/{{identity.entity.id}}" {

 capabilities = ["create", "update", "read", "delete"]

}

meets all the requirements. This policy would permit all current and future users with a custom path based on their entity ID when they log into Vault using a variable replacement within the path.

Information about templated policies can be found here: https://www.vaultproject.io/docs/concepts/policies#templated-policies

***************************************************************************************

Incorrect Answers:

***************************************************************************************

path "kv/team/frank/*" {

 capabilities = ["create", "update", "read", "delete"]

}

path "kv/team/steve/*" {

 capabilities = ["create", "update", "read", "delete"]

}

path "kv/team/bryan/*" {

 capabilities = ["create", "update", "read", "delete"]

}

This may work for the current users of frank, steve, and bryan but it would not work for future users as required in the question. Plus, the users would also need to be granted access to kv/team/<name> as well, not just the paths after their name.

***************************************************************************************

path "kv/team/*" {

 capabilities = ["create", "update", "read", "delete"]

}

While this is the least administrative way to permit access, it is not secure at all since it provides WAY too much access to our users. With this policy, any user under the kv/team path would be able to read any secret stored by any other user. It does NOT follow the principle of least privilege since it provides far too many paths due to the wildcard (*).

***************************************************************************************

path "secret/data/groups/{{identity.groups.ids.fb036ebc-2f62-4124-9503-42aa7A869741.name}}/*" {

 capabilities = ["list"]

}

This is a variable replacement for a group, not individual users. There was no requirement to add these users to a group in Vault. Additionally, the capabilities provided in the policy do not permit them to manage secrets. They could only list what's already stored at the path.

If a backend was mounted using a non-default path, you need to provide it under the Mouth Path option under More Options.

Couldn't really find any useful links for this UI question but it's important to play around with the UI. You can easily do this by running Vault in dev mode with the command vault server -dev.

Legacy applications often suffer from the ability to integrate with modern platforms such as Vault. To assist with this, you can use the Vault Agent to authenticate and manage a Vault token automatically. The token is written to a sink (local file) that the application can pick up and use. The application can then use this token to make the requests to Vault for encrypting/decrypting data. The Vault Agent Auto Auth feature will manage the lifecycle of the token to ensure there is always a valid token that the application can use.

Here is the basic workflow of how Vault Agent Auth Auth works:

You can find information about Vault Agent Auto Auth here

Not all storage backends are created equal. Some support high availability, some do not. Some storage backends have better tools to manage data retention and backups while other storage backends don't offer anything. To decide what storage backend to use, you can use this handy flowchart from my Getting Started with HashiCorp Vault course.

Here is an overview of the storage backend along with an easy way to look at all the different backends. Notice that when you view a certain storage backend, the top of the page will show you whether high availability is supported.

The Vault configuration file includes different stanzas and parameters to define a variety of configuration options. These configurations include the storage backend, listener, TLS certificates, seal type, cluster name, log level, UI, cluster IP address, and a few more. Most of these are required to get Vault up and running in the first place, so they must be placed in the configuration file. Yes, there are alternatives to many of these, like using an Environment Variable, but honestly, I never see that in the real world.

Below is a screenshot from my Getting Started with HashiCorp Vault course. It shows you the Vault components configured inside of the configuration file (as listed above) and components/features that are configured outside of the configuration file, like inside of Vault itself once it's up and running.

To see all the configuration options available to you when planning out your configuration file, check out this link.

This question tests two different aspects of Vault policies: knowing the proper capability required to view data (list) and how to understand writing the correct path for a requirement when wildcards (*) or directory replacements (+) are involved. Out of the options provided, only:

path "kv/+/production" {

 capabilities = ["list"]

}

provides access to LIST the contents on the desired path without giving the auditor read access. A reminder that the + symbol is a directory replacement and ANY value would be permitted in that path segment. This policy might give the auditor more privileges than you asked, but it's the only policy that meets the requirements.

Link for Vault policy capabilities: https://www.vaultproject.io/docs/concepts/policies#capabilities

Link for Vault policy syntax, including information about * and +: https://www.vaultproject.io/docs/concepts/policies#policy-syntax

**************************************************************************************

Incorrect Answers:

**************************************************************************************

path "kv/apps/*" {

 capabilities = ["list", "read"]

}

This provides read access to any path beyond kv/apps, therefore it would give the auditor the ability to read data stored at kv/apps/production.

**************************************************************************************

path "kv/apps/production/*" {

 capabilities = ["list"]

}

This policy doesn't give the auditor list access to the path kv/apps/production, only paths AFTER kv/apps/production. When you have a wildcard in a path like this, it means that any path after the listed path, and not the path itself.

**************************************************************************************

path "kv/apps/+/*" {

 capabilities = ["list"]

}

Similar to the previous policy, this policy doesn't give the auditor list access to the path kv/apps/production, only paths AFTER kv/apps/production. It could also give them access to paths like kv/apps/development/apps/xxx or kv/apps/qa/webapp due to the + and * found in the policy. However, it would not provide access to kv/apps/production

When you use the Vault API to authenticate, the Vault API response will include a client_token that is tied to a specific policy. Once you receive that response, it is up to the user (or application) to parse that response and retrieve the token. Once the token is retrieved, a second API request needs to be sent to Vault to request the new PKI certificate.

Keep in mind that authentication and interaction with a secrets engine are separate actions. Unless you already have a valid Vault token, you need to authenticate first to get a Vault token. Then you can use that token to interact with a secrets engine, like getting a new PKI certificate or generating dynamic credentials.

More about authenticating with AppRole

Specific information about authenticating to Vault using AppRole using the API

To authenticate using the CLI, you could use the command vault login and specify the auth method you wish to use by using the -method flag. For example, if you wanted to authenticate using OIDC, you could use vault login -method=oidc username-bryan.krausen.

The other options are not valid.

Information about the vault login command can be found here.

There are many benefits to using Vault policies, including:

 - provides granular access control to paths within Vault to control who can access certain paths inside Vault

 - policies have an implicit deny, meaning that policies are deny by default - no policy means no authorization

 - policies provide Vault operators with role-based access control so you can ensure users only have access to the paths required

*******************************************

Incorrect Answer:

*******************************************

policies are assigned to a token on a 1:1 basis to eliminate conflicting policies

Policies are indeed attached to tokens, but tokens can be assigned more than one policy if needed. Policies are cumulative and capabilities are additive. Keep in mind that if one policy permits access to a path, but another explicitly denies access, the Deny will always take precedence.

https://learn.hashicorp.com/tutorials/vault/policies