GitLab Agent for K8S Failing to Authorize Instance-level Agents
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
A user deploying the GitLab Agent for K8S has been experiencing difficulty finding configuration to allow mapping Gitlab Groups and subgroups to either namespaces or RBAC roles with an instance wide agent. An internal issue was opened for researching the issue and the conclusion was that the problem would be addressed with the fix for issue 377932 in 18.1. They recently updated to 18.1 and their underlying issue remains - that configuring per-group agents does not work for their use case, as the configuration of the agent is managed by the team that controls each group. They can see the contexts for all the agents, but when they target an environment they should only see the correct contexts for the agents from all regions in that environment, not across all environments. If the team can modify the configuration of the agent that is supposed to restrict them to namespaces authorized by the containers platform team, then that defeats access control entirely.
I'm making this a Public issue as the customer has been waiting on a fix for this issue for some time and would appreciate an opportunity to work with the team directly instead of relaying information back and forth through a Support ticket.
What is the current bug behavior?
Agents are not respecting the Access Control List when added at the instance level. Only allowing all agents on the instance enables access.
What is the expected correct behavior?
Only the agent configured for access should be available to the configured groups.
Relevant logs and/or screenshots
I'm including the logs and configuration in an internal comment because it has internal customer details.
Results of GitLab environment info
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
Patch release information for backports
If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.
Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.
High-severity bug remediation
To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.