FAQ

Replication Path Filtering: Mount Filters in Vault Namespaces

With mount filtering, we can decide which secrets end up in which regions with Vault. Now owners of Vault Enterprise namespaces can set the rules for those filters.

Speakers

Transcript

This is Dan McTeer. I'm a Technology Specialist for HashiCorp. I wanted to talk to you today about the concept of replication filtering. Mount Filters have been in place in Vault for quite some time, and we're now adding that functionality to namespaces to give you a greater level of manageability.

Mounts, Namespaces, and Replication

To explain the concept of filtering, we first need to understand the concepts of mounts and namespaces and replication inside of Vault. A mount is the basic structure inside of Vault. It's essentially a path where a secret is stored.

Later in the Vault lifecycle we came up with the concept of namespaces, which essentially allows you to run a Vault within a Vault. But it uses the same sort of pathing structure that we have available in simple mounts. You can build mounts inside of namespaces, and it gives you the opportunity to isolate those secrets that you're storing apart from other secrets.

When replication comes into play, we're taking what we have here, and we're moving it—we're duplicating it—into other clusters. We may have a cluster over here on the East Coast, and we may have a cluster here in Europe. With replication, we can essentially take this secret value, and we can make a copy of it here and make a copy of it here.

Filtering by Location

When filtering comes into play, the cool part is we can decide which secrets end up in which places. For instance, I can say here at this mount, this secret can only go to the East Coast and nowhere else. And here in this namespace for this mount, I can say I want that to go to EMEA and nowhere else.

The cool part of this feature is that for certain situations where you have legal requirements or other sorts of fencing—untrusted areas—you can decide what goes where. The real value here is that for GDPR, for instance, where you have stricter compliance requirements inside of places like Europe, you can decide to isolate secrets within Europe—you can isolate specific pieces of data using those secrets inside of Europe.

Deploying Infrastructure in an Untrusted Environment

You may even have an untrusted environment. You might be deploying infrastructure in China, for instance, where you want secrets to be managed completely differently in an area like that where you can't inherently trust that situation. Replication and filtering come into play again where you decide I'm going to keep this set in China and nowhere else.

Mount filtering has existed in Vault for quite a while now, which is great in a general sense when you're managing a general group of secrets. An upcoming version of Vault (now available) will have the ability to apply those Mount filters to namespaces. With the concept of namespaces where you have a Vault inside of Vault, we're giving the control of managing that namespace and its associated mount filters to the owner of that namespace—to give you a greater level of self service and independence across your user base.

To learn more about mount filtering and how to use mount filtering, visit our documentation or go to learn.hashicorp.com.

More resources like this one

  • 4/11/2024
  • FAQ

Introduction to HashiCorp Vault

Vault identity diagram
  • 12/28/2023
  • FAQ

Why should we use identity-based or "identity-first" security as we adopt cloud infrastructure?

  • 3/14/2023
  • Article

5 best practices for secrets management

  • 2/3/2023
  • Case Study

Automating Multi-Cloud, Multi-Region Vault for Teams and Landing Zones