hivemq
Run hivemq-platform-operator namespaced
Running a Kubernetes (K8s) operator in a namespaced mode means that the operator's scope is restricted to a specific namespace rather than being cluster-wide.
Most Kubernetes operators support this use-case. Would be great if Hivemq-platform-operator can support running in namespaced mode.
Advantages:
- Security & Isolation: Limits the operator's impact to a specific namespace, reducing security risks.
- Multi-tenancy: Each team can have its own operator in separate namespaces without interfering with others.
- Version Control: Teams can run different operator versions in different namespaces for testing or staging.
Hi Albert, thanks for reporting this.
We already have plans to improve this part of the configuration. The operator is using the Quarkus Operator SDK that supports namespaced operations. This is not exposed in our Helm charts yet, but you can configure it by setting a custom environment variable in the HiveMQ Platform Operator Helm chart:
env:
- name: QUARKUS_OPERATOR_SDK_NAMESPACES
value: my-namespace
But this won't solve all advantages you have mentioned.
Regarding Security & Isolation, the operator will still have cluster wide permissions, so it could still access K8s resources in all namespaces. In our planned feature we want to try to configure RBAC permissions per configured namespace (for all resources where this is possible).
Regarding multi-tenancy and version control, this can already be achieved by configuring selectors. Each operator would still monitor all namespaces, but only reconcile the matching custom resources.
It's also no problem to run different versions of the HiveMQ Platform Operator in your K8s cluster. We have a custom version field in our CRD, so the operators will update the CRD to the newest version of all running operators.
So beside the reduced RBAC permissions you should already be able to use either the namespace or selector based approach for multi-tenancy and multiple operator versions.
Thank you for your quick reply and background information.
It should not be that difficult to create role bindings instead of cluster role bindings when the operator is started in namespaced mode (e.g. using QUARKUS_OPERATOR_SDK_NAMESPACES).
It would require a loop in the template for all configured namespaces, but also a bit of research and thorough testing which K8s permissions work with a RoleBinding and which require a ClusterRoleBinding. As I said, it's already planned to implement this in one of the next releases.
We just released a new HiveMQ Platform Operator Helm chart that exposes the namespaces and selectors configuration: https://docs.hivemq.com/hivemq-platform-operator/configuration.html#platform-selector-options
See also https://www.hivemq.com/changelog/hivemq-platform-operator-1-6-1-release/
We still need to implement the optimized RBAC permissions if namespaces are configured.
RBAC permissions are now also optimized to minimize the scope and use of ClusterRoles and ClusterRoleBindings in the new Helm charts release. See https://www.hivemq.com/changelog/hivemq-platform-operator-1-7-0-release/ Closing the issue as complete
