Discussion: Operator scoping
During the RedHat sync call, @ochienged brought up the issue of scoping of the GitLab operator. This question has two specific dimensions to it (single/multiple GitLab installations and namespace/cluster scope) which have direct consequences on the Operator Lifecycle Manager (OLM) and how security is handled. This decision applies to the GitLab Runner operator and the GitLab application operator. , or a combined operator regardless of the decision made in #30 (closed).
Single/multiple GitLab installations
Part of this issue deals with the expected behavior of the operator with regards to the number installations of GitLab (Runner or application) within the cluster.
If the expectation is that only a single instance of GitLab will be managed by the operator, then the operator has a simpler reconciliation loop. Whereas if multiple instances of GitLab will be managed, the reconciliation loop will be required to track and maintain state of each of the installations. Multiple instances may include multiple versions of GitLab, but the versions should not be older than the three supported versions as of the release of the operator (see #5 (closed)).
The behavior of managing multiple installations may and probably will complicate the CRD that needs to be specified. One option for handling this and reducing the complexity of the CRD is to limit the installation of GitLab to one installation per namespace.
Namespace scoping or cluster scoping
Directly related to the single/multiple instance question is if the operator should be scoped to a specific namespace(s) or not. With Namespace scoping, the operator would only be allowed to manage one or more specific Namespaces. Each Namespace will need an RBAC Role installed to allow the operator's ServiceAccount to manage objects within the Namespace.
For cluster scoping, an RBAC ClusterRole needs to be created for the operator's ServiceAccount. As a result the operator will have the ability to manipulate any Namespace which is a significant security concern. The operator's ServiceAccount would effectively be a cluster admin.