Separate Operator per each Controller? Let's talk.

[dee-kryvenko]

I just ran into this comment #250 (comment) from @tomaszsek, that basically makes a recommendation to have separate operator per each controller. This really sounds like an anti-pattern and this is not what other operators like Prometheus Operator or Redis Operator do or recommend. Not to mention that each operator registers itself as an admission controller...

In a typical CI/CD implementation in a shared K8s environment, most typical roles would include:

1. Cluster admins
2. Operator admins
3. Controller admins
4. Job admins
5. Developers

Obviously, not necessarily that these five are all different people physically - some of these roles might be shared by same teams, and some - be a self-service automation. However, with the current implementation - separation of privileges, wether it is in between people or automation, looks broken to me.

1. Operator admins should not be able to deploy CRDs and register admission controllers.
2. Job admins should not be able to configure build pods to use controller SA, as job admins should not necessarily be able to read controller secrets and should not be able to tamper with controller pod.

With that said - to me the most optimal, the most secure, and the most flexible topology would be to have one shared operator in the cluster, each controller in its own separate namespace, which in turn each use one more namespace designated to just build pods.

Although I can see some might want to have more than one operator to watch groups of namespaces instead of a single ns per operator as it is now - but that'd require admission controller to be separated as operator admins would typically not have permissions to deploy it. Not to mention multiple instances of the same admission controller registered as a separate webhooks each sounds like too much overhead for the control plane and can potentially lead to performance degradation in the cluster.

[prryb]

Hi! Thank you for your message. I do see your point.

When that comment was made, there were no admission controllers. That has changed since that time, that's true. There were some efforts made so that you don't need to have cluster admin permissions to run the operator in a namespace.

It was easier development-wise, to focus on watching one namespace, one Jenkins, etc and there were no strong enough arguments to try to change that.

Now, I think, might be a good time to reconsider that. I'd say making that change (so that one operator supports multiple Jenkins instances) is doable.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this issue is still affecting you, just comment with any updates and we'll keep it open. Thank you for your contributions.

[TueDissingWork]

This is still very relevant - any reason this issue have been closed, other than no activity?

[brokenpip3]

I added the right label but I forgot to re-open it