HashiCorp Vault-Associate HashiCorp Certified: Vault Associate (002) Exam Practice Test

The vault lease operations that use a lease_id as an argument are renew and revoke. The renew operation allows a client to extend the validity of a lease associated with a secret or a token. The revoke operation allows a client to terminate a lease immediately and invalidate the secret or the token. Both operations require a lease_id as an argument to identify the lease to be renewed or revoked. The lease_id can be obtained from the response of reading a secret or creating a token, or from the vault lease list command. The other operations, revoke-prefix, create, and describe, do not use a lease_id as an argument. The revoke-prefix operation allows a client to revoke all secrets or tokens generated under a given prefix. The create operation allows a client to create a new lease for a secret. The describe operation allows a client to view information about a lease, such as its TTL, policies, and metadata. References: Lease, Renew, and Revoke | Vault | HashiCorp Developer, vault lease - Command | Vault | HashiCorp Developer

A lease ID is a unique identifier that is assigned by Vault to every dynamic secret and service type authentication token. A lease ID contains information such as the secret path, the secret version, the secret type, etc. A lease ID can be used to track and revoke access granted to a job by Vault at completion, as it allows the scheduler to perform the following operations:

• Lookup the lease information by using the vault lease lookup command or the sys/leases/lookup API endpoint. This will return the metadata of the lease, such as the expire time, the issue time, the renewable status, and the TTL.
• Renew the lease if needed by using the vault lease renew command or the sys/leases/renew API endpoint. This will extend the validity of the secret or the token for a specified increment, or reset the TTL to the original value if no increment is given.
• Revoke the lease when the job is completed by using the vault lease revoke command or the sys/leases/revoke API endpoint. This will invalidate the secret or the token immediately and prevent any further renewals. For example, with the AWS secrets engine, the access keys will be deleted from AWS the moment a lease is revoked.

A lease ID is different from a token ID or a token accessor. A token ID is the actual value of the token that is used to authenticate to Vault and perform requests. A token ID should be treated as a secret and protected from unauthorized access. A token accessor is a secondary identifier of the token that is used for token management without revealing the token ID. A token accessor can be used to lookup, renew, or revoke a token, but not to authenticate to Vault or access secrets. A token ID or a token accessor can be used to revoke the token itself, but not the leases associated with the token. To revoke the leases, a lease ID is required.

An authentication method is a way to verify the identity of a user or a machine and issue a token with appropriate policies and metadata. An authentication method is not an object that can be tracked or revoked, but a configuration that can be enabled, disabled, tuned, or customized by using the vault auth commands or the sys/auth API endpoints.

References:

Orphan tokens are tokens that are root of their own token tree. This means that they do not have any parent token associated with them, and they do not expire when their parent token expires. Orphan tokens are useful for scenarios where you need a short-lived and independent token, such as for testing or debugging purposes. Orphan tokens can also be used to create temporary access tokens for applications or services that need to communicate with Vault without using a long-lived root token. References: Tokens | Vault | HashiCorp Developer, Vault cli: how to create orphan token with role - HashiCorp Discuss

Not all storage backends support high availability mode for Vault. Only the storage backends that support locking can enable Vault to run in a multi-server mode where one server is active and the others are standby. Some examples of storage backends that support high availability mode are Consul, Integrated Storage, and ZooKeeper. Some examples of storage backends that do not support high availability mode are Filesystem, MySQL, and PostgreSQL. References: 1, 2

The policy shown in the image is:

path “secret/data/webapp1” { capabilities = [“create”, “read”, “update”, “delete”, “list”] }

path “secret/data/super-secret” { capabilities = [“deny”] }

This policy grants or denies access to the key/value v2 secrets engine mounted at secret/ according to the following rules:

