Group access tokens?

[milkpirate]

What problem are you facing?

We have a gitlab instance which is heavily managed by another team. We would like to use group access token (GAT) to manager repo aso. and our dedicated group. Since I seem to face problems (provider is not finding existing repos) when I use the GAT as a personal access token (PAT). I first want to make clear if

• Does the provider support GATs at all?
• Is it the right way to hand them over via PersonalAccessToken method?

How could Crossplane help solve your problem?

If the answer to any of the above: Could GATs be implementd?

[BoxBoxJason]

Hey there,

As I understand it, GitLab Group Access Tokens are meant for API access and broader automation tasks. They can be granted different scopes, so with the right permissions they can perform many actions through the GitLab API.

Deploy tokens, on the other hand, are more limited and are typically used for repository or registry access in deployment workflows.

That said, both resource types are supported by this provider:

• Group Access Token example
• Group Deploy Token example

[milkpirate]

Oh, I'm sorry, I did not make clear that I mean the field in the ProviderConfig.

It's not about managing these objects though the provider is about configuring it.

[markussiebert]

Thanks @milkpirate - to separate the two things being asked:

• Managing GAT resources (creating group access tokens through the provider) - supported via the AccessToken CRD, as noted above.
• Using a GAT as the ProviderConfig credential (what you're actually after) - also supported, and PersonalAccessToken is the correct method.

On the method: a GitLab Group Access Token is a bot-user personal access token under the hood - it authenticates with the PRIVATE-TOKEN header exactly like a PAT. The provider's PersonalAccessToken method does precisely that, so there's no separate "group access token" method and none is needed. GitLab doesn't distinguish the two at the auth layer.

spec:
  credentials:
    source: Secret
    method: PersonalAccessToken   # correct for a GAT
    secretRef:
      namespace: crossplane-system
      name: gitlab-credentials
      key: token

Why you're "not finding existing repos": that's a scope/permission boundary of the GAT, not a provider limitation. A group access token is confined to its own group. Three things to check, in order of likelihood:

1. Visibility boundary (most likely): a GAT can only see projects and subgroups within its own group. Unlike an instance-admin PAT, it cannot see or list projects elsewhere on the instance. Since your instance is managed by another team, any repos outside your dedicated group simply won't be visible to the GAT - that's GitLab's design. (Nesting matters too: a token on the top group sees everything beneath it; a token on a subgroup can't see the parent or siblings.)
2. Token scope: it needs api (read+write) - or at least read_api for read-only flows. A read_repository-only token can't drive the projects/groups API.
3. Bot role: the token's access level in the group must be high enough (Reporter to read, Maintainer/Owner to manage).

Bottom line: using a GAT via method: PersonalAccessToken is the right, fully-supported approach. It will work for resources inside the token's group as long as the token has api scope and a sufficient role - it just can't give instance-wide visibility. If the resources you're targeting live outside your group, you'd need a token that can actually see them.

Closing as supported (auth works with a GAT; the visibility limit is GitLab's scoping, not a provider gap) - happy to reopen if a specific resource still isn't resolving after checking the above.