Policies and OIDC users

Vault
1

Hi all,

I am new to this… very very new.

So my structure of the vault is as follows - it is all in one namespace btw.

Product (A)
| |_Infrastructure
| | |_Secrets
| | |_more secrets
| | |_etc
| |_App
| | |_Secrets
| | |_more secrets
| | |_etc
Product (B)
| |_etc

Currently I have oidc enabled on vault and one of the personas is secrets officer - the point of which is to enable different specified users to self administer (but not update the paths) of the different product paths.

Is the only way that I can do this is to have an AD group that is respectively:
|AD Group | OIDC Access Name | Policy
Secrets Officer Product A | Secret Officer A | Policy for Secret officer A
Secrets Officer Product B | Secret Officer B | Policy for Secret officer B

Or is there something more intelligent that can be done with the policy that looks at the AD group name and determines whether you are a secret officer with the ability to look at product a or b? (Otherwise i have to copy and paste policies each time a new product is added).

Sorry - my table formatting hasn’t worked :frowning:

2

In your structure, you don’t show any secrets engines or auth methods - is it implied that all of this is inside one big KV secrets engine?

What exactly does administer mean in this context?

Yes, you are going to need your own templating/automation outside of Vault itself to maintain the policies and group mappings.

Vault’s policy framework isn’t sophisticated enough to be able to process substrings out of group names and map that onto variable paths within the Vault URL-space.

3

Honestly your structure is a bit odd for a Vault setup so you may have made it harder to do dynamic policies.

In an enterprise with namespaces, you would do:

namespace → kv → app → secret(s) … in whatever path you want.
The “team owners/security people” get namespace/kv/* full access
The “app owners/devs” get namespace/kv/app/* full access

In a non-namespace you can replicate the above with either;

kv-team/app/secret(s)

or

kv/team/app/secret(s)

same policy structure.

Well groups make it easier to apply a policy to a set of users but obviously that’s not a requirement. It’s up to you on how you deploy your policies. AD groups → vault aliases are the easiest way to do this via LDAP or OIDC.

4

Thanks both - you could probably think of your example @aram as what i have as product being represented by your kv/team/app or kv/team/infrastructure entry.

@maxb ok - the important statement for me is the one around policies, so thanks for confirming.

To your initial questions though,

#1 actually there are secret engines and pki engines.
#2 create,read,update,delete at base - it may be harder to prevent them from creating or deleting new folders other then telling them not to do it. (It’s just that vault’s recently been added with general access for people and the path structure has been very very flat.

5

KV secrets engines and PKI secret engines, then? (“secrets engine” being a generic term for
any piece of pluggable functionality that you mount into the Vault URL-space, other than “auth methods” which are treated specially.)

So really your structure diagram was expressing a set of conventions you are defining, for slash-separated prefixes on the paths to where secrets engines are mounted.

Technically, Vault doesn’t really have folders - or at least, not ones you create and delete explicitly.

If I wanted a KV secrets engine at a/very/deeply/nested/path I could go right ahead and create it with the CLI command

vault secrets enable -path=a/very/deeply/nested/path kv

without needing to create any parent path segments first. (Assuming I had permissions, of course.)

Slash characters in the paths are special in how they interact with the /+/ wildcard syntax in ACL policies, but they’re not fully equivalent to paths in a regular filesystem.

A detail to watch out for here… the implications of these permissions vary a lot depending on exactly which paths are involved.

To give an example using the KV secrets engine (v2):

  • kv/config is an endpoint for configuring the secrets engine - it includes things like how many previous versions of values to retain
  • kv/data/... is where actual secret values are read from

You may very well have a case where you want your human secrets operators to be able to view and modify the first, but not the second.

With the PKI secrets engine, similarly there are endpoints for configuration, and endpoints for actually getting certificates signed.

So, two warnings:

1) Don’t expect policy on a top-level path like “product-a/*” to be all you’ll need - be prepared for use-cases needing more nuanced policies.

2) Think about how you’re going to permit people to configure those policies. Will all policy changes need to go through a small group of trusted Vault super-admins? Bear in mind that, other than the Enterprise Namespaces feature that you’re not using, Vault has no built-in functionality to let people manage policies, but only ones in a specific path subtree - so anyone who can manage policies, can grant themselves whatever access they like.

1 Like