Container Security Based on Kubernetes Pod Security Standards and Pod Security Admission

1. Overview

Definition: Kubernetes Pod Security Standards (PSS) define the permissions and isolation features available to a Pod through three cumulative security profiles, while Pod Security Admission (PSA) applies those profiles at Namespace scope through the built-in enforce, audit, and warn modes.

Containers isolate processes and filesystems, but weak isolation can allow sharing the host network, process, or IPC namespace, or grant excessive Linux capabilities. Settings such as privileged: true increase convenience while greatly expanding the attack surface for container escape or host takeover. Image vulnerability checks alone are therefore insufficient; runtime permissions must also be checked consistently at deployment time.

The early PodSecurityPolicy (PSP) was available but entered a deprecation path in Kubernetes 1.21 and was removed in 1.25. PSA applies PSS through the API server's built-in admission controller without installing a separate webhook. PSA is not a general policy engine for every container control, however, so it should be designed in layers with NetworkPolicy, image signing, and runtime detection.

PSS separates policy content from policy application. The policy says “what Pod security level is required,” while the PSA mode decides whether to reject, record, or warn about a violation. This separation permits reuse of one baseline across development, validation, and production clusters while gradually strengthening enforcement.

The current Kubernetes documentation explains the three profiles, modes, Namespace labels, version pinning, and exemptions. Documentation versions can differ from the cluster version, so operations should consult PSS documentation matching the actual control-plane and kubelet versions.

1.1 Background and Necessity

First, a container image is an application artifact, not the final authority for runtime permissions. Even with the same image, risk changes with hostNetwork, hostPID, privileged, allowPrivilegeEscalation, seccomp, and capability settings. PSS groups these runtime attributes into standard profiles and establishes an organizational minimum.

Second, a multi-tenant cluster must prevent a team's YAML from crossing platform boundaries. When a profile is attached to a Namespace, every team pipeline must pass the same admission criteria, so security checks do not depend only on an application developer remembering every rule.

Third, rejecting everything with restricted from the beginning can interrupt existing workloads and operations tools at once. PSA's warn and audit modes provide a transition stage that observes violations while allowing deployment. They should be used to reduce exceptions and permit privileged Namespaces only when explicitly justified.

2. PSS Profiles and Security Boundaries

flowchart LR
    P[Pod manifest] --> PSA[Pod Security Admission]
    PSA --> L{Namespace labels}
    L --> PR[Privileged<br/>unrestricted]
    L --> BA[Baseline<br/>known escalation prevention]
    L --> RE[Restricted<br/>hardening best practices]
    PR --> A[Pod admitted]
    BA --> B[Baseline-compliant Pod]
    RE --> C[Restricted-compliant Pod]
    PSA --> M{Mode}
    M --> E[enforce: reject]
    M --> U[audit: audit annotation]
    M --> W[warn: client warning]

The three PSS levels are cumulative boundaries rather than independent menu choices. privileged is unrestricted, baseline prevents known privilege escalation while emphasizing compatibility with ordinary workloads, and restricted includes the baseline constraints while requiring current Pod-hardening practices such as non-root execution, seccomp, and minimal capabilities.

privileged may be unavoidable for node agents, device plugins, and network or storage systems that interact directly with the host. Allowing every operations tool to run as privileged, however, removes the meaning of Namespace isolation. Limit this profile to trusted operators and narrow Namespaces, and document the reason, image, service account, and node scope.

baseline is a practical starting point for ordinary applications. It limits known risks such as host-namespace sharing, privileged containers, dangerous additional capabilities, and disallowed hostPath, hostPort, or sysctl settings. Because one failing container causes the whole Pod to fail validation, init containers and ephemeral containers must also be checked.

restricted applies strong Pod hardening at the cost of some compatibility. Linux containers must not allow privilege escalation; seccomp must be RuntimeDefault or Localhost; and capabilities must drop ALL, adding back only NET_BIND_SERVICE when truly necessary. If the container or image does not run as non-root, the application must be changed.

