According to the documentation, when configuring an OIDC auth provider, one has to also pass a “default” role, as in
vault write auth/oidc/config \
How can we achieve dynamic user <–> role mappings so that we establish a setup where user X gets assigned role A, user Y gets assigned role B and so forth?
“role” can mean many things in many different contexts.
In this context, “role” means “a configuration profile within the OIDC auth provider”. This kind of role is not one which gets assigned to a user.
Thanks for clarifying this.
So is there a way of making a mapping between users (entities) logging in with OIDC auth provider and vault policies?
This is done via the Vault Identity secrets engine.
You can assign policies to single users via their Identity Entity (
identity/entity/* APIs) or to groups via Identity Groups (
Entities are automatically created for each user when they first log in, if no matching one already exists, so the quick way to get some sample data is to log in and then look at the entity that was created for you. But, you can pre-create them before first login too, if needed.
Groups always need to be pre-created, and then Vault can update their membership from the groups claim in users’ tokens when they log in.
Vault has a slightly weird way of handling mapping of entities-a.k.a.-users and groups to external auth systems:
- First you create the entity or group. If it is a group that will track a group in an external auth system, you specify
external at this point.
- Then you create an entity-alias or group-alias. This maps the Vault entity or group, identified by its UUID (this goes in the
canonical_id parameter), to the (auth-method, name-within-external-system) pair - those go in the (