Scale Vault For Performance

Use Batch Tokens

Compare Batch Tokens vs. Service Tokens

NOTE: Know these differences very well for the exam

  Service Batch
Can be root tokens Yes No
Can create child tokens Yes No
Renewable Yes No
Listable Yes No
Manually Revocable Yes No
Can be periodic Yes No
Can have explicit Max TTL Yes No (always uses a fixed TTL)
Has accessors Yes No
Has Cubbyhole Yes No
Revoked with parent (if not orphan) Yes Stops Working
Dynamic secrets lease assignment Self Parent (if not orphan)
Can be used across Performance Replication clusters No Yes (if orphan)
Creation scales with performance standby node count No Yes
Cost Heavyweight * Lightweight **

* Multiple storage writes per token creation
** No storage cost for token creation, in memory only

NOTE: Batch tokens must have -orphan=true set to be replicated to performance clusters

# Create a performance replicable batch token
vault token create -type=batch -orphan=true -policy=my-policy

# Create an approle batch token
vault write auth/approle/role/hcvop policies=devops \
  token_type="batch" \
  token_ttl="60s"

Slides 1-14

Use Cases of Performance Standby Nodes (Enterprise)

Enable and Configure Performance Replication (Enterprise)

Creating a Paths Filter (Enterprise)

Creates an allow or deny list to determine what paths get replicated to other clusters. This is useful for the cases where we have clusters in different regions and there are local laws that restrict the export of user information. For example, we cannot export user PII from Europe to other regions so we could restrict the replication of the secrets engine that has that data.