Setup without, or with limited, cluster resources

[jbnjohnathan]

Is there a current way, or a plan to introduce, an out of the box option to make the operator use no, or very limited, cluster resources?

Example from the Elastic operator: https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-install-helm.html#k8s-install-helm-restricted

Restricted installation
This mode avoids installing any cluster-scoped resources and 
restricts the operator to manage only a set of pre-defined namespaces.

Since CRDs are global resources, they still need to be installed by an administrator. 
This can be achieved by:
The operator can be installed by any user who has 
full access to the set of namespaces they wish to manage. 

The following example installs the operator to 
elastic-system namespace and configures it to manage 
only namespace-a and namespace-b

The use case is deploying in a cluster where the deployer do not have cluster wide permissions. This would of course mean that the operator would need a list of namespaces to watch as well as it will not be able to create or delete namespaces etc. But for this usecase these limitations are acceptable. As mentioned in the article from Elastic, some resources such as CRDs cannot be avoided being cluster wide.

A good way forward would be to provide rbac manifests for a limited/restricted installation, as well as documentation on what the limitations will be and other steps that are needed.

[jbnjohnathan]

I found a possible limiting factor in the code. In the values.yaml file there is watchNamespace:. But it only takes a single namespace. For a restricted install to work, I would think the operator needs to be able to take a list of namespaces to watch, not just either a single one, or all of them.

[ppaslan]

i was just about to create an issue and found this as the top item so i'll hijack this issue and i hope that's alright.

We are actually in need of this exact same setup, were we can limit the operator to watch certain namespaces and work with role/rolebindings and very limited or no clusterroles/clusterrolebindings

[swoehrl-mw]

Hi @jbnjohnathan. There is currently no way to install the operator in a restricted way (aside from rolling your own helm chart) as the helm chart always installs the ClusterRole(Binding)s. It would mean making the creation of the clusterrole and binding configurable and enable optional namespaced roles and bindings. Installing the CRDs can already be disabled. There are currently no concrete plans to support such a scenario, but if someone wants to contribute that it is something I think we can accept.

Regarding watchNamespace, there is already an existing issue (#374).

it will not be able to create or delete namespaces etc.

That the operator does not do currently anway, all of its operations happen inside a namespace and all its CRDs are namespace-scoped. The cluster-scoped permissions are only there because the current deployment model assumes you deploy the operator once per cluster.

[mrvdcsg]

In larger deployments, the kubernetes cluster is managed by a different team and they scope permissions per namespace. I would argue that needing the cluster-scoped permissions isn't allowed by policy and therefore the option to limit it would greatly improve adoption. This operator is amazing but security teams have a hard "no" for broad scoped things that shouldn't need it. I have an ECK (Elastic Cloud Kubernetes) deployed on AKS that didn't run into any of these issues. This question is nearly a year old, please consider revisiting it and thank you for your efforts.