• The path “secret/data/webapp1” has the capabilities of “create”, “read”, “update”, “delete”, and “list”. This means that the policy allows performing any of these operations on the secrets stored under this path. The data/ prefix is used to access the actual secret data in the key/value v2 secrets engine5. Therefore, the policy permits the operation of vault kv get secret/webapp1, which reads the secret data at secret/data/webapp16.
• The path “secret/data/super-secret” has the capability of “deny”. This means that the policy denies performing any operation on the secrets stored under this path. The policy overrides any other policy that might grant access to this path. Therefore, the policy does not permit the operations of vault kv delete secret/super-secret and vault kv list secret/super-secret, which delete and list the secret data at secret/data/super-secret respectively6.
• The policy does not explicitly define any rules for the path “secret/metadata”. The metadata/ prefix is used to access the metadata of the secrets in the key/value v2 secrets engine, such as the number of versions, the deletion status, the creation time, etc5. By default, if the policy grants any of the capabilities of “create”, “read”, “update”, or “delete” on the data/ path, it also grants the same capabilities on the corresponding metadata/ path7. Therefore, the policy permits the operation of vault kv metadata get secret/webapp1, which reads the metadata of the secret at secret/metadata/webapp18.

References: 5 [ 6]6, 7 [ 8]8

An authentication method should be selected for a use case based on the auth method that best establishes the identity of the client. The identity of the client is the basis for assigning a set of policies and permissions to the client in Vault. Different auth methods have different ways of verifying the identity of the client, such as using passwords, tokens, certificates, cloud credentials, etc. Depending on the use case, some auth methods may be more suitable or convenient than others. For example, for human users, the userpass or ldap auth methods may be easy to use, while for machines or applications, the approle or aws auth methods may be more secure and scalable. The choice of the auth method should also consider the trade-offs between security, performance, and usability. References: Auth Methods | Vault | HashiCorp Developer, Authentication - Concepts | Vault | HashiCorp Developer

The transit secrets engine relieves the burden of proper encryption/decryption from application developers and pushes the burden onto the operators of Vault. The transit secrets engine provides encryption as a service, which means that it performs cryptographic operations on data in-transit without storing any data. This allows developers to delegate the responsibility of managing encryption keys and algorithms to Vault operators, who can define and enforce policies on the transit secrets engine. This way, developers can focus on their application logic and data, while Vault handles the encryption and decryption of data in a secure and scalable manner. References: Transit - Secrets Engines | Vault | HashiCorp Developer, Encryption as a service: transit secrets engine | Vault | HashiCorp Developer

Vault Agent is a client daemon that provides the following features:

• Auto-Auth - Automatically authenticate to Vault and manage the token renewal process for locally-retrieved dynamic secrets.
• API Proxy - Allows Vault Agent to act as a proxy for Vault’s API, optionally using (or forcing the use of) the Auto-Auth token.
• Caching - Allows client-side caching of responses containing newly created tokens and responses containing leased secrets generated off of these newly created tokens. The agent also manages the renewals of the cached tokens and leases.
• Templating - Allows rendering of user-supplied templates by Vault Agent, using the token generated by the Auto-Auth step.
• Process Supervisor Mode - Runs a child process with Vault secrets injected as environment variables.

One of the benefits of using the Vault Agent is that it will manage the lifecycle of cached tokens and leases automatically. This means that the agent will handle the token renewal and revocation logic, as well as the lease renewal and revocation logic for the secrets that are cached by the agent. This reduces the burden on the application developers and operators, and ensures that the tokens and secrets are always valid and up-to-date. References: Vault Agent | Vault | HashiCorp Developer, Caching - Vault Agent | Vault | HashiCorp Developer

To make an authenticated request via the Vault HTTP API, you need to use the X-Vault-Token HTTP Header or the Authorization HTTP Header using the Bearer scheme. The token is a string that represents your identity and permissions in Vault. You can obtain a token by using an authentication method, such as userpass, approle, aws, etc. The token can also be a root token, which has unlimited access to Vault, or a wrapped token, which is a response-wrapping token that can be used to unwrap the actual token. The token must be sent with every request to Vault that requires authentication, except for the unauthenticated endpoints, such as sys/init, sys/seal-status, sys/unseal, etc. The token is used by Vault to verify your identity and enforce the policies that grant or deny access to various paths and operations. References: 3, 4, 5

The maximum time-to-live (TTL) for a token is defined by the lowest value among the following factors:

