Only one local agent connection can be configured with glab

Summary

The command glab cluster agent update-kubeconfig --repo '<group>/<project>' --agent '<agent-id>' --use-context generates a Kubeconfig user entry of the form

- name: gitlab_com-nagyv-gitlab
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1
      args:
      - cluster
      - agent
      - get-token
      - --agent
      - "1087045"
      command: /opt/homebrew/bin/glab
      env: null
      installHint: "To authenticate to the current cluster, glab is required. \n\nFollow
        the installation instructions at https://gitlab.com/gitlab-org/cli#installation.\n"
      interactiveMode: Never
      provideClusterInfo: false

The name given includes the authenticated user, but not the agent id 1087045. As a result, running the command for two different agents, results in a single user record.

Steps to reproduce

  1. Add local access to these agents: https://gitlab.com/gitlab-org/ci-cd/deploy-stage/demos/infra-platform/-/clusters
    1. Run glab cluster agent update-kubeconfig --agent 1087045 --use-context --repo gitlab-org/ci-cd/deploy-stage/demos/infra-platform
    2. Run glab cluster agent update-kubeconfig --agent 1087043 --use-context --repo gitlab-org/ci-cd/deploy-stage/demos/infra-platform
  2. Check the clusters

Example Project

https://gitlab.com/gitlab-org/ci-cd/deploy-stage/demos/infra-platform

What is the current bug behavior?

Only one cluster can be accessed because only one "user"/agent can be configured at once using the GitLab CLI.

What is the expected correct behavior?

Multiple cluster connections should be supported.

Instead of calling the user name: gitlab_com-<gitlab username>, I recommend calling it name: gitlab_com-<agent id>. Storing the username as part of the config does not matter as the user might log out with the GitLab CLI and log in again as a different gitlab user.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:check SANITIZE=true)

(For installations from source run and paste the output of: sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)

(we will only investigate if the tests are passing)

Possible fixes

Proposals

  • Update agent_update_kubeconfig.go to set the authInfoName from gitlab_com-<gitlab username> to gitlab_com-<gitlab agent id>.
Edited Feb 21, 2024 by Timo Furrer
Assignee Loading
Time tracking Loading