HashiCorp Certified: Vault Operations Professional 2022
Scale Vault for Performance
Create a Paths Filter
In this lesson, you’ll learn how to use Vault’s path filter feature to control which mounts and namespaces are replicated between clusters. This is especially useful when your primary and secondary clusters span different regions with varying regulatory requirements (for example, GDPR in Europe).
Why Path Filters Matter
Vault can replicate all data from a primary cluster to one or more performance replica clusters. However, cross-region replication may conflict with data residency laws. For instance, you might store personally identifiable information (PII)—addresses, phone numbers, credit card details—under a Secrets Engine mount. European Union regulations like GDPR forbid sending such data outside the EU.
Warning
Replicating PII or sensitive data outside regulated regions can lead to compliance violations and hefty fines under laws like GDPR.
In this example, sending customers/
or credit-cards/
from an EU primary to an APAC secondary would breach GDPR.
To enforce compliance, Vault’s path filter lets you define either:
- An allowlist (only specified paths replicate), or
- A denylist (all except specified paths replicate).
Mode | Behavior | Example Use Case |
---|---|---|
Allowlist | Only listed paths are replicated. | Replicate EU-only Secrets Engines to an EU replica. |
Denylist | All paths except listed ones are replicated. | Exclude PII mounts when replicating globally. |
Path filters apply to any Vault path: secrets-engine mounts, auth methods, or namespaces.
Allowlist Mode
Use an allowlist when you want to whitelist only certain mounts. Suppose your primary cluster has mounts:
aws/ kv/ cloud-team/ dev/ apps/
ansible/ customers/ help-desk/ automation/
Defining an allowlist with kv/
, cloud-team/
, dev/
, apps/
, and ansible/
means only those five will replicate; the rest are excluded.
Denylist Mode
A denylist lets you replicate everything except the paths you exclude. For example, with mounts:
gcp/ secrets/ eu-data/ k8s/
puppet/ rdt-team/ engineering-mobile/
Excluding eu-data/
, certificates/
, and encryption/
results in all mounts replicating except those three.
Local Mounts
If you need a mount to exist only on a secondary cluster (never replicated elsewhere), enable it with the -local
flag:
vault secrets enable -local -path=apac kv-v2
This command configures a KV v2 mount at apac/
on the secondary cluster (e.g., APAC) that does not replicate back to the primary or other replicas. You can also use -local
on the primary if you need non-replicated mounts there.
Note
Local mounts are ideal for region-specific workloads or test data that must not propagate.
Configuring a Paths Filter
Using the Vault UI
- In the Performance Replication section, add a new secondary cluster.
- Provide a Secondary ID and default TTL.
- Scroll to Filtered Paths.
- Select Allowlist or Denylist, then enter the desired paths.
Using the Vault CLI
Run:
vault write sys/replication/performance/primary/paths-filter/us-east-dr \
mode=allow \
paths=aws/,hcvop/,customers/
us-east-dr
is the Secondary IDmode=allow
selects allowlist modepaths=
lists the mounts to replicate
That wraps up how to configure allowlists, denylists, and local mounts in Vault’s performance replication. Experiment with these settings in your environment to meet your compliance and performance goals.
Links and References
- Personally Identifiable Information (PII)
- General Data Protection Regulation (GDPR)
- Vault Performance Replication
Watch Video
Watch video content