LEARN. PRACTICE. GROW.Concept and mechanism
RBAC controls actions on API resources. A Role describes permissions in a namespace; a binding connects rules to subjects. A RoleBinding may reference a ClusterRole and grant relevant permissions only in its namespace. RBAC permissions are additive: adding a narrower Role does not cancel an existing broader grant. For support, identify required subject, verb, resource, subresource, and scope. Reading Pods and reading pods/log are not exactly the same operation. A Forbidden error may indicate valid authentication with insufficient authorization; it does not require granting cluster-admin or replacing credentials before observing the denied action.
Guided application
NetworkPolicy concerns network communication and needs a supporting implementation. API acceptance of an object does not establish that traffic is now filtered. Permissions from applicable policies combine; an additional deny rule does not automatically override existing allowances. For a connection between isolated Pods, consider source egress and destination ingress alongside required DNS and ports. In a fictional exercise, a team allows database access at the destination but misses API egress. Examine both sides and permit the specific flow. RBAC permission to read a Service does not authorize application traffic, and a network policy does not grant API access to Secrets. These are complementary controls requiring different evidence.
An operator reads Pods but receives Forbidden for pods/log: check the subresource and binding before broadening access.
Common pitfalls
Narrow Role as deny; NetworkPolicy object as enforcement; cluster-admin as diagnosis.
Related topics: Workloads and desired state · Traffic and probes · Resources and scheduling
Grant the required operation and flow within the correct scope.
Reference: RBAC roles bindings and subresources · Kubernetes v1.37 concepts; current official documentation consulted 2026-09-30; cluster versions and plugin capabilities must be confirmed