Profile	Purpose	Typical target	Representative controls
Privileged	Maximum compatibility and permissions	Node and infrastructure workloads	No restrictions; explicit exception required
Baseline	Block known privilege escalation	Ordinary applications	Limit host namespaces, privileged mode, and risky capabilities
Restricted	Strong Pod hardening	Security-critical and low-trust workloads	Minimize non-root, seccomp, and capabilities

Attaching a profile name to a Namespace does not complete security. For example, baseline does not inspect vulnerable images, and restricted does not control service-account token purpose or east-west traffic. PSS should be understood as the first defense line for defining the permissions with which a Pod may start.

3. PSA Behavior and Label Model

sequenceDiagram
    participant C as Client or Controller
    participant API as kube-apiserver
    participant PSA as Pod Security Admission
    participant NS as Namespace labels
    participant AUD as Audit log
    participant K as Kubelet
    C->>API: Create Deployment or Pod
    API->>PSA: Admission request
    PSA->>NS: Read enforce/audit/warn level and version
    PSA-->>API: Decision and warnings
    PSA->>AUD: Record violation annotation when audit applies
    API-->>C: Reject, warning, or success
    API->>K: Schedule admitted Pod

PSA reads Namespace labels to determine a profile per mode. The basic form is pod-security.kubernetes.io/<MODE>: <LEVEL>; MODE is enforce, audit, or warn, and LEVEL is privileged, baseline, or restricted. For example, pod-security.kubernetes.io/enforce=baseline rejects creation of a Pod that violates baseline.

enforce treats a violation as a failed API request. The user receives Forbidden and the violating field, then must repair the manifest. When a Deployment is created, its template may be validated before a Pod exists, but enforcement is applied to the resulting Pod object; this distinction should be clear in the pipeline.

audit allows the request but leaves an audit annotation so violations can be aggregated in centralized audit logs. It is useful for measuring which control is violated by which Namespace. If log collection is incomplete, audit becomes silent allowance, so the API server audit policy and retention period must be designed together.

warn allows the request but returns a user-facing warning. This is useful to developers and deployment pipelines, but an automation tool may discard warnings. CI should convert warnings into visible work items or failures according to the rollout stage.

The three modes may use different levels simultaneously. With enforce=baseline, audit=restricted, and warn=restricted, baseline is mandatory while restricted violations are observed for migration. Production can use this combination to preserve availability while reducing violations against the stronger target.

3.1 Policy Version Pinning

PSS criteria can change with Kubernetes minor versions. The label pod-security.kubernetes.io/<MODE>-version pins a mode to the policy shipped with a particular version, while latest follows the current criteria. To prevent a sudden tightening during a cluster upgrade, consider pinning enforcement to a tested version and using the latest version for audit and warning.

Version pinning is not permission to keep an old security level forever. Fields allowed by the pinned version but restricted by the latest version should remain visible through audit and warn, with an application remediation plan before the next upgrade. Mixed-version clusters also require care because older kubelets may not enforce Pod OS fields fully.

4. Main Controls and Application Procedure

4.1 Host Isolation and Privilege Escalation

Using hostNetwork, hostPID, or hostIPC couples a Pod to the node's network, process, or IPC domain. Except for system Pods with a clear purpose such as monitoring or network plugins, these fields should be disallowed. Even when host namespaces are necessary, analyze other workloads that may be placed on the same node and the resulting attack path.

A privileged container can bypass most container isolation mechanisms. When allowPrivilegeEscalation is true, a process may increase privileges through setuid or file capabilities, so restricted requires false. runAsNonRoot and runAsUser must match the real image user; otherwise the service may fail to start, making user definition during image build important.

Linux capabilities are smaller than full root but permissions such as NET_ADMIN and SYS_ADMIN can still affect the system. Restricted removes all capabilities first and adds back only NET_BIND_SERVICE when necessary. Changing the application to use a high port may be safer than retaining a capability exception.

4.2 seccomp, AppArmor, and SELinux

