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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
