Allow agent user access sharing across top level groups
What does this MR do and why?
Previously a project/group that was authorized for user access had to share a root ancestor with the agent configuration project.
On GitLab.com this is typically not a problem, as most projects/groups that would be authorized already belong to the same top level group. However, self-managed installations often structure their hierarchies differently with multiple top level groups, which limits the usefulness of the agent.
With this change, any project or group on the instance can be specified in the agent configuration file, regardless of root ancestor.
This functionality will not be available on GitLab.com, and is
controlled by the organization_cluster_agent_authorization_enabled
application setting.
References
How to set up and validate locally
- Go to Admin -> Settings -> General -> GitLab agent for Kubernetes, and enable
Enable instance level authorization. - Create a new top-level group, and create a project within it to be the agent configuration project. For example,
group-1/agent-project. - Create a second top-level group, and create a project to be the authorised project. For example,
group-2/authorised-project. - Register an agent in the agent configuration project with the following config:
user_access: projects: - id: group-2/authorised-project # or whatever you called your second group/project - Add a user as a maintainer of the authorised project, that is not a member of the first top-level group or the agent configuration project.
- Impersonate the user, and in the authorised project, go to Operate -> Environments -> New environment and create a new environment. Your agent should show in the "GitLab agent" field. Select this agent and submit the form, and the Kubernetes dashboard should be visible.
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.