GraphQL userAccessAuthorizedAgents returns an empty list for an admin in admin mode

Summary

Project.userAccessAuthorizedAgents returns an empty list for an instance administrator in admin mode who is not a member of the project. A user with the Developer role on the same project gets the expected list.

The field is authorized with :read_cluster_agent, which an administrator passes, so the query succeeds and returns no data. There is no permission error, so the field looks like it is telling you no agent is authorized.

🛠️ with ❤️ at Siemens

Steps to reproduce

You need a GitLab Self-Managed instance or a GDK, because admin mode is not available to you on GitLab.com.

1. Create a group example-group with two projects, agent-project and deployment-project.

2. In agent-project, create an agent for Kubernetes named my-agent, and commit this configuration file to the default branch:

   # .gitlab/agents/my-agent/config.yaml
   
   user_access:
     access_as:
       agent: {}
     projects:
       - id: example-group/deployment-project

   The push to the default branch registers the user access authorization. You do not have to install agentk in a cluster, because the bug is in how GitLab resolves the authorization.

3. Add a second user as a Developer on deployment-project.

4. Sign in as that Developer and run the query in /-/graphql-explorer:

   query {
     project(fullPath: "example-group/deployment-project") {
       userAccessAuthorizedAgents {
         nodes {
           agent {
             name
             project {
               fullPath
             }
           }
         }
       }
     }
   }

   my-agent is listed. This confirms the setup works.

5. Sign in as an instance administrator who is not a member of example-group, agent-project or deployment-project, and enable admin mode.

6. Run the same query again. nodes is empty.

What is the current bug behavior?

The administrator in admin mode gets an empty list:

{ "data": { "project": { "userAccessAuthorizedAgents": { "nodes": [] } } } }

What is the expected correct behavior?

The administrator in admin mode gets the same list as the Developer:

{
  "data": {
    "project": {
      "userAccessAuthorizedAgents": {
        "nodes": [
          {
            "agent": {
              "name": "my-agent",
              "project": { "fullPath": "example-group/agent-project" }
            }
          }
        ]
      }
    }
  }
}

Output of checks

Reproduced on GitLab 19.3.0-pre. This is not a regression: the two scopes below have had no admin path since they were added.

Possible fixes

Both scopes behind Clusters::Agents::Authorizations::UserAccess::Finder resolve authorizations from membership alone, and neither has an admin path:

• ProjectAuthorization.for_user joins project_authorizations and filters on user_id
• GroupAuthorization.for_user builds from the user's group memberships

An administrator without an explicit membership matches neither, so the finder returns nothing.

The finder is the right place for the fix. It has six callers, and all six have the same bug, so an administrator in admin mode is also rejected by the KAS user access proxy and by the environment services when setting a cluster agent on an environment.

Fix proposed in !169626 (merged).