JWT / Gitlab: Using template -> permission denied

Hello,

I was able to connect our Gitlab v17.8.2-ee with our Vault v1.10.10 via jwt/ and the following policy:

path "kv/data/ci_cd/example/vault_test/production/*" {
  capabilities = [ "read","list" ]
}

path "kv/metadata/ex/example/vault_test/production/*"
{
  capabilities = ["read"]
}

but, if I switch to a template one:

path "kv/data/ci_cd/{{identity.entity.aliases.ACCESSOR_NAME.metadata.project_path}}/production/*" {
  capabilities = [ "read","list" ]
}

path "kv/metadata/ci_cd/{{identity.entity.aliases.ACCESSOR_NAME.metadata.project_path}}/production/*" {
  capabilities = [ "read" ]
}

then it ends in a permission denied. Everything else stays the same. No changes on gitlab, or roles … just change the policy rules.

If we compare the access log on our Vault, the only diff is, that client_id is missing, if I use the template. Everything else looks the same:

...
    "metadata": {
      "project_path": "example/vault_test",
      "role": "exmaple-vault_test-production"
    },
...

I have no idea, what can be the issue.

any ideas ?

cu denny

Are you replacing ACCESSOR_NAME in the template with the actual accessor name?

It should look something like this:
{{identity.entity.aliases.auth_jwt_9d35541c.metadata.project_path}}

The mount accessor name can be retrieved by running vault auth list .

$ vault auth list

Path           Type          Accessor                    Description
----           ----          --------                    -----------
jwt/           jwt           auth_jwt_9d35541c           n/a
token/         token         auth_token_ca765385         token based credentials
1 Like

hi @michaelkosir

you are my hero :slight_smile: I totally read over this small thing:

. The mount accessor name (ACCESSOR_NAME in the example below) can be retrieved by running vault auth list.

Thanks a lot !

1 Like