A ServiceAccount provides an identity for processes running in a Pod, used to authenticate to the API server and to be authorized by RBAC. Every namespace has a default ServiceAccount, and Pods that do not specify one are automatically assigned it. Role-Based Access Control (RBAC) is the standard authorization mode, using Roles and ClusterRoles to define permission sets, and RoleBindings and ClusterRoleBindings to grant those permissions to subjects (users, groups, or ServiceAccounts). A Role grants access within a single namespace, while a ClusterRole grants cluster-wide access or access to non-namespaced resources and can be reused across namespaces via a RoleBinding.
Pod-level security is configured through the PodSecurityContext, which sets security-relevant fields such as runAsUser, runAsGroup, fsGroup, seccompProfile, runAsNonRoot, and supplemental groups. Historically, PodSecurityPolicy (PSP) enforced similar controls, but PSP was deprecated in Kubernetes 1.21 and removed in 1.25. It has been replaced by Pod Security Admission (PSA), a built-in admission controller that enforces Pod Security Standards at three levels: privileged, baseline, and restricted, configured per namespace via labels.
Admission control can also be extended. A ValidatingAdmissionPolicy uses CEL-based rules to validate incoming API requests declaratively (beta in 1.30), and a MutatingAdmissionWebhook intercepts requests before persistence to mutate objects, used by service meshes, sidecar injectors (such as Istio), and secret backends. The API server's default authentication chain processes X509 client certificates, bearer tokens (including ServiceAccount tokens), OpenID Connect tokens, bootstrap tokens, and anonymous auth (when enabled). A bootstrap token is a short-lived token (24 hours or longer) used to authenticate new nodes joining the cluster, typically during kubeadm join.