Authorization: KCSA practice questions

After the API server has authenticated a request, an authorizer decides whether that identity may perform the requested verb on the requested resource. Kubernetes supports several authorization modes, including Node, RBAC, ABAC and Webhook, plus AlwaysAllow and AlwaysDeny, which are meant only for testing. AlwaysAllow is dangerous on any reachable cluster, and because RBAC has no deny rules, a configuration such as AlwaysAllow,RBAC behaves exactly like AlwaysAllow.

Role-based access control is the mode most clusters rely on. A Role or ClusterRole holds rules, each a combination of API groups, resources and verbs such as get, list, watch, create, update and delete. Permissions are purely additive; there is nothing to subtract. A Role always belongs to one namespace, while a ClusterRole is not namespaced and can describe cluster-scoped resources, non-resource endpoints, or namespaced permissions meant for reuse across namespaces. The kubectl helper for a namespaced read-only role looks like kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods.

Bindings attach roles to subjects, which are users, groups or ServiceAccounts. A RoleBinding grants permissions inside its own namespace and can reference either a Role in that namespace or a ClusterRole; in the second case the ClusterRole's rules apply only within the binding's namespace. A ClusterRoleBinding grants access across the whole cluster. This distinction matters for the cluster-admin ClusterRole: bound with a ClusterRoleBinding it gives full control of every resource in every namespace, while bound with a RoleBinding it gives full control of everything in that one namespace, including the namespace itself. Binding a role to the group system:authenticated hands it to every authenticated user, and the documentation warns that binding cluster-admin to all service accounts lets any container act as a cluster administrator. A binding's roleRef cannot be changed after creation; to switch roles you delete and recreate the binding.

RBAC also prevents privilege escalation through its own API. You can create or update a role only if you already hold every permission it contains, at the same scope, or if you have the escalate verb on roles or clusterroles. Similarly, creating a binding requires holding the referenced permissions or the bind verb. Wildcards in resources or verbs are risky because they automatically include resource types and subresources added later.

To check effective permissions, kubectl auth can-i asks the authorizer directly, and administrators can combine it with --as to test another user or a ServiceAccount such as system:serviceaccount:dev:dev-sa. Authorization limits what an identity may do, not how much it may consume; per-namespace consumption limits come from a ResourceQuota, which caps aggregate resource usage and object counts in a namespace.