Consolidate GitLab Service accounts and Kubernetes Service accounts

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem

In GitLab Kubernetes integration, there are several ways to control access to Kubernetes from GitLab projects, users and pipeline jobs. For example,

  • ci_access keyword allows pipeline jobs in specified projects/groups to access to the agent. By default, the service account/role is inherited from agentk, which is Admin access. Additionally, impersonation is available to map to the other service account/role for narrowing permissions.
  • user_access keyword allows members in specified projects/groups to access to the agent. Similar to above, impersonation is available.

At the glance the feature behaviors look semantically correct, however, this is not quite aligned with GitLab RBAC, for example,

  • Say, a project is allowed to access a cluster via ci_access. This means all of the users who have permission to run pipelines in the project effectively gain an access to the cluster i.e. they can't directly connect to the cluster but can exploit the cluster by running whatever jobs. This is stepping into the toes of user_access.
  • Say, members of a project is allowed to access a cluster via user_access. They can directly access to the agent, however, they can't access to the agent from CI job even though CI jobs authorize the user access already. If the user can access, the jobs triggered by the user should allow it as well.
  • Even if a user is allowed to access to an agent with ci_access/user_access keyword, they can't fetch agent config info that exists in the agent owner project because the application-deployer might not be a member of the agent owner project. Related to #391610 (closed). i.e. Kubernetes RBAC allows the access, but GitLab RBAC doesn't allow the access.

Proposal

Consolidate GitLab Service accounts and Kubernetes Service accounts. At first, users should create GitLab Service accounts into their deployment projects. Project Access Token already has this capability. For example,

Frontend Project:
  - Service account (Maintainer role) - Read-write access
    Flux/Agent can use this PAT to sync with GL project
  - Service account (Reporter role) - Read-only access
    GitLab Environment can use this account to fetch the resources from agent
Backend Project:
  - Service account (Maintainer role) - Read-write access
    Flux/Agent can use this PAT to sync with GL project
  - Service account (Reporter role) - Read-only access
    GitLab Environment can use this account to fetch the resources from agent

Secondly, Agent Owner project can map the GitLab service accounts to Kubernetes service accounts:

# agent config file

service_accounts:
  - gl-service-account:   org/backend:rw-service-account
    kube-service-account: backend-rw-service-account
  - gl-service-account:   org/backend:ro-service-account
    kube-service-account: backend-ro-service-account
  - gl-service-account:   org/frontend:rw-service-account
    kube-service-account: frontend-rw-service-account
  - gl-service-account:   org/frontend:ro-service-account
    kube-service-account: frontend-ro-service-account

Additionally, these gl-service-accounts have View cluster permission in the agent owner project. This allows these service accounts to fetch agent info via GraphQL.

A few notes:

  • Project access token is better than Deploy Token by multiple reasons. 1) PAT is supported in Audit Events 2) Users can see which service account created resources in GL projects, like deployments 3) Deploy Token is user-less token therefore it can't accomplish the same thing.
  • GL Service accounts should be able to have environment-scope. See &9859 (comment 1286841562).
Edited by 🤖 GitLab Bot 🤖