Demo Applying Pod Security Standards

Gatekeeper and Kyverno are powerful admission controllers, but both require installing extra tooling. Pod Security Standards (PSS) are built into Kubernetes and let cluster administrators enforce security baselines at the namespace level without deploying operators or CRDs. PSS provides three predefined profiles and three enforcement modes. Use PSS when you want a simple, auditable, label-driven way to validate or block Pod specs at admission time.

Pod Security profiles and modes

Profile	Purpose	Typical use
privileged	Essentially “anything goes” — minimal restrictions.	System and infra workloads that require host access.
baseline	Blocks the most dangerous privilege escalations while minimizing application breakage.	General-purpose application workloads.
restricted	Hardened, follows security best practices.	Sensitive workloads, strict compliance environments.

Mode	Behavior
`enforce`	Blocks creations/updates that violate the profile.
`audit`	Records violations to audit logs (doesn’t block).
`warn`	Prints admission-time warnings but allows the object.

The image shows a webpage from the Kubernetes documentation discussing Pod Security Standards. It outlines different policy levels: Privileged, Baseline, and Restricted, with a navigation sidebar on the left.

You can review the exact checks and rationale for each profile in the Kubernetes Pod Security Standards documentation.

The image shows a webpage from the Kubernetes documentation discussing baseline security policies for containerized workloads, with a focus on managing Windows Pods and HostProcess configurations.

Pod Security Standards are label-driven: a namespace’s enforcement behavior is determined solely by labels on that namespace (for example pod-security.kubernetes.io/enforce=baseline). Labels make policy auditable and easily reversible.

Applying or changing PSS labels requires permission to modify namespaces (typically cluster-admin). Test changes in a non-production cluster or dedicated namespaces before rolling higher-level enforcement.

Typical workflow

The common progression is:

Inspect namespaces and labels.
Label a namespace with PSS modes (warn/audit first to surface issues).
Attempt non-compliant workloads to capture warnings/audit entries.
Fix workloads to meet the profile.
Switch to enforce when ready to block non-compliant Pods.

Follow the steps below.

Check current namespaces and labels

kubectl get namespaces --show-labels

Example output (trimmed):

NAME            STATUS   AGE   LABELS
default         Active   137m  kubernetes.io/metadata.name=default
kube-flannel    Active   137m  k8s-app=flannel,kubernetes.io/metadata.name=kube-flannel,pod-security.kubernetes.io/enforce=privileged
pss-baseline    Active   9m    kubernetes.io/metadata.name=pss-baseline
pss-privileged  Active   9m    kubernetes.io/metadata.name=pss-privileged
pss-restricted  Active   9m    kubernetes.io/metadata.name=pss-restricted

Label a namespace to enforce the baseline profile but also audit/warn the restricted profile so you can see what would fail under stricter rules:

kubectl label namespace pss-baseline \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted
# Output:
# namespace/pss-baseline labeled

Create a Pod that violates baseline to see the enforcement behavior

Save this as privileged-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: privileged-app
spec:
  hostNetwork: true
  containers:
    - name: app
      image: nginx:alpine
      securityContext:
        privileged: true

Apply it into pss-baseline:

kubectl apply -f privileged-pod.yaml -n pss-baseline

You will see an error because baseline forbids host namespaces and privileged containers:

Error from server (Forbidden): error when creating "privileged-pod.yaml": pods "privileged-app" is forbidden: violates PodSecurity "baseline:latest": host namespaces (hostNetwork=true) are prohibited, privileged (container "app" must not set securityContext.privileged=true)

Try a standard nginx Pod that baseline will admit but restricted will warn on

Use kubectl run for a quick test:

kubectl run baseline-test --image=nginx:alpine -n pss-baseline

Admission will allow the Pod but print warnings (because pss-baseline has warn/audit for restricted):

