Kubernetes does not make an application safe merely because it runs inside a container. Containers share the node kernel, and a poorly constrained workload can gain far more host or cluster access than the application actually needs. Security contexts let workload authors describe process-level restrictions, while Pod Security Standards and admission controls help platform teams establish consistent minimums across namespaces.
This topic is central to the current KCSA security curriculum, which includes Pod Security Standards, admission, authentication, authorization, isolation, and other Kubernetes security fundamentals. The practical goal is not to memorize every field. It is to understand how identity, privileges, kernel controls, filesystem access, and admission policy combine to reduce the blast radius of a compromised container.
Separate container isolation from process privilege
A container packages a process with namespaces, cgroups, filesystems, and other runtime controls, but it is still a process on a node. If that process runs as root, has broad Linux capabilities, can write to the host filesystem, or is privileged, the boundary is much weaker than many teams assume.
Kubernetes security context fields express constraints such as the UID or GID a process should use, whether privilege escalation is allowed, which Linux capabilities are present, whether the root filesystem is read-only, and which seccomp or other kernel security profiles apply. Some settings are defined at Pod level and inherited by containers; others are container-specific and can override Pod-level values where the API permits.
Think in terms of least privilege. Start with the smallest process identity and kernel permissions that let the workload function, then add only what evidence shows is necessary. This is the same principle that makes broader application security more resilient: remove unnecessary authority before an attacker can use it.
Run application processes as non-root wherever possible
Using a non-root UID limits what a compromised process can do inside the container and can interact with host-level protections to reduce risk. Kubernetes can specify runAsUser, runAsGroup, and runAsNonRoot. A manifest can therefore enforce an execution identity even when the image was built with weak defaults.
Do not treat an arbitrary high UID as a complete security model. File ownership, mounted volumes, supplemental groups, application ports, and image contents still matter. If the image expects root to create files at startup, changing only runAsNonRoot may cause a deployment failure. The better solution is usually to build the image so the application can operate correctly without root.
Validate file permissions during image build and in persistent storage. A non-root container that receives a writable volume with overly broad permissions can still alter more data than intended.
Control privilege escalation and Linux capabilities explicitly
Linux capabilities split traditional root authority into narrower privileges. A container that needs to bind to a low port should not automatically receive every root capability. Kubernetes security context configuration can drop capabilities and selectively add back the few required by the application.
allowPrivilegeEscalation: false prevents a process from gaining more privileges than its parent through mechanisms such as setuid binaries. It is an important control, but it must be interpreted with the rest of the security context. Privileged containers and certain powerful capabilities are inconsistent with that restriction.
A useful hardening pattern is to drop all capabilities by default, then justify exceptions. The Kubernetes Restricted Pod Security Standard follows this direction by requiring broad capability removal and allowing only a narrow exception. This turns permission design from an implicit runtime default into an explicit part of the workload specification.
Use read-only filesystems and controlled writable paths
Many application containers do not need to modify their root filesystem after startup. Setting a read-only root filesystem limits persistence opportunities and prevents accidental writes to image layers. Writable application data can be placed on specific mounted volumes such as an emptyDir, persistent volume, or projected configuration volume depending on the use case.
This design also exposes hidden application assumptions. If a process writes logs, temporary files, caches, or generated configuration into arbitrary directories, enabling read-only root may break it. Rather than abandoning the control, identify the required paths and mount only those as writable.
Filesystem controls are defense in depth. They do not replace proper API authorization, network policy, or secret handling, but they make post-compromise behavior more constrained and observable.
Apply seccomp, AppArmor, and SELinux as kernel-level boundaries
Security contexts can connect Kubernetes workloads to Linux kernel protections. Seccomp filters system calls; AppArmor applies profiles that restrict process behavior; SELinux labels subjects and objects so mandatory access-control policy can govern what a process may touch. The exact availability depends on the node operating system and runtime configuration.
Seccomp’s RuntimeDefault profile is a strong baseline for many workloads because it blocks system calls that ordinary applications rarely need. A custom Localhost profile can be tighter, but it adds node-management complexity because the profile must exist where the Pod runs.
Do not enable a kernel mechanism purely for compliance paperwork. Test the workload, observe denials, and understand the exceptions. A policy that is routinely set to unconfined after deployment failures provides little protection.
Understand the Pod Security Standards profiles
Kubernetes defines Privileged, Baseline, and Restricted Pod Security Standards. Privileged is effectively unrestricted and is suitable only for workloads that genuinely require broad host-level access. Baseline blocks well-known privilege escalations while permitting common application patterns. Restricted follows current hardening best practices and is designed for lower-trust application workloads.
The Restricted profile covers controls such as non-root execution, seccomp configuration, and tight capability use. It is intentionally more demanding, so existing workloads may require remediation before it can be enforced. The aim is not to label every namespace Restricted on day one. It is to understand which workloads require exceptions and reduce those exceptions over time.
Infrastructure agents, storage plugins, and networking components may legitimately need host access. Keep them in tightly controlled namespaces with strong RBAC rather than weakening every application namespace to accommodate a few privileged system workloads.
Use Pod Security Admission in enforce, audit, and warn modes
Pod Security Admission evaluates Pods against Pod Security Standards and can be configured through namespace labels. enforce blocks noncompliant workloads, warn returns client-visible warnings, and audit records violations for later analysis. Kubernetes documentation recommends using these modes strategically so teams can see future enforcement problems before breaking production.
A practical rollout is to begin with audit and warn, inventory violations, fix the largest classes of weak configuration, and then move selected namespaces to enforcement. Pinning policy versions can provide stability, while auditing or warning against a newer version helps teams prepare for evolving standards.
PodSecurityPolicy is no longer the model to design around; it was removed from Kubernetes. Current platforms should use Pod Security Admission and, when they need more expressive controls, other admission-policy mechanisms.
Recognize where admission policy needs more than Pod Security Standards
Pod Security Standards intentionally focus on common workload-hardening fields. They do not express every organizational rule. A team may also need policies that restrict registries, require image digests, mandate resource limits, forbid particular host paths, enforce labels, or verify signed artifacts.
Kubernetes supports policy enforcement through built-in mechanisms such as ValidatingAdmissionPolicy and through dynamic admission webhooks. Ecosystem tools can evaluate richer policy and external data. Choose controls based on the rule you need, operational reliability, and the failure mode when the policy service is unavailable.
Admission is part of the API write path, so a broken webhook can become a cluster availability problem. Treat policy services as production infrastructure with monitoring, certificates, scaling, and tested failure behavior.
Test effective security, not just manifest syntax
A secure-looking manifest can still run with unexpected authority if admission policy is misconfigured, the wrong namespace labels are applied, or node-level protections are absent. Test representative workloads and verify the effective UID, group, capabilities, filesystem writability, seccomp profile, and ability to access sensitive host interfaces.
Use negative tests as well. Confirm that the platform rejects a privileged Pod where it should, blocks disallowed capabilities, and prevents a workload from bypassing namespace security expectations. These tests are especially valuable after cluster upgrades or policy changes.
Keep exceptions visible. If a workload needs privilege, document why, who owns it, what compensating controls exist, and when the exception will be reviewed. An undocumented privileged namespace becomes permanent security debt.
Security contexts limit what a compromised process can do on its node, but they do not stop stolen service-account credentials from calling APIs the account is authorized to use. Pod Security Standards do not replace NetworkPolicy. Read-only filesystems do not protect a Secret that the application is allowed to read. Each control narrows one attack path.
Combine workload hardening with minimal RBAC, network segmentation, secret protection, image provenance, runtime monitoring, and timely patching. The broader hardening discipline is useful: reduce exposed functionality, configure safe defaults, monitor deviations, and make exceptions deliberate.
Within CNCF certifications, Pod security is foundational because it ties Kubernetes API configuration to Linux process security. Administrators who understand both layers can reason about why a setting matters instead of treating securityContext as a checklist copied from another manifest.
Test security settings against init containers and ephemeral containers as well as the main application container. A Pod that hardens only its primary container can still expose broader privilege through a helper container. Review every container specification and the Pod-level defaults that apply to them.
Volume types also influence the effective boundary. A container with a read-only root filesystem can still write to mounted volumes, and a hostPath mount can expose sensitive node files regardless of ordinary image isolation. Restrict hostPath and other host-integrating features through admission policy, and make infrastructure exceptions explicit.
Host namespaces are another high-risk capability. hostPID, hostIPC, and hostNetwork reduce isolation between the Pod and node. Some system components need them, but application workloads usually should not. Pod Security Standards help catch these classes of configuration before a workload reaches the node.
Resource limits are not a direct securityContext field, yet they support resilience against denial-of-service conditions. A compromised or malfunctioning container that can consume unbounded memory or CPU may affect neighboring workloads. Combine privilege reduction with requests, limits, quotas, and node isolation appropriate to workload criticality.
Security contexts should be part of reusable application scaffolding rather than an afterthought. Platform teams can provide tested base manifests, Helm values, or policy templates that make the secure path easy. Developers then override only the few settings their application genuinely needs instead of copying permissive examples from old repositories.
Observe admission results during rollout. Warnings from Pod Security Admission can identify fields that will fail under a future Restricted policy. Capture those warnings in CI or deployment logs so they become actionable engineering work rather than terminal output that disappears after a manual deployment.
Version pinning deserves attention. Pinning enforcement to a specific Pod Security Standard version can prevent an upgrade from unexpectedly blocking existing workloads, while warning or audit against latest exposes future incompatibilities. This creates a controlled migration path instead of choosing between surprise breakage and permanently stale security.
Cluster administrators should also review exemptions. Pod Security Admission can exempt namespaces, users, or runtime classes, but each exemption creates a path around normal enforcement. Keep the list short, document ownership, and protect the identities that qualify for exemption with stronger RBAC and auditing.
When a workload cannot meet Restricted requirements, determine the exact control it conflicts with. A networking daemon that needs NET_ADMIN has a different risk from an application that merely expects to write under /tmp. Narrow exception analysis produces better compensating controls than labeling an entire namespace privileged.
Finally, remember that securityContext is declarative configuration. Runtime verification closes the loop. Query the running container’s UID, capabilities, mount flags, and seccomp status during testing. That evidence proves the platform actually delivered the isolation the manifest intended.
Windows workloads require different assumptions. Linux-specific controls such as capabilities, seccomp, and SELinux do not map directly to Windows Pods, so platform policy should account for spec.os.name and the controls supported by each node operating system. Do not assume a manifest that is hardened on Linux has equivalent behavior on Windows.
Security defaults should also be evaluated against third-party charts and operators. Vendor manifests often request permissions for broad compatibility across environments. Review those privileges before installation, and isolate infrastructure components that genuinely need them instead of weakening application policy cluster-wide.
During incident response, security-context information helps determine blast radius. A container that ran as non-root, dropped capabilities, used a read-only root filesystem, and had no host mounts presents a different node-compromise risk from a privileged Pod with host PID and host filesystem access. Preserve the effective Pod specification as evidence.
Policy compliance should be continuous. A namespace can be hardened today and weakened later through a label change, exemption, or new admission configuration. Monitor security-significant namespace labels and policy objects, and alert when enforcement level is reduced outside an approved change.
For teams adopting stricter standards, measure violations by category. If hundreds of workloads fail only because seccomp is unset, one platform-defaulting improvement may solve most of the gap. If a small group requires host networking or privilege, those workloads need individual architecture review rather than a broad exception.
Make these controls observable in platform reporting. A periodic inventory of privileged Pods, root-running containers, added capabilities, host namespace use, and namespaces without Pod Security labels gives administrators a concrete backlog. Security posture improves faster when exceptions are visible by owner and workload instead of buried inside thousands of manifests.