Kubernetes security spans authentication, authorization, admission control, runtime hardening, and network segmentation. Authorization is governed by Role-Based Access Control through four objects: Roles grant permissions within a specific namespace, ClusterRoles grant cluster-wide permissions or apply to non-namespaced resources like nodes and PersistentVolumes, RoleBindings attach a Role (or ClusterRole) to users, groups, or ServiceAccounts within a namespace, and ClusterRoleBindings do the same cluster-wide. Permissions are expressed as verb and resource pairs, with verbs covering get, list, watch, create, update, patch, delete, and deletecollection, and the wildcard * granting everything, which should be avoided in production. ClusterRoles can be bound to a single namespace through a RoleBinding to reuse permission sets across namespaces. kubectl auth can-i answers whether the current user (or an impersonated one via --as and --as-group) can perform a specific action, and is the standard tool for auditing RBAC.
Workload identity comes from ServiceAccounts, which are mounted into Pods at /var/run/secrets/kubernetes.io/serviceaccount/ by default. Every namespace has a default ServiceAccount, but the recommendation is to create a dedicated ServiceAccount per workload and to set automountServiceAccountToken: false unless the Pod actually calls the apiserver. Pod-level hardening is achieved through the SecurityContext, which controls runAsUser, runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation, and capabilities.drop. runAsNonRoot: true only requires that the UID be non-zero while the actual UID is decided by the image, and runAsUser sets a specific numeric UID; the two can be combined for strictness. Mounting the root filesystem read-only, combined with writable emptyDir volumes for paths like /tmp, is a hallmark of the restricted Pod Security Standard.
Pod Security Standards define three levels applied through namespace labels: Privileged is unrestricted, Baseline blocks known dangerous escalations, and Restricted enforces hardened best practices including no root, no host network, and no privileged containers. PodSecurity Admission is the built-in admission controller that implements these standards and replaced the older PodSecurityPolicy, which was removed in v1.25. Beyond Pod-level security, NetworkPolicies enforce traffic controls at the IP and port level via the CNI plugin, with default-deny as the recommended baseline, while ResourceQuotas and LimitRanges cap total and per-Pod consumption within a namespace. For richer policy, admission webhooks hook into the request pipeline: Mutating Admission Webhooks can modify objects before they are stored, and Validating Admission Webhooks can only accept or reject. Full policy engines like OPA Gatekeeper and Kyverno build on these webhooks: Gatekeeper uses Rego, while Kyverno uses YAML rules to validate, mutate, generate, and verify images across the cluster.