Skip to main content
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.
Replicating PII or sensitive data outside regulated regions can lead to compliance violations and hefty fines under laws like GDPR.
The image illustrates data replication between a primary cluster in Europe and a secondary cluster in APAC, highlighting regulatory compliance considerations like GDPR. It includes labeled data categories and a note on performance replication.
In this example, sending customers/ or credit-cards/ from an EU primary to an APAC secondary would breach GDPR.
The image illustrates data replication between a primary cluster in Europe and a secondary cluster in APAC, highlighting that certain data (e.g., customer data) may be restricted from replication due to regulatory compliance like 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).
ModeBehaviorExample Use Case
AllowlistOnly listed paths are replicated.Replicate EU-only Secrets Engines to an EU replica.
DenylistAll 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.
The image explains a "Paths Filter - Allowlist" concept, showing which paths are included for replication to a secondary system, with a list of paths that will and will not be replicated.

​
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.
The image explains a "Paths Filter - Denylist" concept, showing that all paths will be replicated except for those on the denylist, which includes "eu-data/", "certificates/", and "encryption/".

​
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.
Local mounts are ideal for region-specific workloads or test data that must not propagate.
The image illustrates a concept of local mounts in a database cluster setup, showing a primary cluster in Europe and a secondary cluster in APAC, with a focus on preventing certain data from being replicated across the replica set.

​
Configuring a Paths Filter

​
Using the Vault UI

  1. In the Performance Replication section, add a new secondary cluster.
  2. Provide a Secondary ID and default TTL.
  3. Scroll to Filtered Paths.
  4. Select Allowlist or Denylist, then enter the desired paths.
The image is a guide on creating a paths filter for a secondary token in a performance cluster, with instructions on configuring settings, selecting list types, and adding paths. It includes a Vault certification badge and a cartoon character illustration.

​
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 ID
  • mode=allow selects allowlist mode
  • paths= lists the mounts to replicate
The image shows a configuration screen for creating a paths filter, with settings for a mount filter config for "us-east-dr" in allow mode, and paths including "aws/", "customers/", and "hcvop/". It also features a Vault certification badge and a cartoon character.
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.

Watch Video