For Vault Enterprise, operators typically use namespaces as a way to create multi-tenancy in Vault. The Vault admin would create a namespace per team. That team is then responsible for all config in that namespace. This encourages a self-service strategy. Each namespace would have its own auth methods, secrets engines, policies, and so on. Think of it as a mini-vault. Here are the namespace limits.
For Vault OSS, Vault admins would create a path strategy for a secrets engine. So for the kv secrets engine, they would have a path like this: kv/line-of-business-a/team-a/app-a/secret-a. Policies would be created based on these paths. There are pros and cons to using multiple mount points vs the method I just mentioned. Take a look at this mentioned in this helpful doc. Nevermind the namespace here, consider the root namespace in OSS. Here are the mount point limits.
When thinking about Vault's logical structure, you want to find the right balance of granularity between the various mounts needed and the roles defined within the mounts.
Sharing mounts between teams has benefits and risk. It is up to you to find the right balance of granularity between the various mounts needed and the roles defined within the mounts. Below are a couple use cases with their benefits and risks.
You create a single KV mount with a sub-path for every team within the same mount.
- Benefit: reduces potential of hitting mount table limits.
- Risk: the KV mount is accidentally deleted causing all users of that secret engine to be impacted.
You create a unique mount per LOB.
- Benefit: can provide sub-paths for different teams and limit the blast-radius of an errant change to a single mount.
- Risk: unique KV mounts per team becomes inefficient from a mount management perspective.