Delegate user/identity management outside of Vault

Vault
1

Hi :slight_smile:

tl;dr - I’d like to move user management to LDAP, but still have option to use other auth methods and keep policies set for (by?) LDAP auth method.

I want to introduce Vault as a secrets management solution in a considerably complex infrastructure spanning multiple (micro)services and other mostly automated users.

The users may be fit for authenticating with various auth methods, like Approle, k8s auth, etc. Managing each identity directly in Vault - in my perception - becomes hard. It’s not quite easy to lookup and edit entities. For that reason, I’d like to have users and groups in LDAP, centrally.

I successfully set up LDAP and groups, but following don’t seem possible:

  • My LDAP user is part of a group which has a policy attached. If I create another alias for the same underlying entity (e.g. userpass), login through the non-LDAP auth method won’t get me the group policy in resulting token.
  • Policy association can only be configured in Vault. Could it be done in LDAP via attribute?

Can one auth method cause another to pull some info from external identity provider? Or to achieve something similar, do I need to explicitly sync Vault with external system?

I’d be grateful for any advice!

2

Your mileage will vary because not every auth method supports groups. LDAP and userpassword do, I think OIDC does too (currently testing that with Azure-AD). AWS STS does not, others I don’t know.

So to answer your question, you need to move your authorization one abstraction level up. It means that:

  • Vault entities are assigned to Vault groups - must be an external group
  • Policies are attached to Vault groups
  • Create entity alias for each entity in each auth backend
  • When possible, create an group alias for your LDAP groups to map to Vault groups

So the authentication/authorization process is loosely as follow:

  1. User picks an auth backend and authenticate to it through Vault
  2. Vault will link (or create just-in-time) this authentication with a Vault entity using an entity-alias
  3. For backend that support it, Vault will map backend specific groups to Vault groups
  4. The token will get token policies, issued by the auth backend, if any. I underdstand that you want to move away from this and it a good practice.
  5. The token will also get identity policies, given by that higher level of abstraction provided by the identity backend
1 Like