Vault secret engine...
 
Notifications
Clear all

Vault secret engine and path creation strategy

3 Posts
2 Users
0 Likes
422 Views
0
Topic starter

Can u pls give some info what should be the strategy when we're creating secret engine? 

let's say kv (we can add DB or AWS etc. can it be different depending on secrets engine type?). only one secret engine for KV and then secrets under it or secrets engine for each department and paths under each department's secret engine? or based on team? can you pls give some examples based on your experience and share some use cases? do we have some limitations?

thx,

1 Answer
0

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.

Granularity of paths

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.

Vaultman Topic starter 13/06/2023 11:53 am

@sam-gabrailtekanaid-com what would be your questions and possible answers to make a decision? is LOB=OU? what's is your preference based on your experience especially in OSS since we don't have NS? after creation how we manage and maintain and support the teams? possible errors problems and troubleshooting? deletion/migration etc?

Sam Gabrail 14/06/2023 8:01 pm

Yes LOB is Line of Business and can typically be mapped to the OU. Think of the usa-hq namespace above as the root namespace in an OSS Vault cluster. My preference would be the first example. To create a single KV mount with a sub-path for every team within the same mount.

Each path will have a policy attached to it and tied to the auth method so the team will have access only to their own path.

Share:
Scroll to Top