More granular access control for kubernetes integrations (custom namespaces)

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

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.

Group Structure:

Screen_Shot_2020-04-21_at_2.57.07_PM

Intended users

Further details

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.

Proposal

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.

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited by 🤖 GitLab Bot 🤖