Hashicorp Vault - OIDC group membership

I know that you can set up both jwt and oidc authentication methods between GitLab and Hashicorp Vault. I’ve been able to do it successfully with the documentation.
But can it be done so that users are automatically assigned to groups in the vault after they log in and their identity is created? I was trying to set groups_claim in vault role to “groups” and I can log in, but my entity is not assigned to any group. I tried both when the group already created (external) and when there were no groups in Vault.

Hi @rgembalik
GitLab is not providing the group claim directly in the token, but only on /oauth/userinfo endpoint as mentioned in docs (bottom of the page)
Hashicorp Vault is expecting the claim to be in the token itself. So as far as I see it won’t work like you want :frowning:

I see. I was afraid that’s the case, but wanted to ask around in case I missed something semi-obvious. It would be cool though if GitLab could expose the group list in token when asked to (e.g. as additional scope).

You can try to create feature request for it. You never know :slight_smile:

I sure will once I have some spare time :slight_smile:

At the same time, I thought about this for a moment and I started thinking: Is the groups field really not in the token? The documentation specifically mentions using it in the bound_claims to filter access only to your own GitLab group (see step 4 in the docs ).

That makes me think that vault already has this information provided.

Hmmm, interesting. Good job finding it. I have to try it myself :slight_smile:

Let me know how it goes, cause for me those bounds work, but groups_claim and I’m curious if it works for other people.

After first quick try:

  • no group in Vault - user authenticated, no access (except default policy)
  • with existing external group (entity) AND alias linked to that group entity AND added policy to the group entity it worked! My group (entity) name and alias was the same = name of the group in GitLab, well the path in URL.

Damn, then, I have to be doing something wrong, because I already tried something like that. Do you mind sharing anonymized configs of role and auth method? Or some screenshots with sample data?

I am using Postman and calling Vault API. Using GitLab 13.10.2-ee and Vault 1.6.3

Configure OIDC auth:
URL: https://vault.example.com/v1/auth/oidc/config
Body: { “oidc_discovery_url”: “https://git.example.com”, “oidc_client_id”: “client_id_from_gitlab”, “oidc_client_secret”: “client_secret_from_gitlab”, “default_role”: “my-default”}

Configure OIDC role:
URL: https://vault.example.com/v1/auth/oidc/role/my-default
Body: {“name”: “my-default”, “role_type”: “oidc”, “user_claim”: “sub”, “bound_audiences”: “client_id_from_gitlab”, “groups_claim”: “groups”, “allowed_redirect_uris”: [“https://vault.example.com/ui/vault/auth/oidc/oidc/callback”, “https://vault.example.com/oidc/callback”], “oidc_scopes”: “openid”}

Create External Group:
URL: https://vault.example.com/v1/identity/group
Body: {“name”: “testgroup”, “type”: “external”, “policies”: “test-kv-access”}

Create Group Alias:
URL: https://vault.example.com/v1/identity/group-alias
Body: {“name”: “testgroup”, “mount_accessor”: “id_of_auth_oidc”, “canonical_id”: “id_of_external_group”}

So I did everything the same way, but now I see where my confusion came from:

I was expecting the OIDC user to appear under int the group members list. It didn’t
I did get access to the policy I specified as the one allowed for a given group. Once I removed the policy from the group - its read access ceased to exist (even on the existing lease).

@balonik Did you see your user entity among the users of the given group? Just checking if that’s still something I messed up, because it very well might be :slight_smile:

yep, I do have user’s entity in group members

Hmm… I don’t, but I still have access to the secret specified in the policy assigned to the group:

Did you use an actual numeric id of the GitLab group in the alias (or anywhere else for that matter) or did you use the slug that is a part of the group URL in GitLab? I used the textual slug for mine.

I have used the slug so the group in GitLab is actually called testgroup with URL gitlab.example.com/testgroup

I have tried it with Vault 1.7.0 and I don’t get user in group member list anymore.
I suppose this is something that changed between 1.6.3 and 1.7.0. So to sum it up:
1.6.3 - I get user entity as member of the group after login and I have the access from group’s policies
1.7.0 - I DON’T get user entity as member of the group after login and I have the access from group’s policies