Not by default. An operator needs only the permissions required to manage its own resources, and reading its ClusterRole before install shows how much more it asks for. Wildcard rules, escalate, bind and Secret access are the entries to challenge.
Why operators ask for a lot
An operator is a controller that creates and changes objects for you, so it needs write access to something. Many chart authors take a shortcut and bind the cluster-admin role or write a ClusterRole full of asterisks. That works on day one and quietly grants access to every resource, including ones added later.
The Kubernetes RBAC docs warn about this directly. Wildcards in resource and verb entries can grant access to sensitive resources, and when a new resource type or subresource appears, the wildcard automatically covers it. The docs recommend least privilege with specific resources and verbs.
What to look for in a ClusterRole
| Entry | Why it deserves a question |
|---|---|
| resources or verbs set to a wildcard | Covers things added later without review |
| escalate on roles or clusterroles | Lets the holder write roles with permissions they lack |
| bind on clusterroles | Lets the holder grant roles they do not hold |
| get or list on secrets, cluster wide | Reads service account tokens and credentials |
| create on pods | Can run pods as service accounts in the namespace |
| a binding to cluster-admin | Everything, everywhere |
The docs explain the escalate and bind verbs: without them you can only grant permissions you already hold. The docs also note that the edit role allows accessing Secrets and running pods as any service account in the namespace, so it can be used to gain the access of any of those accounts. Reading Secrets is a form of privilege escalation, not a read only convenience.
How to review before you install
- Render the chart or bundle and extract every Role, ClusterRole and their bindings.
- For each rule, ask which feature of the operator needs it. If nobody can answer, it is a candidate to remove.
- Prefer namespaced Roles over ClusterRoles when the operator watches one namespace.
- Check whether the operator needs to create other roles. If it does, it needs bind or escalate, which is a bigger decision than it looks.
- Record the decision, so the next upgrade can be diffed against it.
You can test a proposed account with kubectl auth can-i and an impersonated service account, for example kubectl auth can-i list secrets --all-namespaces --as=system:serviceaccount:NAMESPACE:NAME.
Upgrades change the answer
A new operator version can add rules. Compare the rendered RBAC for each release, the same way you compare CRDs. The full operator checklist is in Kubernetes operator security checklist.
Quick check
Is cluster-admin ever acceptable for an operator?
It is rarely needed. If a vendor insists, ask for the specific resources and verbs and treat a refusal as a risk finding.
Does a namespaced Role limit the damage?
It limits the scope to one namespace, but remember that pod creation and Secret access inside it can still reach other service accounts there.
Safeguard scans dependencies and SBOMs for the software you deploy, and a free scan is available at https://gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
