There are lots of benefits of using Integrated Storage as a storage backend for Vault. Introduced in Vault 1.4, Integrated Storage is a built-in solution that provides a highly available, durable storage backend without relying on any external systems. Integrated Storage uses the same underlying consensus protocol (RAFT) as Consul to handle cluster leadership and log management. All Vault data is stored locally on each node, and replicated to all other nodes in the cluster for high availability. It also reduces complexity since all configuration is done within Vault. No external systems to provision alongside Vault.

If you're interested in more information about Integrated Storage, check out my HashiConf '21 session (Oct 19th), where I discuss the benefits of using Integrated Storage in your environment and how to migrate to it.

Here's a good summary of the benefits of Integrated Storage directly from my HashiConf presentation.

Incorrect Answers:

uses the SERF gossip protocol to enable communication between cluster nodes

Vault doesn't use a gossip protocol, it uses a consensus protocol (RAFT) for leader elections and log management

eliminates network communication between hosts, requiring no open ports between hosts

Although Integrated Storage reduces the number of ports required (as compared to a Consul backend), the Vault cluster nodes still need to communicate over port 8201 for replication and RPC forwarding. Therefore, it doesn't eliminate all network connectivity between hosts - making this answer incorrect.

And here's a link directly to the official documentation for setting up Integrated Storage

Also, here are a bunch of HashiCorp Learn tutorials to help you better learn and deploy Vault with Integrated Storage

When executing an authentication request to Vault, you will need to provide the credentials that will be used for authentication. Once successfully authenticated, Vault will return a bunch of information. The primary value that you need to retrieve from this response is the client_token, which can be queried from a JSON parsing tool (such as jq) by grabbing the value of .auth.client_token.

In this example, the user is authenticating with the userpass auth method. You can tell by looking at the API endpoint being called, which is v1/auth/userpass/login/bryan.krausen. 

You can also see from the API request that the request is pulling data from a file named payload.json. This file would contain the password for our user. Oftentimes, this payload.json file (you can call it whatever you want, by the way) would contain different information based on what you are trying to do. If you are using AppRole to authenticating, for example, the payload.json file would contain the role-id and the secret-id in JSON format. Keep in mind the payload doesn't always contain sensitive information, it could just refer to a namespace or other data depending on what API endpoint you are using.

More information about the basics of using the API to interact with Vault can be found here.

All plaintext data must be base64-encoded. The reason for this requirement is that Vault does not require that the plaintext is "text". It could be a binary file such as a PDF or image. The easiest safe transport mechanism for this data as part of a JSON payload is to base64-encode it.

When you use the Vault API to decode ciphertext, Vault returns the data as a base64-encoded string. It is up to the user, or application, to decode and see the original data. Please keep in mind that base64-encoding is NOT encryption and anybody can still read base64-encoded data. Data that is base64-encoded is NOT safe and should be treated as sensitive data, assuming the decoded data is sensitive.

https://www.vaultproject.io/docs/secrets/transit

There are a few key factors to consider for this question. The first is the path itself of where the secret is stored, which is secret/cloud/azure/subscription . The path is part of the API endpoint that is needed to read the secret.

The second is the fact that it is stored on a KV Version 2 secrets engine. When you are retrieving data on a KV Version 2 secrets engine, you must include the data/ prefix, since a KV V2 secrets engine splits data and metadata into different prefixes. In this case, it changes the path to secret/data/cloud/azure/subscription because we are reading a secret and the data path is placed after the mount path of secret/.

Finally, since you are reading a secret, you must provide a valid token to do so using the proper header. The correct answer is the only answer that gets ALL of this right.

Incorrect Answers:

$ curl https://vault.krausen.com:8200/v1/secret/data/cloud/azure/subscription

This answer above does get the path correct, but it does not include a valid token to make the request.

$ curl \

 --header "X-Vault-Token: s.CbzCNJCVWt63jyzyaJakgDwz" \

 https://vault.krausen.com:8200/v1/secret/cloud/azure/subscription

This answer has an incorrect path since it does NOT include the data prefix required by a KV Version 2 secrets engine.