• The authentication method that issued the token. Each auth method can have a default and a maximum TTL for the tokens it generates. These values can be configured by the auth method’s mount options or by the auth method’s specific endpoints.
• The mount endpoint configuration that the token is accessing. Each secrets engine can have a default and a maximum TTL for the leases it grants. These values can be configured by the secrets engine’s mount options or by the secrets engine’s specific endpoints.
• A parent token TTL. If a token is created by another token, it inherits the remaining TTL of its parent token, unless the parent token has an infinite TTL (such as the root token). A child token cannot outlive its parent token.
• System max TTL. This is a global limit for all tokens and leases in Vault. It can be configured by the system backend’s max_lease_ttl option.

The client system that uses the token cannot define the maximum TTL for the token, as this is determined by Vault’s configuration and policies. The client system can only request a specific TTL for the token, but this request is subject to the limits imposed by the factors above.

References: 3, 2, 4, 5, 6

The Google Cloud Secrets Engine is the best option for the DevOps team to provision VMs in GCP via a CICD pipeline and integrate Vault to protect the credentials used by the tool. The Google Cloud Secrets Engine can dynamically generate GCP service account keys or OAuth tokens based on IAM policies, which can be used to authenticate and authorize the CICD tool to access GCP resources. The credentials are automatically revoked when they are no longer used or when the lease expires, ensuring that the credentials are short-lived and secure. The DevOps team can configure rolesets or static accounts in Vault to define the scope and permissions of the credentials, and use the Vault API or CLI to request credentials on demand. The Google Cloud Secrets Engine also supports generating access tokens for impersonated service accounts,which can be useful for delegating access to other service accounts without storing or managing their keys1.

The Identity Secrets Engine is not a good option for this use case, because it does not generate GCP credentials, but rather generates identity tokens that can be used to access other Vault secrets engines or namespaces2. The Key/Value Secrets Engine version 2 is also not a good option, because it does not generate dynamic credentials, but rather stores and manages static secrets that the user provides3. The SSH Secrets Engine is not a good option either, because it does not generate GCP credentials, but rather generates SSH keys or OTPs that can be used to access remote hosts via SSH4.

References:

• Google Cloud - Secrets Engines | Vault | HashiCorp Developer
• Identity - Secrets Engines | Vault | HashiCorp Developer
• KV - Secrets Engines | Vault | HashiCorp Developer
• SSH - Secrets Engines | Vault | HashiCorp Developer

The namespace can be defined in the “Mount path” field in the “Advanced options” section of the login screen. The mount path is the path where the auth method is enabled, and it can include a namespace prefix. For example, if the LDAP auth method is enabled at the pathns1/auth/ldap, where ns1 is the namespace, then the mount path field should be set to ns1/auth/ldap. This way, the Vault UI will log in to the correct namespace and auth method. Alternatively, the namespace can also be specified in the URL of the Vault UI, such as

Running the second command in the GUI CLI will fail. The second command is vault kv put secret/creds passcode=my-long-passcode. This command attempts to write a secret named creds with the value passcode=my-long-passcode to the secret path, which is the default path for the kv secrets engine. However, the kv secrets engine is not enabled at the secret path, as shown by the first command vault secrets list, which lists the enabled secrets engines and their paths. The only enabled secrets engine is the transit secrets engine at the transit path. Therefore, the second command will fail with an error message saying that no secrets engine is mounted at the path secret/. To make the second command succeed, the kv secrets engine must be enabled at the secret path or another path, using the vault secrets enable command. For example, vault secrets enable -path=secret kv would enable the kv secrets engine at the secret path. References: kv - Command | Vault | HashiCorp Developer, vault secrets enable - Command | Vault | HashiCorp Developer

AppRole is a machine-oriented authentication method that allows machines or applications to authenticate with Vault using a role ID and a secret ID. The role ID is aunique identifier for the application, and the secret ID is a single-use credential that can be delivered to the application securely. AppRole is designed to provide secure introduction of machines and applications to Vault, and to support the principle of least privilege by allowing fine-grained access control policies to be attached to each role1.