seccomp limits the system calls a container process may invoke. RuntimeDefault uses the runtime's default profile, while a specialized application may specify a Localhost profile. Bypassing the profile through privileged execution widens the kernel attack surface, so required system calls should be established through compatibility and performance tests.

AppArmor and SELinux depend on the image and node operating system. Even when PSS checks an allowed field form, operators must separately verify that the profile is loaded on the node and audit events are collected. Mixing different node operating systems can make the same Pod behave differently under the security profile.

4.3 YAML Design and Supply-Chain Integration

PSS evaluates the final PodSpec, so Helm defaults, Kustomize overlays, and templates generated by Operators all need checking. A Deployment written safely by a developer can still become non-compliant if an Operator adds a privileged init container. Run server dry-run and policy checks on rendered manifests.

Image signing and SBOM are not substitutes for PSS. Signing says which image was deployed, an SBOM says which components it contains, and PSS says with which permissions that image runs. Combining these signals in one deployment approval policy reduces both untrusted components and excessive runtime permissions.

4.4 Exemptions for Privileged Workloads

PSA can configure explicit exemptions for usernames, RuntimeClasses, and Namespaces. An exempt request skips enforce, audit, and warn, so a broad exemption is effectively a policy bypass. When exempting a service account, verify whether users who can create Deployments with that account are indirectly exempted as well.

Approve exemptions based on a specific function and control set, not merely because the workload is called “system.” For example, pin a network-plugin Namespace, device-plugin RuntimeClass, or node-diagnostics image to a digest and node scope, then add RBAC, NetworkPolicy, and audit logging. Review the list regularly so obsolete permissions do not remain.

5. Rollout and Operations

The first step is to inventory all Namespaces and workloads. Separate system Namespaces, build and deployment tools, applications, and observability or security agents, then collect use of privileged mode, hostPath, hostNetwork, and capabilities. An unlabeled Namespace should mean “not yet evaluated,” not “safe.”

Second, set a target and enable warn and audit first. For example, warn on baseline in development Namespaces and warn and audit restricted for sensitive services. Track violating fields, owning team, remediation difficulty, and business impact in a table, while preserving causes and alternatives in a prose runbook.

Third, enforce in test and staging. Use kubectl label --dry-run=server to evaluate existing Pods against the new level, and validate Pods generated by Deployments, Jobs, CronJobs, and Operators. Passing one deployment is less important than passing rolling updates, recovery, debug ephemeral containers, and node replacement scenarios.

Fourth, migrate production by Namespace. Apply baseline enforcement to ordinary applications first and promote repaired services to restricted. Isolate unavoidable privileged workloads in separate Namespaces with approved exemptions instead of mixing them with ordinary applications.

Fifth, observe criteria changes before and after upgrades. If enforcement is pinned, keep evaluating the latest profile through audit and warn and include the delta in release validation. Connect violation count, exemption count, deployment failure rate, and mean time to detect security incidents to dashboards and management metrics.

6. Comparative Analysis

6.1 PSS and General-Purpose Policy Engines

PSS is built into Kubernetes and offers a simple operating model of three profiles and Namespace labels. It has a low adoption barrier because there is no separate webhook to install and upgrade, making it suitable for a common minimum baseline. It is less expressive for organization-specific rules such as approved image registry prefixes, allowed hostPath directories, or cross-field conditions.

General-purpose engines such as OPA Gatekeeper and Kyverno can extend policies with organizational rules, auditing, mutation, and validation. They also require operation of webhook availability, policy ordering, performance, failure behavior, and CRD lifecycles. In practice, using PSS for the common minimum and a general engine for enterprise-specific conditions is a reasonable combination.

Comparison axis	PSS and PSA	General-purpose policy engine
Installation	Primarily built into Kubernetes	Separate controller and webhook
Policy expression	Three profiles and Pod security fields	Organization-specific conditions and transformations
Scope	Mainly Pod security and Namespace	Images, labels, resource relationships, and more
Advantage	Simplicity, consistency, low barrier	High expressiveness and automation
Caution	Limited fine-grained exceptions and enterprise rules	Webhook availability, conflicts, and operational complexity