$ curl \

 --header "X-Vault-Token: s.CbzCNJCVWt63jyzyaJakgDwz" \

 https://vault.krausen.com:8200/secret/data/cloud/azure/subscription/latest

This answer includes an additional segment on the path, which is not needed to get the latest version of the secret. You simply read the path where the secret is stored to get the latest version. Everything else about this CURL command is correct, though.

Here is the official documentation for the KV Version 2 API

Out of the options provided, only two of them are valid headers to use to set the token in a Vault API request.

X-Vault-Token: <token>

Authorization: Bearer <token>

The others are not valid options to use for authenticating to Vault with a token.

Check out this short section that declares the two available headers for authenticating with Vault

While there are plenty of Vault auth methods, some of them are better suited for machine-to-machine access, and some are geared towards human-based access. Human-based auth methods usually involve physical interaction with Vault, like entering a username and password or accepting the MFA push on your phone. Human-based auth methods include:

 - GitHub

 - Userpass

 - OIDC

 - LDAP

 - Okta

https://learn.hashicorp.com/tutorials/vault/getting-started-authentication#github-authentication

When tokens are created, a token accessor is also created and returned to the user/requested. This accessor is a value that acts as a reference to a token and can only be used to perform limited actions in Vault. These actions include 1) looking up information about the token, 2) renewing the token, 3) lookup the capabilities on a path, and 4) revoking the token.

Note that you CANNOT authenticate with Vault using a token accessor. You must have the token itself to authenticate to Vault to read secrets, make configuration changes, etc.

Check out more information about token accessors here.

In this case, your policy does not permit access to view policies in Vault, therefore the Policies tab is not shown in the Vault UI. To see the Policies tab, you need a policy that includes the following path (for Vault OSS):

1. path "sys/policy/*" {
2. capabilities = ["read", "list"]
3. }

Note that Vault OSS and Vault Enterprise have different paths to manage policies. In Vault Enterprise, the path above would be sys/policies/acl/* . That's because Vault Enterprise has different types of policies, including traditional ACLs, Sentinel EGPs, and Sentinel RGPs. Because of that, Vault Enterprise changes the API endpoint.

The policy above will permit you access to just view the policies in Vault, but you will not be able to manage/edit them. In order to update policy, you would need update permissions on all policies, or at least the policies you need to manage. So if you have a policy called developers that you wanted to update, you would need a policy that included this permission:

1. path "sys/policies/acl/developer" {
2. capabilities = ["read", "list", "update"]
3. }

Keep in mind that you would need the create permission if the policy didn't exist and you wanted to create it. Having the update permission only allows you to modify an existing policy.

More information about the Vault OSS endpoint for managing policies can be found here.

Information about the Vault Enterprise endpoint for policies can be found here.

Based on the screenshot provided, the following statements are true:

 * The user has more than just read privileges on the path. You can tell because the options to "Delete" and "Create New Version" are present for the user. If they didn't have those permissions, the options would not show in the Vault UI.

 * The secrets are stored on a KV Version 2 secrets engine. You can tell because the Vault UI is offering a way to create another version of the secret. KV Version 1 does not offer the ability to version secrets.

 * the secrets engine is mounted at the path of developers/. You can tell by the fact that developers is the first segment of the path where the data is stored.

 * This is the fifth (5) version of the secret stored in Vault, which means there are (or were) four (4) previous versions of the secret. You can tell because the Vault UI is showing you that you are looking at Version 5 of the secret.

I couldn't really find a great link to add since this is a question about the Vault UI, but here's something to look at if you're interested

Batch tokens are designed to be lightweight with limited flexibility. They can reduce the stress on the storage backend and improve the overall performance because they are not persisted to storage. However, they lack many features available to regular service tokens, such as token renewal, creation of child tokens, token revocation, cubbyhole access, and more (see this chart).

Batch tokens are commonly used for very high-performance requirements, such as when 1000s of containers startup at the same time or heavy use of the transit secrets engine.

Incorrect Answers:

batch tokens can be renewed - batch tokens cannot be renewed. You will get an error from Vault if you try to renew a batch token

batch tokens can create child tokens - this is not true about batch tokens, as they cannot create child tokens since they aren't fully featured like service tokens.