Warning: would violate PodSecurity "restricted:latest": 
- allowPrivilegeEscalation != false (container "baseline-test" must set securityContext.allowPrivilegeEscalation=false)
- capabilities not dropped (container "baseline-test" must set securityContext.capabilities.drop=["ALL"])
- runAsNonRoot != true (pod or container "baseline-test" must set securityContext.runAsNonRoot=true)
- seccompProfile not set (pod or container "baseline-test" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/baseline-test created

These warnings let you discover which fields to add to meet the stricter profile without blocking workloads.

Enforce the restricted profile on another namespace and observe rejections

Label pss-restricted to enforce:

kubectl label namespace pss-restricted pod-security.kubernetes.io/enforce=restricted
# Output:
# namespace/pss-restricted labeled

Try to run the same nginx image there:

kubectl run restricted-test --image=nginx:alpine -n pss-restricted

Since restricted is in enforce mode, creation is blocked and the required corrections are listed:

Error from server (Forbidden): pods "restricted-test" is forbidden: violates PodSecurity "restricted:latest":
- allowPrivilegeEscalation != false (container "restricted-test" must set securityContext.allowPrivilegeEscalation=false)
- capabilities not dropped (container "restricted-test" must set securityContext.capabilities.drop=["ALL"])
- runAsNonRoot != true (pod or container "restricted-test" must set securityContext.runAsNonRoot=true)
- seccompProfile not set (pod or container "restricted-test" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

Example Pod that complies with restricted

Save this as restricted-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: restricted-app
spec:
  containers:
    - name: app
      image: nginx/nginx-unprivileged:alpine
      securityContext:
        runAsNonRoot: true
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        seccompProfile:
          type: RuntimeDefault

Apply it into the restricted namespace:

kubectl apply -f restricted-pod.yaml -n pss-restricted
# Output:
# pod/restricted-app created

The image nginx/nginx-unprivileged:alpine runs as a non-root user and the securityContext fields satisfy the restricted checks.

Use warn mode to discover non-compliant workloads (audit flow)

Create an audit namespace and start in warn mode:

kubectl create namespace workload-audit
kubectl label namespace workload-audit pod-security.kubernetes.io/warn=baseline

Run a test Pod (baseline is permissive):

kubectl run audit-test --image=nginx:alpine -n workload-audit
kubectl get events -n workload-audit

If you then change the warn label to restricted and create another Pod, admission prints warnings for restricted violations:

kubectl label namespace workload-audit pod-security.kubernetes.io/warn=restricted --overwrite
kubectl run audit-test-2 --image=nginx:alpine -n workload-audit

Admission-time output:

Warning: would violate PodSecurity "restricted:latest":
- allowPrivilegeEscalation != false (container "audit-test-2" must set securityContext.allowPrivilegeEscalation=false)
- capabilities not dropped (container "audit-test-2" must set securityContext.capabilities.drop=["ALL"])
- runAsNonRoot != true (pod or container "audit-test-2" must set securityContext.runAsNonRoot=true)
- seccompProfile not set (pod or container "audit-test-2" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/audit-test-2 created

You can inspect events to correlate lifecycle events with admission-time messages:

kubectl get events -n workload-audit

Recommended minimal `securityContext` fields for `restricted`

Field	Example value	Purpose
`runAsNonRoot`	`true`	Ensure containers don’t run as UID 0.
`allowPrivilegeEscalation`	`false`	Prevent setuid binaries / privilege escalation.
`capabilities.drop`	`["ALL"]`	Remove Linux capabilities.
`seccompProfile.type`	`RuntimeDefault`	Apply a seccomp profile at runtime.

Putting these into pod/container specs is the most common way to resolve restricted violations.

Summary

Start with warn and audit modes to safely discover issues.
Fix Pod specs (set runAsNonRoot, allowPrivilegeEscalation=false, drop capabilities, set seccompProfile, avoid host namespaces, etc.) until warnings disappear.
Switch to enforce for the target profile to block non-compliant workloads.
PSS offers a simple, label-driven approach that is easy to audit and reverse without extra operators.

Course Introduction

Platform Architecture and Infrastructure

GitOps and Continuous Delivery

Platform APIs and Self-Service Capabilities

Observability and Operations

Security and Policy Enforcement

Conclusion

Demo Applying Pod Security Standards

Pod Security profiles and modes

Typical workflow

Recommended minimal `securityContext` fields for `restricted`

Summary

Watch Video

Practice Lab

​Pod Security profiles and modes

​Typical workflow

​Recommended minimal securityContext fields for restricted

​Summary

Watch Video

Practice Lab

Pod Security profiles and modes

Typical workflow

Recommended minimal `securityContext` fields for `restricted`

Summary