GitLab Group / AD Group sync use case with Vault

What's this issue all about? (Background and context)

What hypotheses and/or assumptions do you have?

What questions are you trying to answer?

What research methodology do you intend to use?

What persona, persona segment, or customer type experiences the problem most acutely?

Customer is looking to GitLab groups to be able to map that back to their Org's AD groups. Customer is saying that this is all they get in the JWT token…but there are no GL groups here. They are having problems linking the GL group to the AD group to narrow access rights to secrets via the GL group

There is an AD Sync option for GL but that wouldn’t appear to fix the issue of using a group in the claim to tie it to the correct Vault role

JWT is for CI/CD and OIDC is for user authentication, right? We can find an example of binding the project to a vault policy for CI/CD and a user to a gitlab group membership via oidc.

In this case, its a pipeline doing the authenticating... customer wants to be able to make sure a user is in a correct AD Group before they allow them to do a thing in Vault... we could map a user & Group to a vault role if it was available as a bind claim. The docs say to use namespace_id or project_id but that is a pretty wide open group for their needs.

Things suggested and tried:

you want vault to validate WHO triggered the pipeline (and what AD groups they belong)? The JWT does have the user_id but GitLab would not know what AD groups that user belong.

For example, for project based JWT auth. This ensures that this project has the policy aws-read.

###
resource "vault_identity_group" "project-14379212" {
  # https://gitlab.com/gitops-demo/infra/aws
  name     = "project-14379212"
  type     = "external"
  policies = [ vault_policy.aws-read.name ]
  metadata = {
    version = "1"
  }
}
resource "vault_identity_group_alias" "project-14379212-alias" {
  # This is the bridge between the gitlab group and the vault group.
  # https://gitlab.com/gitops-demo/infra/aws
  name           = "14379212"
  mount_accessor = vault_jwt_auth_backend.gitlab-runner.accessor
  canonical_id   = vault_identity_group.project-14379212.id
}
resource "vault_policy" "aws-read" {
  name = "aws-read"
  policy = <<EOT
# Read secret/infrastructure/aws
path "secret/data/infrastructure/aws" {
  capabilities = ["read"]
}
EOT
}

Customer wants to validate who triggered the pipeline. Also, I saw that the JWT had the userid... but AD group aside, Vault would have no way of knowing what GitLab group they are a part of to map to a role.

Example above makes sense... but... the problem is that here:

resource "vault_identity_group_alias" "project-14379212-alias" {
  # This is the bridge between the gitlab group and the vault group.
  # https://gitlab.com/gitops-demo/infra/aws
  name           = "14379212"
  mount_accessor = vault_jwt_auth_backend.gitlab-runner.accessor
  canonical_id   = vault_identity_group.project-14379212.id
}

The project.id is what you are keying off of as the bridge between the vault group and the gitlab group, yes? Can't a project have multiple groups as members? --- Could be a typo, tt's a map from gitlab project id to vault_identity_group (not gitlab group).

so it stands... Customer would need a more granular capability surfaced in the JWT.

How hard of a feature request would it be to get the group or group_id added to a JWT?

FWIW: Adding project_parent_group_id is a nice to have. Then I think I could add a Vault Policy for a a whole group and not project by project.

Vault mapping to be the hardest part. FYI, you can already do this:

claim_mappings = {
    namespace_id   = "namespace_id"
    namespace_path = "namespace_path"
    project_id     = "project_id"
    project_path   = "project_path"
  }

The mappings of vault_identity_group and vault_identity_group_alias were limiting.

resource "vault_jwt_auth_backend_role" "gitlab-runner" {
  backend        = vault_jwt_auth_backend.gitlab-runner.path
  role_name      = "gitlab-runner"
  role_type      = "jwt"
  token_policies = ["default", vault_policy.project-tmpl.name]
  user_claim   = "project_id"
  groups_claim = "project_id"
  bound_claims = {
    iss = "gitlab.com"
  }
  claim_mappings = {
    namespace_id   = "namespace_id"
    namespace_path = "namespace_path"
    project_id     = "project_id"
    project_path   = "project_path"
  }
  token_ttl     = 60
  token_max_ttl = 3600
}

I could only figure out how to pick one value to map to the policy.

What business decisions will be made based on this information?

How hard of a feature request would it be to get the group or group_id added to a JWT?

What, if any, relevant prior research already exists?

See above and internal slack convo here