The Google GKE Marketplace verify script that gates publication checks the Application CRD and fails if it finds unsupported RBAC entries.
We do not produce any such entries for deployment in the Marketplace, however, our Application CRD contains an entry for ClusterRoles and ClusterRoleBindings because the chart may be configured to support them.
We need to add a logic gate around these so they can be turned off which will allow us to satisfy the requirement for Google Marketplace.
I also found references to ClusterRole in the following files that I will need to address to prevent the case where someone disables ClusterRole in the ApplicationCRD and yet still creates ClusterRoles.
Ill defer to @twk3 and @pursultani for need of a cluster role beyond creating the CRD.
nginx-ingress controls ClusterRole based on the previously mentioned scoping setting. I'd be surprised if the runner actually needed ClusterRole, and we can take that up with that chart. kubemonkey never gets deployed to production.
If creating the CRD (eg: the operator) requires a ClusterRole, then by definition that precludes GKE Marketplace customers from ever having access to the Operator.
For efficiency, as the discussion of whether to turn this off in the runner can probably get moved to a separate issue, I have documented how to turn off the ClusterRole in the gitlab-runner chart in !702 (merged).
Currently our operator is using a clusterrole, but we should be able to migrate it to a namespace role I believe. As everything we have it manage is namespaced.
Creating the CRD definitely needs a clusterrole, and it tends to need significant permissions, typically clusteradmin level. This is something I expect we will have to reach out to Google for guidance in, as I'm certain they will want to support CRDs/operators, but we will likely need to provide them in the schema rather than in the helm chart.
For the current release, the operator is off by default.
This is something I expect we will have to reach out to Google for guidance in, as I'm certain they will want to support CRDs/operators, but we will likely need to provide them in the schema rather than in the helm chart.
This. There are a number of other GKE Marketplace apps that use the operator pattern, and the current solution is to ask users for the name of a Service Account with ClusterAdmin rights, I believe.
When we discussed this last they were looking at improving that installation method as well, but that was the current iteration. Let's disable the operator for now, since it's beta anyway, and we can circle back up with Google on how to best proceed once we get this version published.
@rmarshall this is very hard to measure since we don't use the helm chart ourselves to deploy the runner fleet, and I have never seen how people are using the helm chart in production so I can not tell if it's being used or not. That being said, I do see the need for this, since gitlab-runner can run in a different namespace then the job itself, but specifing the namespace configuration keyword. Also users are able to override this namespace per job, so the runner needs to have a ClusterRole for users doing deployments/jobs possibly on a different namespace that the runenr bastion is runnign in.
@steveazz that does clarify, and in !702 (merged) I documented what would need to happen in environments where ClusterRoles are not available for usage. The runner chart already had enough support to accomplish what was necessary without any changes other than documentation.