The PKI secrets engine generates dynamic X.509 certificates. With this secrets engine, services can get certificates without going through the usual manual process of generating a private key and CSR, submitting to a CA, and waiting for a verification and signing process to complete. Vault's built-in authentication and authorization mechanisms provide the verification functionality.

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

When you rotate the transit encryption key, future encryptions will use this new key. Old data can still be decrypted due to the use of a key ring.

When you look at ciphertext, it will begin with vault:v#, where v# is the version. For example, the ciphertext shown below was encrypted with v2 of the encryption key.

1. Key Value
2. --- -----
3. ciphertext vault:v2:0VHTTBb2EyyNYHsa3XiXsvXOQSLKulH+NqS4eRZdtc2TwQCxqJ7PUipvqQ==

You can also limit what encryption keys can be used with Vault. If you have rotated the encryption key 7 times, you can configure Vault to limit what encryption keys can be used to decrypt data. For example, you can configure the min_decryption_version parameter to tell Vault to "archive" any key prior to the specified version and not permit a decrypt action using a key older than specified with this parameter. Note that Vault does NOT delete this key, it just archives it. You can update this parameter to an earlier version and older data could then be decrypted.

Good information about using the transit secrets engine, including a paragraph about key versions.

Information about setting the minimum decryption version.

In some cases, having a token be revoked would be problematic -- for instance, if a long-running service needs to maintain its SQL connection pool over a long period of time. In this scenario, a periodic token can be used.

The idea behind periodic tokens is that it is easy for systems and services to perform an action relatively frequently -- for instance, every two hours, or even every five minutes. Therefore, as long as a system is actively renewing this token -- in other words, as long as the system is alive -- the system is allowed to keep using the token and any associated leases.

Incorrect Answers:

Orphan Service Token is used when the token hierarchy behavior isn't desirable, such as child tokens being revoked when the parent is revoked. It wouldn't help us in this scenario because it would still be revoked when it hit the max TTL

Batch Token shouldn't be used here since a batch token cannot be renewed, and therefore would not solve the issue with our application in the scenario

Root Token would compromise security, since the application would have unrestricted access to Vault

If a lease has been created in Vault, it has an associated TTL in which it will expire and be revoked. If the lease needs to be extended for some reason, you can use the command vault lease renew <lease_id> to extend the TTL of the lease so it will not expire at its original TTL and will be extended by the time specified in seconds from the current time the lease renewal was issued.

More information about lease renewal can be found here.

Luckily, Vault provides an easy way of re-wrapping encrypted data when a key is rotated. Using the rewrap API endpoint, a non-privileged Vault entity can send data encrypted with an older version of the key to have it re-encrypted with the latest version. The application performing the re-wrapping never interacts with the decrypted data. The process of rotating the encryption key and rewrapping records could (and should) be completely automated. Records could be updated slowly over time to lessen database load, or all at once at the time of rotation. The exact implementation will depend heavily on the needs of each particular organization or application.

https://learn.hashicorp.com/tutorials/vault/eaas-transit-rewrap?in=vault/interactive

The vault lease revoke command is used to revoke a lease/secret created by a Vault secrets engine. Each lease that is created is tracked using a unique lease ID, which can be used to renew or revoke a lease.

 * You can revoke an individual lease using the command vault lease revoke <lease_id>

 * You can also revoke ALL leases from a secrets engine using the -prefix flag, such as vault lease revoke -prefix azure/

 * You can also revoke leases created from a specific role by using the -prefix flag but specifying the path all the way to the role like this: vault lease revoke -prefix azure/creds/<role_name>

For more information on revoking leases, check out the official HashiCorp documentation here.

Incorrect Answers:

Both of the incorrect answers are incorrect because they specify a path but do not contain the -prefix flag as discussed above.

Vault supports a single storage backend to store its encrypted data. Technically you can split the way that Vault handles storing data vs. storing information for clustering (HA) if you wanted to use the ha_storage stanza in the configuration file. However, you'll still only have a single storage backend to store Vault's encrypted data.

For more information about how to split your HA storage from your regular data storage, check out this link. However, please note that this is NOT a common practice

When you are using the UI, you will likely need to add additional LIST permissions to the mount (sys/mounts) and then LIST for every path up to the desired secret. For example, the following policy would provide LIST access to everything needed, including seeing the KV mount and all paths beneath it.

1. path "kv/apps/webapp01" {
2. capabilities = ["read", "create", "update", "list"]
3. }
4.  
5. path "sys/mounts" {
6. capabilities = ["list"]
7. }
8.  
9. path "kv/*" {
10. capabilities = ["list"]
11. }

Check out the information here to understand the sys/mounts.

Vault does not trust the storage backend where it stores its data, therefore all data that is written to the storage backend passing through the cryptographic barrier and is encrypted. When data is being read from the storage backend, the data passes through the cryptographic barrier again to be decrypted so Vault can read it. This is part of the fundamental architecture of the Vault platform.

Check out the Vault architecture here in the official documentation.

Once you log in to the Vault UI, you have four primary tabs across the top. Secrets, Access, Policies, and Tools. Once you click on Secrets, it'll show you the secrets engines that are enabled. To enable a new secrets engine, click on Enable new engine + to enable and configure a new secrets engine in Vault.