More granular access control for kubernetes integrations (custom namespaces)
Problem to solve
When using custom namespaces, you can't define service accounts per namespace/sub-group to separate access. By default, all sub-groups have access to the cluster-admin token defined in the top-level group integration.
My scenario involves the following:
Information to assume:
We need to use custom namespaces, therefore Gitlab managed namespaces is turned off. Because of this, all child projects/sub-groups use the cluster-admin service account defined in the parent group.
I need to separate permissions by namespace and environment. Example: Group A can't deploy to Group B's namespaces. Group A/B only deploy to the DEV/TEST/Prod clusters in their own namespaces using their own service accounts.
Use Case: When a large customer tries to migrate to Gitlab CI/CD with existing kubernetes infrastructure, its likely impossible to use gitlab managed namespaces/service accounts due to naming conventions and security restrictions. In order to make it easier for new CI/CD customers to on-board with pre-existing large kubernetes deployments at the group (or even instance level), it should be simple to define namespaces with linked service accounts per environment.
Ideas to fix the issue: (Assume Group-level k8s integrations)
- Don't instantiate the cluster-admin service account config to subgroups/projects (Maybe a checkbox to enable/disable?)
- When setting up environments for a sub-group/project, define a service account token for the environment (Namespaces can already be defined via gitlab-ci.yml). Personally, I would prefer to do this at a sub-group level in order for all sub projects to use the config without manually adding it for every new repository.
Permissions and Security
Similarly to the existing kubernetes settings, you need to be a group owner to manage this configuration.