Not as a general purpose role for developers. The Kubernetes docs 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 service account there. Grant narrower roles, and treat edit like a path to every account in the namespace.
Why edit is more than it looks
The name suggests edit means change your own app. The RBAC docs say otherwise. Because edit can read Secrets and create pods that run as any service account in the namespace, the holder can reach whatever those accounts can reach. The docs call out reading Secrets as a form of privilege escalation because it exposes service account credentials.
The view role leaves Secrets out for the same reason.
The comparison
| Role | Secrets | Pods as other accounts | Escalation concern |
|---|---|---|---|
| view | Excluded | No | Lower |
| edit | Accessible | Yes, in the namespace | The docs flag it |
| cluster-admin | Everything | Everything | Maximum |
How to decide
- List what your developers do: deploy, read logs, port forward, debug.
- Build a custom Role with those verbs on those resources. Avoid wildcards, which the docs warn will also cover resources added later.
- Keep Secret access out unless the task needs it, and then name the specific Secrets with resource names where possible.
- Check which service accounts exist in the namespace and what each can do. A powerful account in a shared namespace raises the value of pod creation.
- Review bindings quarterly and remove people who changed teams.
Check what a subject can do
kubectl auth can-i --list --as=jane@example.com -n team-a
That lists the actions the subject can take in the namespace, which is a fast way to see if a role is wider than expected.
Related reading
Pod creation is itself a strong permission. See what can someone do who can create pods in Kubernetes and who can read Kubernetes Secrets.
An example split of duties
A common pattern is three roles. A deploy role for the pipeline account, which can create and update Deployments, Services and ConfigMaps in the namespace. A debug role for developers, which can read pods and logs and run port forwards but cannot read Secrets. And a break glass role that is bound only during an incident, with the grant and the removal both recorded.
Under this model a developer cannot read a database password through the API just because they work on the app. The pipeline holds the powerful verbs, and the pipeline itself is reviewed and logged.
When people push back
Teams sometimes say edit is needed to debug. Usually what they need is logs, exec into a pod, or a copy of the config. Grant those specific verbs on those resources. If exec is needed in production, log it. Exec into a pod can read the pod's mounted service account token, so it is a strong permission too.
Quick check
Should developers get edit in production?
Rarely. Production access is better limited to deployment tooling plus a break glass path with logging.
Does RBAC stop someone granting themselves more?
The docs say the API prevents escalation by editing roles or bindings unless the user holds the permissions or has escalate or bind rights.
Safeguard policies, gates and compliance evidence automation can help record who has access and review it on a schedule.
Sources
Last reviewed: 19 October 2026.
