GitLab + JWT + Vault + AD Group

[felipeng84]

Hi all,

I am working on the integration between GitLab + JWT + HashiCorp Vault and AD. My environment is on-premise and both has AD integration for authentication:

• GitLab: 14.10.0-ee ( Premium)
• Vault: 1.2.3 (OpenSource)

Currently: It is working when I specify a list of users in the bound_claims, like:

"user_claim": "user_login",
  "bound_claims": {
    "user_login": ["user1", "user2"]
  }

My goal: Instead of using a list of users I would like to use a list of AD groups, in order to
validate if the user is a member of a particular group. Something like this pseudocode:

"groups_claim": "ad_groups",
  "bound_claims": {
    "ad_groups": ["devops"]
  }

Currently Vault configuration:

vault auth enable jwt
vault write auth/jwt/config jwks_url="https://gitlab.acme.com/-/jwks" bound_issuer="gitlab.acme.com"
vault secrets enable -path=sfcc kv-v2
vault policy write prd-sfcc - <<EOF

path "sfcc/data/prd*" {
  capabilities = [ "read", "list" ]
}
EOF

vault write auth/jwt/role/prd-sfcc - <<EOF
{
  "role_type": "jwt",
  "policies": ["prd-sfcc"],
  "token_explicit_max_ttl": 60,
  "user_claim": "user_login",
  "bound_claims_type": "glob",
  "bound_claims": {
    "project_path": "dev/myproject",
    "ref_type": "tag",
    "user_login": ["user1", "user2"],
    "environment_protected": "true",
    "environment": "Production"
} }
EOF

Any idea how I could validate if the user who started the job (user_claim) is member of specific AD group?

[maxb]

@felipeng84

Vault: 1.2.3

This is a really really old version of Vault - it doesn’t make sense to be using such an old version for any new work.

@felipeng84

Something like this pseudocode:

"groups_claim": "ad_groups",
  "bound_claims": {
    "ad_groups": ["devops"]
  }

Does that not work as is? It seems to me like it should.

@felipeng84

path "sfcc/data/prd*" {
  capabilities = [ "read", "list" ]
}

Please be aware you can’t "list" on the /data/ subpath of a KVv2. The list operation is defined on the /metadata/ subpath.

[felipeng84]

@maxb

@felipeng84

Vault: 1.2.3

This is a really really old version of Vault - it doesn’t make sense to be using such an old version for any new work.

Good point there is a task on our roadmap to upgrade Vault.

@felipeng84

Something like this pseudocode:

"groups_claim": "ad_groups",
  "bound_claims": {
    "ad_groups": ["devops"]
  }

Does that not work as is? It seems to me like it should.

This is a pseudocode, I just invented those keys/values

@felipeng84

path "sfcc/data/prd*" {
  capabilities = [ "read", "list" ]
}

Please be aware you can’t "list" on the /data/ subpath of a KVv2. The list operation is defined on the /metadata/ subpath.

Right, I will update the capabilities

[maxb]

@felipeng84

This is a pseudocode, I just invented those keys/values

Then, good guess, it looks like correct actual config to me! Give it a try!

[felipeng84]

No way hehe
Well, I tried, and I got: "groups_claim": "ad_groups", :api error: status code 400: "ad_groups" claim not found in token

Which means that GitLab is not providing the AD group in the JWT token (Authenticating and reading secrets with HashiCorp Vault | GitLab)
So, I am out of luck, or is there any other way for Vault to validate based only with the username?

[maxb]

Oh, I see.

If the information is not available in the JWT, then there is no way to have Vault provide this enforcement directly.

I had assumed that you had a more usual JWT of the kind a generic OIDC identity provider would produce - sorry, I’m not familiar with GitLab jobs.

Unless you can enforce restrictions at a different layer, such as limiting which users can trigger the jobs at all, I think it would probably be necessary to implement a custom Vault auth method plugin to get the behaviour you are looking for. (It would need to do its own LDAP lookup to get group information.)