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.