Privilege Escalation: KCSA practice questions

Privilege escalation is any path by which a user, workload or node ends up with more access than it was granted. In Kubernetes the paths fall into two families: API permissions that are more powerful than they look, and Pod settings that hand a container control of its node. The RBAC good-practices guide catalogs the first family, and the Pod Security Standards constrain the second.

On the API side, RBAC normally stops a user from creating a role with more rights than they hold, or from binding a role whose rights they lack. The escalate verb on roles and the bind verb on bindings are the documented exceptions, and impersonate lets a user take on the rights of another identity. Members of the system:masters group bypass every RBAC check and keep unrestricted superuser access that removing bindings cannot revoke, so the guide says not to add users to it. Several ordinary-looking grants are escalation routes too. get on nodes/proxy reaches the kubelet API, which can execute commands in every Pod on the node and bypasses audit logging and admission control. Creating arbitrary PersistentVolumes includes hostPath volumes, which give a Pod the node's filesystem. Create rights on CertificateSigningRequests plus approval for the kubernetes.io/kube-apiserver-client signer can mint client certificates with any name, including those of system components. create on serviceaccounts/token issues tokens for existing service accounts, control of webhook configurations exposes every admitted object and can alter it, and patching a Namespace can relabel it for a more permissive Pod Security level.

Workload creation deserves separate attention. Permission to create Pods, or any workload resource that manages Pods, implicitly grants access to the namespace's Secrets, ConfigMaps and PersistentVolumes and to the API rights of every ServiceAccount there, and users who can run privileged Pods can use that access to reach the node.

On the Pod side, the dangerous settings are those that remove isolation. A privileged container disables most security mechanisms, and the Baseline standard also disallows sharing host namespaces, forbids hostPath volumes and disallows adding capabilities beyond a default list. allowPrivilegeEscalation controls whether a process can gain more privileges than its parent, for example through a setuid binary, by setting the no_new_privs flag; it defaults to true when unset and cannot be false for a privileged container or one with CAP_SYS_ADMIN. Baseline is defined as preventing known privilege escalations, and Restricted adds hardening on top: allowPrivilegeEscalation must be false, containers must drop ALL capabilities and may add back only NET_BIND_SERVICE, and they must run as non-root users. The guide recommends enforcing Baseline or Restricted wherever users are not fully trusted to create isolated Pods, with Pod Security admission or a third-party mechanism.

Nodes are a third angle. A stolen kubelet credential should not reach beyond its own node, which is what the Node authorizer and the NodeRestriction admission plugin provide: such a kubelet may modify only its own Node object and the Pods bound to that node.