VAULT_ADDR is the environment variable that is used to specify the address of the Vault server expressed as a URL and port, for example: https://vault.bryankrausen.com:8200/. You can easily modify the value of the environment variable whenever you want to target a different Vault node/cluster.

Check out this link for a list of all Vault's environment variables that you can use.

The best bet here is to use the AWS secrets engine to generate dynamic credentials for your AWS account(s) when Terraform is executed. You can use the Vault provider to grab these credentials for Vault and then use the credentials as inputs for your AWS provider. In this scenario, Terraform would generate credentials only when executed, and the credentials would automatically expire when the lease expires. This strategy meets all the requirements of the security team.

More information on the AWS secrets engine can be found here

The encryption key is used to encrypt/decrypt data written to the storage backend. The encryption key is protected (encrypted) by the Master Key. The encryption key is stored alongside the data in a keyring on the storage backend. It can be easily rotated (manual operation) and all versions of the key are stored to decrypt any data that was encrypted with previous versions of the key.

Good overview of Vault architecture and data protection can be found here.

Entities are single, logical identities representing users and applications across any tokens they have generated using auth backends, even multiple auth backends. For example, a user may have AWS credentials as well as LDAP or Active Directory credentials. These separate credentials (known as Aliases within Vault Identity) and all of the tokens generated by these credentials are all recognized as referring to the single user or application within various parts of Vault. Vault simplifies administration across multiple Identity Providers (IDP) by bridging them into a common identity.

Vault will automatically create an Entity if one does not exist for any client gaining access to a secret within Vault. Entities can have policies assigned to them that apply to all tokens associated with that entity. They can also be referenced in Sentinel policies, and custom metadata set on the entity can also be referenced within Sentinel policies. This can be used to group entities, but the Identity system also supports real groups.

Vault policies can be assigned to entities that will grant additional permissions to the token on top of the existing policies on that token. If the token presented on the API request contains an identifier for the entity, and if that entity has a set of policies on it, then the token will be capable of performing actions allowed by the policies on the entity as well.

NOTE: The policies on the entity provide additional capabilities and are NOT a replacement for the policies on the token.

Here is a good learn tutorial on Entities and Aliases

If you want to revoke the secrets generated by a secrets engine, you need to revoke the leases associated with the secrets. You can do this using the vault lease revoke <lease_id> command and revoke individual leases, if needed.

If you need to revoke many leases, you can use vault least revoke -prefix <prefix> and Vault will revoke all leases associated with the specified path. For example, you can revoke all leases associated with an entire database secrets engine by using vault lease revoke -prefix database/. Furthermore, you can revoke leases generated by a single role by using the command vault lease revoke -prefix database/creds/<role>.

Additional information can be found here regarding lease renewal and revoking.

Every component in Vault is enabled on a path, and only a single named mount can be used at a given time. If there is already a secrets engine mounted at database/, you cannot enable a second on the default path. Therefore, you need to define the path to be used when enabling another database secrets engine. You do this by using the -path flag on the CLI when using the vault secrets enable command.

By default, a secrets engine, auth method, and audit device will be enabled at a default path that matches the name of the plugin being enabled. For example, if I run vault secrets enable consul, it will be enabled at the default path of consul/. If I run vault secrets enable azure, it'll be enabled at the path azure/.

You can enable multiple secrets engines of the same type as long as the paths are different.

https://learn.hashicorp.com/tutorials/vault/getting-started-secrets-engines

The default TTL in Vault is 768 hours (32 days). Any token created with a specified TTL will have a TTL of 768 hours. The default TTL can be changed in the Vault configuration file.

This is a great tutorial that explains the concept of the default TTL and default explicit TTL.

Root tokens are tokens that have the root policy attached to them. Root tokens can do anything in Vault. Anything. In addition, they are the only type of token within Vault that can be set to never expire without any renewal needed. As a result, it is purposefully hard to create root tokens. In fact, there are only three ways to create root tokens:

 * The initial root token generated at vault operator init -- this token has no expiration

 * By using another root token; a root token with an expiration cannot create a root token that never expires

 * By using vault operator generate-root (example) with the permission of a quorum of unseal/recovery key holders

This explanation comes directly from HashiCorp documentation found here.

When creating a policy, only the following capabilities are available in Vault:

 - Create

 - Update

 - Read

 - Delete

 - List

 - Sudo

 - Deny

For more information about Policies, check out this link: https://www.vaultproject.io/docs/concepts/policies#capabilities

This is true. And these are the three format options available in the Vault CLI. The default is table and you can specify json, yaml, or pretty as an alternative.

You can also use the environment variable VAULT_FORMAT to set this as well.

1. Output Options:
2.  
3. -field=<string>
4. Print only the field with the given name. Specifying this option will
5. take precedence over other formatting directives. The result will not
6. have a trailing newline making it ideal for piping to other processes.
7.  
8. -format=<string>
9. Print the output in the given format. Valid formats are "table", "json",
10. "yaml", or "pretty". The default is table. This can also be specified
11. via the VAULT_FORMAT environment variable.

Details on VAULT_FORMAT can be found here.