Gitlab OIDC group claims mapping

Vault
1

Hi all,

I have configured Gitlab JWT and Gitlab OIDC auth backends in Hashicorp Vault. Both of usecases work properly. Gitlab pipeline jobs could access secrets in Vault. Users authenticated via Gitlab OIDC could access their secrets according policy as well. Now I am trying to write templated policy so users could manage secrets used in pipeline jobs, based on their Gitlab group memberships. For this, I planned to use group claims returned by Gitlab OIDC identity provider and map them to alias metadata so group info could be then used in templated policy. There are five group related claims available (GitLab as OpenID Connect identity provider | GitLab):

groups
groups_direct
https://gitlab.org/claims/groups/owner
https://gitlab.org/claims/groups/maintainer
https://gitlab.org/claims/groups/developer

I am able to map groups and groups_direct claims using claim mappings below, but it does not work in same way for other group claims.

vault write auth/gitlab_oidc/role/gitlab_oidc_default - <<EOF
{
    "claim_mappings": {
        "/groups_direct/0": "direct_group_0",
        "/groups_direct/1": "direct_group_1",
        "/groupst/0": "group_0",
        "/groups/1": "group_1"
    }
}
EOF

No matter how I define claim_mappings for https://gitlab.org/claims/groups/owner, it does not work.

When claim_mapping is defined like "/groups/owner/0": "group_owner1", it ends up with warning and not being mapped:

2022-05-31T14:32:03.221Z [WARN] auth.oidc.auth_oidc_d834cfd1: unable to locate /groups/owner/0 in claims: /groups/owner/0 at part 1: couldn't convert value "owner" to type int

Why is Vault trying to convert that claim to integer instead of string?

When claim_mapping defined as "https://gitlab.org/claims/groups/owner/0": "group_owner1", it is not throwing any message in log but not mapped anyway.

So could someone please suggest proper way to define claim_mappings for https://gitlab.org/claims/groups/owner claim?

Also I would like to know if there is some better way to parse group claim arrays to individual groups so i dont need to specify mappings for 20 group claim array elements. This does not scale very well. Same question apply then to templated policy as well. Is is possible to write policy using some regular expresions to access metadata values?

Both Gitlab and Hashicorp Vault are deployed on-premise.

Versions:
GitLab: 14.7.2-ee.0
Vault: 1.9.2

Thank you

2

I don’t think you should be trying to pull individual indexes out into separate fields in this way - I can’t think of a way in which this will end well.

Because you are applying the JSON pointer /groups/owner/0 to JSON where the "groups" key in the top level, is of array type, and therefore requires an integer index.

Because there is no claim named literally "https://gitlab.org/claims/groups/owner/0". As there is no leading / this is a literal string match.

I imagine you would need to escape the / characters in the URL, so they are not interpreted as separators in JSON Pointer syntax. I have never done this but according to RFC 6901 - JavaScript Object Notation (JSON) Pointer a / is escaped as ~1, implying something like /https:~1~1gitlab.org~1claims~1groups~1owner/0.

Vault ACL policy templating is sadly not powerful enough to be usefully used to make decisions based on group membership, in my experience.

3

Could you please elaborate more on this topic, please? Are there some caveats or risks using indexed array members the way I am using them?

So proper escaping is what was needed to solve my issue. I tried backslashes to escape slashes but obviously without luck. Now it is working as required.

I cannot disagree. That’s why I am using claim mappings and alias metadata in templated policy as a workaround for now.

Let me know if you have some other comments on actual usage.

Thanks a lot for escaping hint!

4

Since you have no guarantees in which order groups will be listed in the claims, I don’t see how you will be able to write reliable access rules using this mapping.

Also, it will be very easy for users being added to additional groups to disrupt assumptions, by causing indexes to change.