You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by "squakez (via GitHub)" <gi...@apache.org> on 2026/05/09 08:18:14 UTC
[I] Operator tenancy model [camel-k]
squakez opened a new issue, #6616:
URL: https://github.com/apache/camel-k/issues/6616
### Requirement
In recent releases we have deprecated the "multiple operators" feature [1]. The main reason is that the model provided was opening security constraints, where any user can escalate privileges by picking an operator for which they may have not enough privileges.
Right now we officially supports:
* Global (descoped) operator: an operator that reconciles all resources at cluster level
* Namespaced operator: an operator that reconciles only resources in a given namespace
We miss the possibility to run a "Multi namespace operator", which is a way to let the user provide a sharding model when the number of namespaces scales. The goal is that with this model, it is the operator that has to pick up a selected (configurable by operator admin) number of namespaces.
The only potential challlenge is the need to provide namespaced RBAC for each namespace.
[1] https://camel.apache.org/camel-k/next/installation/advanced/multi.html
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Operator tenancy model [camel-k]
Posted by "bart-rijnders (via GitHub)" <gi...@apache.org>.
bart-rijnders commented on issue #6616:
URL: https://github.com/apache/camel-k/issues/6616#issuecomment-4428881185
> Could we make this configurable through labels? Labels and label selectors are the standard Kubernetes mechanism for grouping, selecting, and dynamically discovering resources. Instead of maintaining a static list of namespaces in the operator configuration, the operator could be configured with a namespace label selector.
I second this, it would give the highest level of flexibility for teams managing an operator _without_ being cluster administrators. For inspiration, the [Grafana operator uses this as well](https://github.com/grafana/grafana-operator/blob/09826455e8e74f46af6a72861196f6cd848dcb1f/deploy/helm/grafana-operator/values.yaml#L22). Here is a link to the [code generating the config](https://github.com/grafana/grafana-operator/blob/09826455e8e74f46af6a72861196f6cd848dcb1f/main.go#L477)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Operator tenancy model [camel-k]
Posted by "timmy-mathew-ah (via GitHub)" <gi...@apache.org>.
timmy-mathew-ah commented on issue #6616:
URL: https://github.com/apache/camel-k/issues/6616#issuecomment-4426156196
Hi @squakez, thanks for creating this issue.
A multi-namespace operator mode would be very useful in environments like ours, where we have a large number of namespaces in a multi-tenant Kubernetes cluster.
From a security and governance standpoint, running the Camel K operator in global mode is not allowed in our setup, as it requires cluster-wide permissions. This creates a significant security concern, since the camel-k operator would have access to resources such as Secrets and ConfigMaps across all namespaces for teams that don't need to use camel-k.
At the same time, running one operator per namespace for a large enterprise setup does not scale well operationally.
Could we make this configurable through labels? Labels and label selectors are the standard Kubernetes mechanism for grouping, selecting, and dynamically discovering resources. Instead of maintaining a static list of namespaces in the operator configuration, the operator could be configured with a namespace label selector.
This way, teams could enable a label on their namespaces as an opt-in mechanism for deploying Camel K-based integrations.
With regard to RBAC, one possible operational model could be to use a policy engine such as Kyverno to generate the required namespaced Roles and RoleBindings when a namespace opts in through the label. Another option could be to provide a reusable RBAC template that platform admins can apply per namespace to grant the required permissions to the Camel K operator.
The multi-namespace operator mode could also be introduced in a backward-compatible way, keeping the existing global and single-namespace modes unchanged while adding namespace label selection as an additional opt-in configuration.
For example:
```yaml
camel-k-enabled: "true"
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Operator tenancy model [camel-k]
Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez closed issue #6616: Operator tenancy model
URL: https://github.com/apache/camel-k/issues/6616
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Operator tenancy model [camel-k]
Posted by "timmy-mathew-ah (via GitHub)" <gi...@apache.org>.
timmy-mathew-ah commented on issue #6616:
URL: https://github.com/apache/camel-k/issues/6616#issuecomment-4446433085
@squakez is it feasible to make this compatible with namespace selector labels as suggested above?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Operator tenancy model [camel-k]
Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez commented on issue #6616:
URL: https://github.com/apache/camel-k/issues/6616#issuecomment-4448251768
We need to make a deeper assessment. Feel free to have a look and provide some proposal (any document or a draft PR if you prefer). Right now the identification of the resource is happening via labels. However, the reconciliation has to be bound to selected namespaces, at least, within the operator framework which we are using.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org