Decide if we want to remove support for _adding_ non-RBAC clusters
Problem to solve
This is a follow up on #55902 (closed), 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.
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.
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
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.