Investigate permissions needed for using Custom Resources and Custom Controllers
What we know
-
In order to create a CustomResourceDefinition, the user needs the ClusterAdmin role.
-
There are users out there who will want to deploy GitLab who do not have this level of access
-
In the past, this level of permission would not have been granted to users of
OpenShift Dedicated
What we suspect
- That the community is moving to using Custom Resources and Controllers in Native Kubernetes applications. And wrapping them in Helm Charts. We see examples of this with prometheus and certmanager. So these permission problems won't be exclusive to us.
What we need to investigate
-
Does only the creation of the CRD need these elevated permissions? Or are any custom
controllers
dealing with the kubeserver api have these issues. -
Is there any sort of workaround we can provide for users in restrictive environments? (Similar to how using a local tiller might be a workaround currently for users who can't deploy tiller to the cluster)
-
How are services like OpenShift Dedicated dealing with this new trend of Kubernetes Native apps?
-
What percentages of Kubernetes usage do we expect to have permission restrictions in place?
What is the potential impact
The outcome of this research may impact how much we use Custom Resources and controllers. Based on the results, we can determine whether we restrict to only using Operators in an optional fashion, that can enhance the experience but can be turned off/replaced.