Decide if we want to remove support for _adding_ non-RBAC clusters

Problem to solve

This is a follow up on https://gitlab.com/gitlab-org/gitlab-ce/issues/55902, where we removed support for creating non-RBAC kubernetes clusters on GCP.

A remaining question was if we wanted to also remove support for adding them to GitLab at all.

Intended users

Operators, developers

Further details

Even if we don't want non-RBAC clusters created by GitLab, is there a compelling reason for us to not support adding them?

  • 26 users answered the question regarding their access control model. 92.31% are using RBAC. Only 2 users reported that they were using ABAC.
  • 28% of clusters on GitLab.com are ABAC
  • 13% of clusters created in the last 6 months are ABAC
  • 9% of clusters created in the last 1 month are ABAC

Because the number of ABAC created clusters are declining and the number is small, we will remove support.

Proposal

On adding a cluster, remove the RBAC-enabled cluster option, so that all added clusters are implicitly assumed to be RBAC-enabled.

Permissions and Security

Documentation

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

Links / references

  • ABAC kubernetes docs, where it says

    The ABAC Authorization feature has been considered deprecated from the Kubernetes 1.6 release.

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited Feb 07, 2024 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading