Different auth methods have different intentions and purposes. The following defines what different auth methods are intended for within Vault:

‣Machine-oriented: AppRole, TLS, tokens, platform-specific methods (cloud, k8s)

‣Operator-oriented: Github, LDAP, username & password

Beyond Cubbyhole, the KV secrets engine is the ONLY secrets engine that will store static data in Vault for future retrieval. All other secrets engines either generate or encrypt data.

https://www.vaultproject.io/docs/secrets#secrets-engines

Vault offers several secrets engines that can encrypt and decrypt data for Vault clients. In the answers above, only the Transit and Transform secrets engine can encrypt/decrypt data. Remember that neither of these secrets engines will store data in Vault. It will be up to the application to store the data elsewhere after Vault responds with the ciphertext.

When using the CLI, the proper command is vault login -method=<auth method type>. Each auth method will have its own parameters to include as well, such as the username in the correct answer.

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

Static credentials should be used here so they can be controlled outside of Vault. However, these static credentials should still be stored within Vault using the KV secrets engine so they are not stored somewhere in plaintext.

https://learn.hashicorp.com/tutorials/vault/static-secrets

Orphan tokens are not children of their parent; therefore, orphan tokens do not expire when their parent does.

https://learn.hashicorp.com/tutorials/vault/tokens#orphan-tokens

This policy will NOT permit access to secrets stored under secrets/cloud/apps/jenkins. Notice that in the policy, the wildcard (*) is AFTER the path Jenkins, and not AT the Jenkins path. This policy would permit access to anything AFTER the Jenkins path, but not ON the Jenkins path. To access secrets on the Jenkins path, you'd need to add secrets/cloud/apps/jenkins or even something like secrets/cloud/apps/* to the policy.

(Sneaky, I know. But you need to understand where the permissions start and stop based on the defined path in the policy)

https://www.vaultproject.io/docs/concepts/policies

The operator rekey command generates a new set of unseal keys. This can optionally change the total number of key shares or the required threshold of those key shares to reconstruct the master key. This operation is zero downtime, but it requires that Vault is unsealed and a quorum of existing unseal keys are provided.

https://learn.hashicorp.com/tutorials/vault/rekeying-and-rotating

This path is part of the root-protected paths that require sudo or root access to access. Therefore, the policy here must also include the sudo capability in order to permit the user to rotate the encryption key for Vault. Alternatively, you can use a root token to perform this action.

For a list of root-protected paths in Vault, check out this link: https://learn.hashicorp.com/tutorials/vault/policies#root-protected-api-endpoints

With every dynamic secret and service type authentication token, Vault creates a lease. A lease is metadata containing information such as time duration, renewability, and more. Vault promises that the data will be valid for the given period, or Time To Live (TTL). Once the lease is expired, Vault can automatically revoke the data, and the consumer of the secret can no longer be certain that it is valid.

By using the lease ID for actions such as renewing and revoking, you don't have to share the actual secrets created on the backend platform. For example, suppose I generate an AWS credential (access key and secret key). In that case, another user can use the lease ID to renew/revoke the lease vs. having to provide that user with the actual AWS credentials that were generated.

Check out more information here about Leases.