LEARN. PRACTICE. GROW.Concept and mechanism
Describe an operational need through identity, verb, resource, subresource, and scope. A RoleBinding can reuse a ClusterRole within a namespace; a ClusterRoleBinding has different reach. The binding name does not restrict access. To scale without editing the whole Deployment, assess deployments/scale and the verbs actually used by the client. For logs, pods/log is a distinct subresource. The access matrix should reflect actual APS work, including incident diagnosis, and should be demonstrated with the operational identity. A test performed only by an administrator does not prove the receiving team will have autonomy.
Guided application
Risk does not end with read verbs. Creating Pods can permit mounting data and using existing ServiceAccounts when no other controls apply. Also review bind, escalate, and policy-changing capability. For workloads not using the API, avoid automatically mounted tokens. When a projected token rotates, the client must consume its new value instead of retaining the startup read. In a supplier integration, separate what the pipeline may publish from what it may delegate to other identities. A security upgrade must cover affected control-plane and node components; updating only kubectl does not patch remote software. Follow distribution guidance, compatibility, and recovery validation. Record positive and negative tests, access-review owners, and the revocation process when a contract ends or a role changes.
A pipeline lacking get secrets can still create a Pod mounting a Secret. Analyze the indirect path before classifying risk.
Common pitfalls
Only direct verbs; names treated as scope; fixed tokens in images; testing only with cluster-admin.
Related topics: Linux hardening and kernel controls · Admission and workload protection
Grant the needed operation and assess the powers it enables indirectly.
Reference: RBAC authorization · Kubernetes v1.35; current six-domain CKS outline