6.2 PSS and Runtime Security

PSS is a preventive control at Pod creation or update time. A runtime tool such as Falco observes processes, file access, and network behavior to detect attacks or abnormal behavior after execution begins. The former means “do not start with this setting,” while the latter means “detect abnormal activity after start”; they deepen defense rather than compete.

For example, an image that passes restricted may still execute a shell through an application vulnerability, which PSS cannot detect. Conversely, relying only on runtime detection responds after execution. Pod creation policy, network isolation, image trust, and runtime detection must operate together.

7. Application Cases and Advanced Topics

7.1 Financial Transaction API Cluster

A financial transaction API sets restricted as its target and starts with enforce=baseline, audit=restricted, and warn=restricted. Developers make images run as non-root and support a read-only root filesystem, while the platform team adds seccomp RuntimeDefault and capability drops to the common Helm chart. Audit logs track violations and approved exemptions by service.

After enabling restricted enforcement in staging, repeat payment approval, rolling deployment, and recovery scenarios. If an ephemeral container is necessary for debugging, use an approved debug RuntimeClass and short-lived access account instead of giving ordinary operators unrestricted permissions. This prevents operational convenience from becoming a permanent privileged path.

7.2 Manufacturing Edge Cluster

At a factory edge, device plugins and network agents may require a host namespace or a particular capability. Separate them from application Namespaces and narrow exemptions by image digest, RuntimeClass, and service account. Operate sensor collection services with baseline or restricted so the privileged path of field infrastructure does not spread to business APIs.

Because edge clusters may be disconnected, declare labels and PSA settings during cluster provisioning and retain local audit logs. When connectivity returns, synchronize exemptions and violations centrally so site-specific exceptions do not accumulate without review.

7.3 Exam and Related-Topic Strategy

In an exam answer, do not only define PSS; draw the causal flow “risky PodSpec → PSA mode decision → API response or audit → kubelet execution → runtime observation.” Then summarize the three profiles in a table and explain in prose why each profile is needed organizationally.

When linking to container security, DevSecOps, zero trust, and supply-chain security, separate the control points. PSS addresses workload permissions, image signing addresses provenance, SBOM addresses component transparency, NetworkPolicy addresses communication scope, and runtime security addresses behavior. This avoids a list-style answer that merely says more security tools should be installed.

8. Considerations and Implications

Balance availability and least privilege. Immediate restricted enforcement can interrupt operations and deployment tools, so collect violations with warn and audit and set a service-by-service remediation order. Conversely, privileged should not be the default; isolate exceptions in separate Namespaces with RBAC, audit, and expiry dates.
Manage policy and cluster versions together. Kubernetes upgrades can change PSS criteria, and mixed-version kubelets can enforce OS-specific fields differently. Pre-validate the enforcement version and operate audit and warn against the latest criteria to find upgrade risk early.
Manage exemptions as security assets. Since username, RuntimeClass, and Namespace exemptions skip all three modes, record the reason, owner, image, allowed nodes, and expiry date. Review the resources a service account can create and perform periodic access recertification.
Connect controls outside PSS explicitly. A Pod can pass PSS while its image is vulnerable, its network reach is excessive, its service account is stolen, or its runtime behavior is abnormal. Connect image scanning and signing, SBOM and VEX, NetworkPolicy, Secret management, and runtime detection into one policy flow with clear owners.
Verify policy effect with operating metrics. The goal is not merely to reduce violation counts; track privileged ratio, exemption ratio, deployment failure rate, average exception lifetime, and incident detection time. These metrics let a professional engineer explain the effect of security strengthening on productivity and availability.

References

In one line: PSS defines the minimum security boundary for Pod permissions and PSA gradually applies it through Namespace-level warn, audit, and enforce modes, so effective container security must also manage versions, exemptions, supply chain, and runtime controls.