Internal and external groups can be created in Vault. Internal groups are created in the identity store and map to other groups or entities. Internal groups are created manually as needed. External groups are usually associated with an auth method, such as LDAP or OIDC. They can be created automatically as a result of mapping LDAP groups to policies, or they can be created manually, such as if you're using OIDC for authentication.

https://www.vaultproject.io/docs/secrets/identity#external-vs-internal-groups

When requested, Vault can take the response it would have sent to an HTTP client and instead insert it into the cubbyhole of a single-use token, returning that single-use token instead. Logically speaking, the response is wrapped by the token, and retrieving it requires an unwrap operation against this token.

https://www.vaultproject.io/docs/concepts/response-wrapping#overview

To enable an auth method, the command always includes vault auth enable <method>. Additional parameters can be added to specify the path, such as vault auth enable -path=cloud aws or include a description vault auth enable -description="cloud secrets" aws

And yes, you can include both vault auth enable -description="cloud secrets" -path=cloud aws

Note that although I've used AWS as an example here, the same methodology applies when enabling any auth method.

https://www.vaultproject.io/docs/auth/aws#via-the-cli

Vault has two default policies, root and default:

  ▪ root policy is created by default – it is a superuser with all permissions

  ▪ default policy is created by default - common permissions

This means that the base, web-app-1, and automation-team policies have been added to Vault.

https://www.vaultproject.io/docs/concepts/policies#built-in-policies

Kyle will need to delete the lease from Vault since a manual secret engine revocation will fail using the -force flag with the vault lease revoke command. This is meant for recovery situations where the secret in the target secrets engine was manually removed. If this flag is specified, -prefix is also required. This is aliased as "-f". The default is false.

https://www.vaultproject.io/docs/commands/lease/revoke

Using the lease ID, the lease can be renewed up until the maximum TTL, or it can be revoked. Lease IDs are similar to token accessors in Vault.

https://www.vaultproject.io/docs/commands/lease

The proper command would be vault lease renew aws/creds/s3-read-only/39e6b9a2-296-83d9-2fe0-c11e846bdc99. If you wanted to change the specific increment for the new lease, you could use the -increment flag in the command as well.

https://www.vaultproject.io/docs/commands/lease/renew

To immediately revoke all leases associated with a specific role, Teddy can run the command vault lease revoke -prefix database/creds/prod-mysql. All leases for this specific role will be revoked. This does NOT affect leases associated with other roles under the database/ mount.

https://www.vaultproject.io/docs/commands/lease/revoke#examples

When tokens are created, a token accessor is also created and returned. This accessor is a value that acts as a reference to a token and can only be used to perform limited actions:

 - Look up a token's properties (not including the actual token ID)

 - Look up a token's capabilities on a path

 - Renew the token

 - Revoke the token

The token making the call, not the token associated with the accessor, must have appropriate permissions for these functions.

https://www.vaultproject.io/docs/concepts/tokens#token-accessors

To manage the database resource, the database secrets engine should be used, specifically with the MySQL plugin. In this scenario, the key is that the backend platform that needs to be managed is a database; where it's hosted is *mostly* irrelevant. I say mostly because the database secrets engine supports many types of databases, and MySQL running in RDS handles credentials slightly different than a MySQL database running on an EC2 instance.

https://www.vaultproject.io/docs/secrets/databases/mysql-maria