Support deployment without cluster admin permissions

[jsenko]

In some cases, users may want to deploy the operator in a single namespace and without cluster-wide permissions. Explore how the operator can support this.

[antonmry]

This feature would be very useful for big orgs with different teams, for example if you have one team managing kubernetes and another one managing Apicurio. It would allow the second one to be independent and make changes quicker.

It could also help with engineers doing development or PoC of the product. They typically don't have cluster-wide permissions but a namespace to do this type of work.

Based in the article With Kubernetes Operators comes great responsibility, it seems also a more secure operator.

It would be interesting to know what global resources this operator needs to create and it could be avoided or separated in a previous step so the rest of the installation is independent of the specific actions with cluster-wide permissions.

[antonmry]

After a brief review, we only found one thing which requires cluster-wide privileges:

https://github.com/Apicurio/apicurio-registry-operator/blob/be91f2b38134f1d44ad90e70fbf9f1ad550fbe5e/pkg/controller/apicurioregistry/clients.go#L94-L118

So it's checking the openshift version (object clusterversions from the Api Group config.openshift.io) , we guess to assure compatibility between the operator and openshift. If it isn't Openshift, then just ignore the validation:

if api_errors.IsNotFound(err) {
			// default to OpenShift 3 as ClusterVersion API was introduced in OpenShift 4
			ocpSemVer, _ = semver.NewVersion("3")
		} else {
			log.Error(err, "Failed to get OCP cluster version")
			return nil
		}

We understand if the user doesn't have privileges, it fails because it's a different error, right?

In any case, allow bypass this validation or provide the Openshift version as argument to the operator would solve the issue. Does it make sense?

[jsenko]

Hi, thank you for the feedback and review. I think this would be a good solution, I'll prepare a PR for the next release.

[famarting]

@jsenko note the cluster_role and cluster_role_binding included in the yaml's we release, we'll need to remove those to address this as well. Btw, here an example of how to detect the openshift cluster without requiring admin permissions https://github.com/EnMasseProject/enmasse/blob/master/pkg/util/openshift.go