Problem
The ClusterRole shipped by the chart does not carry any RBAC aggregation labels. This means that users or service accounts bound to the standard Kubernetes admin or edit ClusterRoles cannot manage the operator's CRDs (PulsarTenant, PulsarNamespace, PulsarTopic, ...) out of the box.
Every consumer has to either:
- create additional RoleBindings / ClusterRoleBindings referencing pulsar-resources-operator-manager-cluster-role, or
- post-render / kustomize-patch the chart to inject aggregation labels themselves.
This is a common Kubernetes pattern, most controllers/operators that ship CRDs expose their permissions via ClusterRole aggregation (https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles) so that platform admins don't have to maintain a parallel RBAC tree per operator.
Proposed change
Add the standard aggregation labels to the manager ClusterRole:
metadata:
labels:
rbac.authorization.k8s.io/aggregate-to-admin: "true"
rbac.authorization.k8s.io/aggregate-to-edit: "true"
A read-only companion ClusterRole (get/list/watch on the CRDs) labelled with rbac.authorization.k8s.io/aggregate-to-view: "true" would also be a natural addition, but is optional.
Ideally the labels should be togglable via values.yaml, e.g.:
rbac:
aggregateToAdmin: true
aggregateToEdit: true
aggregateToView: true
with sensible defaults (all true, or admin/edit true and view false).
Willing to contribute
I'm happy to open a PR implementing a minimal version of this, will link it here. Let me know about the other proposed features
Problem
The ClusterRole shipped by the chart does not carry any RBAC aggregation labels. This means that users or service accounts bound to the standard Kubernetes admin or edit ClusterRoles cannot manage the operator's CRDs (PulsarTenant, PulsarNamespace, PulsarTopic, ...) out of the box.
Every consumer has to either:
This is a common Kubernetes pattern, most controllers/operators that ship CRDs expose their permissions via ClusterRole aggregation (https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles) so that platform admins don't have to maintain a parallel RBAC tree per operator.
Proposed change
Add the standard aggregation labels to the manager ClusterRole:
A read-only companion ClusterRole (get/list/watch on the CRDs) labelled with rbac.authorization.k8s.io/aggregate-to-view: "true" would also be a natural addition, but is optional.
Ideally the labels should be togglable via values.yaml, e.g.:
with sensible defaults (all true, or admin/edit true and view false).
Willing to contribute
I'm happy to open a PR implementing a minimal version of this, will link it here. Let me know about the other proposed features