manager.rbac.strict is a no-op; the cluster-admin binding is gated by the undocumented manager.rbac.minimal

[dva08]

Bug description

The Capsule Helm chart v0.13.7 exposes manager.rbac.strict: true as a configuration option intended to run the controller without cluster-admin privileges. However, enabling this flag does not remove the cluster-admin ClusterRoleBinding from the controller's ServiceAccount — it only adds an aggregate ClusterRole. The controller continues to operate with cluster-admin permissions regardless of the flag value.

Reproduction steps

1. Install Capsule via the Helm chart with manager.rbac.strict: true (chart version 0.13.7, controller image v0.13.7)
2. Check the ClusterRoleBinding for the capsule controller:

kubectl get clusterrolebinding | grep capsule-manager
# capsule-manager-rolebinding   ClusterRole/cluster-admin   ...
3. The binding is still present and references ClusterRole/cluster-admin — strict mode has no effect on it.
Expected behavior
When manager.rbac.strict: true is set, the Helm chart should either:
- Remove the cluster-admin ClusterRoleBinding entirely, OR
- Replace it with a scoped ClusterRole that grants only the permissions Capsule actually needs
Actual behavior
The capsule-manager-rolebinding ClusterRoleBinding persists and still references ClusterRole/cluster-admin, regardless of the manager.rbac.strict flag value.
Evidence
ClusterRoleBinding (confirmed on live cluster):
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: capsule-manager-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: capsule
  namespace: capsule-system
Helm chart values.yaml (capsule-0.13.7):
rbac:
  strict: false  # <-- When set to true, expected to remove cluster-admin binding
Controller image: ghcr.io/projectcapsule/capsule:v0.13.7
All Capsule ClusterRoleBindings:
capsule-manager-rolebinding                                     ClusterRole/cluster-admin
capsule-namespace-provisioner                                   ClusterRole/capsule-namespace-provisioner
capsule-pre-delete                                              ClusterRole/capsule-pre-delete
capsule:capsule:aggregate                                       ClusterRole/capsule:capsule:aggregate
capsule:capsule:crds                                            ClusterRole/capsule:capsule:crds

Impact
The Capsule controller runs with full cluster-admin privileges, which violates the principle of least privilege. This is a security concern for production multi-tenant clusters where defense-in-depth is important.

Environment

• Helm chart version: capsule-0.13.7
• Capsule controller image: ghcr.io/projectcapsule/capsule:v0.13.7
• Kubernetes version: v1.34.5
• CNI: Cilium v1.19.4
• CapsuleConfiguration: default (active, reconciled)

Additional context
The manager.rbac.strict flag appears to only add an aggregate ClusterRole but does not modify or remove the existing cluster-admin binding. This may be a bug in the Helm chart template or in the Capsule controller's RBAC initialization logic.

Labels: bug, rbac, helm-chart

[dva08]

Correction to my own report after digging into the chart templates — the root cause is
different from what I described, and I think this unblocks validation.

manager.rbac.strict is a no-op. It is not referenced by any template in v0.13.7.
helm template produces byte-identical output with and without it:

helm template capsule projectcapsule/capsule --version 0.13.7 -n capsule-system > a.yaml
helm template capsule projectcapsule/capsule --version 0.13.7 -n capsule-system \
  --set manager.rbac.strict=true > b.yaml
diff a.yaml b.yaml   # empty; both 558266 bytes

$ grep -rn 'rbac.strict\|rbac.minimal' capsule/
capsule/README.md:155:| manager.rbac.strict | bool | `false` | Strongly restrict ... |
capsule/templates/rbac.yaml:109:    {{- if $.Values.manager.rbac.minimal }}

So capsule:capsule:aggregate is rendered unconditionally, not "added by strict mode" as
I originally wrote.

The working flag is manager.rbac.minimal, which is undocumented. It is the actual
gate in templates/rbac.yaml:

line 109  {{- if $.Values.manager.rbac.minimal }}   -> capsule:capsule:controller (scoped)
line 483  {{- else }}                               -> capsule-manager-rolebinding -> cluster-admin

minimal appears in neither values.yaml nor README.md. Setting manager.rbac.minimal: true
does resolve the original problem — verified on our cluster: the cluster-admin binding is gone,
tenant reconciliation, tenant-owner namespace creation and GlobalTenantResource propagation all
still work, with zero forbidden entries in the controller log.

Suggested fix: either wire strict into the templates, or document minimal in values.yaml
and deprecate/remove strict. Right now one flag is documented but dead and the other is
functional but invisible.

Related, possibly worth a separate issue: even with minimal: true, capsule:capsule:controller
retains

- apiGroups: ["*"], resources: ["*"], verbs: ["delete", "deletecollection"]
- apiGroups: ["*"], resources: ["*"], verbs: ["get", "list", "watch"]

i.e. cluster-wide read of every Secret and delete on any object. That is a much weaker guarantee
than "minimal" suggests.

One more note on the aggregation step. The docs recommend
kubectl label clusterrole admin projectcapsule.dev/aggregate-to-controller=true. The underlying
reason is RBAC escalation prevention: the controller must hold admin's permissions to create the
tenant-owner RoleBindings that reference it. The bind verb is a much narrower alternative and
works — we replaced the admin label with:

- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  resourceNames: ["admin", "capsule-namespace-deleter", "capsule-namespace-provisioner"]
  verbs: ["bind"]
- apiGroups: ["networking.k8s.io"]
  resources: ["networkpolicies"]
  verbs: ["get","list","watch","create","update","patch","delete","deletecollection"]

(the second rule is needed because capsule:capsule:controller grants every verb on
networkpolicies except create, which GlobalTenantResource propagation requires).
Tenant-owner RoleBindings to admin are still created correctly. Might be worth considering
as the documented default.