Inconsistency in user access document
Problem to solve
I made a mistake in !761 (merged). It is not possible to correctly implement the endpoint POST /api/v4/internal/kubernetes/authorize_proxy_user
because it is not possible to determine the authorization source: If the user has access via two different sources, we do not know which one to choose.
Proposal
At the moment, I can think of two ways forward:
Option 1: Always pass the project ID or group ID as well.
- When calling these APIs on the GitLab frontend, we can probably do this most of the time (if we're on the page for a group or a project, we can fill this in), but it means that a user can visit the same agent on different projects and have different abilities each time, depending on the RBAC for each project.
- However, this limitation also applies to PAT and OIDC access. We could follow the same pattern as with the job token and use prefixes (the token comes last because we don't know if it will contain
:
)gitlab:project:$project_id:oidc:$token
gitlab:group:$group_id:oidc:$token
gitlab:project:$project_id:pat:$token
gitlab:group:$group_id:pat:$token
Option 2: Revert !761 (merged) and instead go with #312 (comment 1121078022), i.e. always impersonate UserName:gitlab:user:<username>
, but let Groups
in GitLab Premium include more information.
- In this approach, the user will have uniform access to a given agent across projects. This can also be confusing, since two users with the same access level in a given project can see different things in that project if their roles vary in other projects.
Option 3: Revert !761 (merged), but add a top-level impersonation setting:
user_access:
access_as: { agent: {} } | { user: {} }
projects: [...]
groups: [...]
where impersonate
applies to all the projects
and groups
. When using user impersonation.