Kubernetes Permission Rule Management

Kubernetes Permission Rule Management is the discipline of authoring the individual rule entries inside Role and ClusterRole objects — the specific combinations of API groups, resources, subresources, resource names, verbs, and non-resource URLs that together define exactly what an authorized subject may do. While role and binding management concern the containing objects, rule management is concerned with getting the fine-grained content of those objects precise, since an imprecise rule is the most common source of both excessive privilege and unexpected authorization failures.

The Anatomy of a Rule

Required Fields

Every RBAC rule specifies apiGroups (empty string "" for the core API group, or a named group like apps or batch), resources (the plural resource name, such as pods or deployments), and verbs (the actions permitted). A rule with no matching resource or verb the caller is attempting grants nothing for that call, regardless of how permissive other rules in the same role appear.

rules:
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "update"]

Optional Scoping Fields

resourceNames restricts a rule to specific named instances (valid only for get, update, patch, and delete), and nonResourceURLs grants access to non-resource API paths such as /healthz, usable only in ClusterRole objects and never combined with resources in the same rule.

Verb Semantics

Read Verbs

get retrieves a single named object; list enumerates a collection; watch streams changes to a collection over time. A controller that reconciles state typically needs all three together — list to establish an initial view and watch to stay current, get for on-demand lookups of individual objects.

Write Verbs

create, update, patch, and delete each correspond to a distinct HTTP semantic, and Kubernetes does not treat them interchangeably: granting update without patch blocks clients that use strategic merge patches (the default behavior of many controllers and kubectl apply), which is a common source of "permission denied" errors that appear despite a seemingly adequate rule.

deletecollection

deletecollection permits bulk deletion of every object matching a list query in a single call, a materially more dangerous action than delete, which only removes objects named individually — a rule granting delete does not implicitly grant deletecollection, and the two should be evaluated separately during review.

Subresource Rules

Distinct From Parent Resources

Subresources such as pods/log, pods/exec, pods/portforward, deployments/scale, and deployments/status each require their own explicit rule entry; a rule granting full access to pods does not grant the ability to exec into a pod's container or stream its logs.

rules:
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]

Security Implications of Subresource Grants

pods/exec and pods/attach are functionally equivalent to arbitrary code execution inside a running container, making them among the most sensitive individual grants in the entire RBAC surface — far more sensitive than the base pods resource they are attached to, and worth reviewing independently during any access audit.

Writing Precise, Auditable Rules

Avoiding Wildcards

resources: ["*"], verbs: ["*"], and apiGroups: ["*"] each collapse a rule's intended scope; a role containing even one wildcard rule is effectively unbounded in that dimension and should be treated with the same scrutiny as cluster-admin during review, regardless of how narrow its other rules appear.

Splitting Rules by Sensitivity

Grouping low-sensitivity read verbs (get, list, watch) in one rule and higher-sensitivity write verbs in another, even for the same resource, makes it easier to review, and easier to grant read-only variants of a role by simply omitting the write rule.

rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]

Validating Rule Correctness

Testing Against Real Calls

kubectl auth can-i <verb> <resource> --subresource=<subresource> --as <subject> verifies a specific rule's effect precisely, including subresource and resource-name scoping, and should be used to confirm a rule change before it reaches production rather than inferred from reading the YAML alone.

Watching for Rule Redundancy

Overlapping rules across multiple roles bound to the same subject are additive — RBAC has no deny rules, so any rule anywhere granting a permission makes it available, meaning removing a permission requires removing every rule that grants it, not just the one that was most recently added.