Once the Transit secrets engine is enabled, you can start creating encryption keys using vault write -f transit/keys/<key name>. Once you create your key, the application needs permission to use the key for encrypting data (and decrypting). This is done by permitting the UPDATE capability on the path transit/encrypt/<key name> and transit/decrypt<key name>.

https://learn.hashicorp.com/tutorials/vault/eaas-transit

Auth methods are commonly grouped into machine-based and human-based auth methods. In this case, AWS and Azure cannot be used since you can't authenticate with a single auth method across both platforms. The OIDC is a human-based auth method, which leaves only tokens. Tokens can be used on any platform since they are created and managed by Vault itself.

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

Just because you are using a certain platform does not mean you need to use the related auth method. Remember that a Linux or Windows box can reach out to Vault directly over the network without having to directly involve the underlying platform. GPC auth MIGHT be the best option, but it's not the ONLY option that you can use.

Another Example: Azure virtual machines can authenticate using the Azure auth method, but AppRole, Userpass, TLS, OIDC, etc. would still be a possibility. Azure *might* be the best but you're not limited to only Azure.

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

Secrets engines are components that store, generate, or encrypt data. Secrets engines are incredibly flexible, so it is easiest to think about them in terms of their function. Secrets engines are provided some set of data, they take some action on that data, and they return a result.

https://www.vaultproject.io/docs/secrets

Instead of sending the secrets over the network, you can use the cubbyhole's response wrapping feature.

The response wrapping feature generates a single-use temporal token called a wrapping token and puts the secrets inside the wrapping token's cubbyhole. What your co-worker will send over the network is this wrapping token. Remember that the secret is now inside the wrapping token's cubbyhole; therefore, only the wrapping token can reveal this secret. You can then unwrap this wrapping token to read the secrets. Using this strategy ensures that the actual secrets are never sent across the wire.

Additionally, a significant feature of response wrapping is that the wrapping token is a single-use token. That means that once you unwrap the token to retrieve the secrets, nobody else can ever use that token to obtain the secrets.

Here is a good tutorial on how to use response wrapping.

As of Vault 1.8, the following authentication methods are supported:

 - AppRole

 - AliCloud

 - AWS

 - Azure

 - Cloud Foundry

 - GitHub

 - Google Cloud

 - JWT/OIDC

 - Kerberos

 - Kubernetes

 - LDAP

 - Oracle Cloud Infrastructure

 - Okta

 - RADIUS

 - TLS Certificates

 - Tokens

 - Username and Password

VMware nor Android are supported auth methods in Vault.

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

There are a few ways that you can write data to a KV store when using the Vault CLI. First off, the proper command to write data to the KV store is vault kv put <path> <key>=<value>. You can also input data from a file by referencing the file rather than key pairs such as vault kv put <path> @file_path

You could also do something like cat secrets.txt | vault kv put kv/training/certifications/vault

Note that when writing data with key pairs, such as the first example, you can add multiple key pairs if you want, like this: vault kv put kv/training/certification/vault username=bryan password=vault level=associate

More information on the vault kv put command can be found here.

There are two types of replication that are available to Vault Enterprise customers:

  * Disaster Recovery Replication

  * Performance Replication

The big differences between the two types of replication include:

 * DR replication will replicate all tokens and leases from the primary cluster to the secondary. This means tokens that were valid for the primary cluster are valid for the secondary cluster when it is promoted. However, a DR replication cluster does NOT respond to clients unless it is promoted to a primary.

 * Performance replication can respond to client requests, but it handles its own tokens and leases. Any tokens or leases that are created on the primary cluster are NOT replicated to the secondary servers. Therefore if you failover to the secondary cluster, applications would need to re-authenticate because the existing tokens would not be valid on the secondary cluster.

Learn tutorial on Disaster Recovery Replication

Setting up Performance Replication for Vault

Regardless of where a database server is deployed, you can use the database secrets engine to generate dynamic credentials against it. It doesn't matter what platform that server is deployed on, you would still use the database secrets engine. You are NOT restricted to the platform-specific secrets engine (AWS, Azure, GCP, Kubernetes, etc).

More on Secrets Engines here.

Check out more information on the database secrets engine here.

Vault has two built-in policies:

The root policy is created by default – it provides superuser privileges with complete and full access to everything in Vault. You cannot change nor delete this policy. This policy is attached to all root tokens.

The default policy is created by default and provides common permissions for tokens. You can change this policy but it cannot be deleted. It is automatically attached to all non-root tokens by default (this behavior can be changed if needed)

Check out this link for information regarding the built-in policies: https://www.vaultproject.io/docs/concepts/policies#built-in-policies