Different storage backends support different features, such as high availability or being supported by HashiCorp technical support. You can find the list of backends here and view supporting information for each.

https://www.vaultproject.io/docs/configuration/storage

This question is really focused on the proper command to log into Vault and not necessarily the hidden password aspect of it - although it gives it a little bit of a twist .

In the CLI, the shell history (if enabled) will log any commands that you type. If you enter the command vault login -method=userpass username=tom and press enter, you will be prompted to enter your credentials but they will be hidden. Linux will not log your password in the shell history. Note that vault login -method=userpass username=tom and vault login -method=userpass username=tom password=jerry are valid commands to log in to Vault.

https://www.vaultproject.io/docs/auth/userpass

All plaintext data must be base64-encoded before being encrypted by Vault. As a result, decrypted data is always base64 encoded. You can decode the output to reveal the original cleartext data.

https://www.vaultproject.io/docs/secrets/transit#usage

When authenticating to Vault using the API, Vault will return a token. It is up to the operator or automation to extract the token from the response and submit it as part of subsequent requests. For example, check out the response in this example on HashiCorp's website. Notice that the response includes the client_token under the .auth.client_token key. This value must be extracted (like using a JSON parsing tool like jq) in order to include the value as the X-VAULT-TOKEN for subsequent requests like in these examples.

This is applicable to any auth method, although I'm highlighting AppRole in this example.

https://www.vaultproject.io/docs/auth/approle

In order versions of Vault (pre-Vault 1.10), batch and service tokens are prepended with b. and s., respectively. In newer versions of Vault (Vault 1.10+), batch tokens are prepended with hvb. Batch tokens are also longer (meaning byte size) than service tokens because batch tokens are encrypted by the Vault's barrier.

https://learn.hashicorp.com/tutorials/vault/tokens

When you authenticate to Vault using the API, the response will include the client_token, which is required for subsequent responses. To parse this, you can format the output in JSON (like I have above) and parse the response using something like jq to retrieve the token at .auth.client_token

https://www.vaultproject.io/api/auth/userpass#login

Dynamic secrets are generated when they are accessed. Dynamic secrets do not exist until they are read, so there is no risk of someone stealing them or another client using the same secrets. Because Vault has built-in revocation mechanisms, dynamic secrets can be revoked immediately after use, minimizing the amount of time the secret existed.

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

Service token is the general token that most people talk about when referring to a token in Vault.

Batch token is an encrypted binary large object (blobs) that carries just enough information for authentication.

Periodic service tokens have a TTL, but no max TTL.

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

********************************************************************

Policy and primary tokens are NOT valid token types in Vault.

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

When creating the key, the exportable flag must be set as true. By default, it is false. This enables the keys to be exportable. This allows for all the valid keys in the keyring to be exported. Once set, this cannot be disabled.

This is not best practice, so please be careful if you decide to export the key.

https://www.vaultproject.io/api-docs/secret/transit#exportable

Although this is a KV v2 secrets engine, the CLI command does not require the data prefix as the API does. Therefore, the correct command is vault kv put cloud/apps/terraform username=password. Any interaction with KV secrets should begin with vault kv <command>

https://www.vaultproject.io/docs/secrets/kv/kv-v2