Okta, GitHub, and Transit are not machine-oriented authentication methods. Okta and GitHub are user-oriented authentication methods that allow users to authenticate with Vault using their Okta or GitHub credentials23. Transit is not an authentication method at all, but a secrets engine that provides encryption as a service4.

References:

• AppRole Auth Method | Vault | HashiCorp Developer
• Okta Auth Method | Vault | HashiCorp Developer
• GitHub Auth Method | Vault | HashiCorp Developer
• Transit Secrets Engine | Vault | HashiCorp Developer

When looking at Vault token details, the policies key helps you find the paths the token is able to access. Policies are a declarative way to grant or forbid access to certain paths and operations in Vault. Policies are written in HCL or JSON and are attached to tokens by name. Policies are deny by default, so an empty policy grants no permission in the system. A token can have one or more policies associated with it, and the effective policy is the union of all the individual policies. You can view the token details by using the vault token lookup command or the auth/token/lookup API endpoint. The output will show the policies key with a list of policy names that are attached to the token. You can also view the contents of a policy by using the vault policy read command or the sys/policy API endpoint. The output will show the rules key with the HCL or JSON representation of the policy. The rules will specify the paths and the capabilities (such as create, read, update, delete, list, etc.) that the policy allows or denies. References: 4, 5, 6, 7, 8

The three policies that exist in Vault are:

• admins: This policy grants full access to all secrets and operations in Vault. It can be used by administrators or operators who need to manage all aspects of Vault.
• default: This policy grants access to all secrets and operations in Vault except for those that require specific policies. It can be used as a fallback policy when no other policy matches.
• transit: This policy grants access only to the transit secrets engine, which handles cryptographic functions on data in-transit. It can be used by applications or services that need to encrypt or decrypt data using Vault.

These policies allow an organization to perform useful tasks such as:

• Encrypting, decrypting, and rewrapping data using the transit engine all in one policy: This policy grants access to both the transit secrets engine and the default policy, which allows performing any operation on any secret in Vault.
• Creating a transit encryption key for encrypting, decrypting, and rewrapping encrypted data: This policy grants access only to the transit secrets engine and its associated keys, which are used for encrypting and decrypting data in transit using AES-GCM with a 256-bit AES key or other supported key types.
• Separating permissions allowed on actions associated with the transit secret engine: This policy grants access only to specific actions related to the transit secrets engine, such as creating keys or wrapping requests. It does not grant access to other operations or secrets in Vault.

A web application that uses Vault’s transit secrets engine to encrypt data in-transit can benefit from the following security features:

• Even if the attacker was able to access the raw data, they would only have encrypted bits (TLS in transit). This means that the attacker would need to obtain the encryption key from Vault in order to decrypt the data, which is protected by Vault’s authentication and authorization mechanisms. The transit secrets engine does not store the data sent to it, so the attacker cannot access the data from Vault either.
• The keys can be rotated and min_decryption_version moved forward to ensure this data cannot be decrypted. This means that the web application can periodically change the encryption key used to encrypt the data, and set a minimum decryption version for the key, which prevents older versions of the key from being used to decrypt the data. This way, even if the attacker somehow obtained an old version of the key, they would not be able to decrypt the data that was encrypted with a newer version of the key.

The other statements are not true, because:

• You cannot rotate the encryption key so that the attacker won’t be able to decrypt the data. Rotating the key alone does not prevent the attacker from decrypting the data, as they may still have access to the old version of the key that was used to encrypt the data. You need to also move the min_decryption_version forward to invalidate the old version of the key.
• The Vault administrator would not need to seal the Vault server immediately. Sealing the Vault server would make it inaccessible to both the attacker and the legitimate users, and would require unsealing it with the unseal keys or the recovery keys. Sealing the Vault server is a last resort option in case of a severe compromise or emergency, and is not necessary in this scenario, as the attacker does not have access to the encryption key or the data in Vault. References: Transit - Secrets Engines | Vault | HashiCorp Developer, Encryption as a service: transit secrets engine | Vault | HashiCorp Developer