Course outline

01 · Kubernetes Architecture Deep Dive

02 · Workloads & Scheduling

03 · Networking, Storage & Service Mesh

04 · Platform Engineering & Multi-Tenancy

05 · Networking & Service Mesh

06 · Observability & Autoscaling

07 · Configuration & Secrets Management

08 · Stateful Storage Operations

09 · Security, Identity & Admission

10 · Release Packaging with Helm & Kustomize

11 · Operators, CRDs & Controllers

12 · Production Troubleshooting & Operations

Stage 5 · Platform

Security, Identity & Admission

Pod Security Admission

Privileged, baseline, restricted profiles, namespace labels, and dry-run enforcement.

7 min readKubernetes & Cloud NativePlatform

Pod Security Standards

Pod Security Standards (PSS) replace PodSecurityPolicy. Three profiles define security levels: Privileged (unrestricted), Baseline (minimally restrictive), and Restricted (heavily restricted). PSS is enforced through Pod Security Admission controller.

Profile	Blocks	Use Case
Privileged	Nothing	System pods, CNI, storage drivers
Baseline	Known privilege escalations	Most application workloads
Restricted	All privilege escalation	Security-sensitive workloads

Security Profiles

Each profile has specific rules. Baseline blocks: privileged containers, host networking, host PID, host IPC, host ports, and certain capabilities. Restricted adds: non-root requirement, read-only root filesystem, dropping all capabilities, and seccomp profile.

Restricted profile requirements


# Restricted profile requires:
apiVersion: v1
kind: Pod
metadata:
  name: restricted-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
    resources:
      limits:
        cpu: "500m"
        memory: "256Mi"

Restricted profile requires: non-root user, read-only filesystem, all capabilities dropped, seccomp RuntimeDefault, no privilege escalation. These restrictions prevent container breakout and privilege escalation.

Namespace Labels

PSS uses namespace labels to enforce profiles. Three modes: enforce (reject non-compliant), audit (log violations), warn (show warnings). Each mode can target a different profile, allowing gradual enforcement.

Progressive enforcement labels


apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    # Start with warn-only
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest
    # Audit violations
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: latest
    # Don't enforce yet — see what would break
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: latest

Start with warn-only to see which pods violate restricted profile. Fix violations, then upgrade enforce from baseline to restricted. This prevents breaking existing workloads during migration.

Dry-Run Mode

Dry-run mode evaluates policies without enforcing them. Use it to test what would be rejected. The API server returns warnings without blocking the request. This is essential for safe policy rollout.

Dry-run testing


# Test if a pod would pass restricted profile
kubectl apply -f pod.yaml --dry-run=server 2>&1 | grep -i warning

# Check pod compliance with PSA
kubectl label namespace production pod-security.kubernetes.io/warn=restricted

# Apply pod and see warnings
kubectl apply -f pod.yaml
# Warning: would violate "restricted" profile:
#   allowPrivilegeEscalation != false
#   capabilities must drop "ALL"

--dry-run=server evaluates the request against all admission controllers without persisting. Warnings show which PSS rules are violated. Fix the pod spec until no warnings appear.

Migrating to PSS

Migration steps: 1) Enable warn mode for restricted profile. 2) Fix all warnings. 3) Enable audit mode. 4) Verify no audit violations. 5) Enable enforce mode for baseline. 6) Upgrade to restricted. 7) Test with --dry-run=server.

Migration commands


# Step 1: Enable warnings
kubectl label ns production \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/warn-version=latest

# Step 2: Check for violations
kubectl get events -n production --field-selector reason=FailedCreate

# Step 3: Fix violations in pod specs
# Add securityContext, drop capabilities, etc.

# Step 4: Enable enforcement
kubectl label ns production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest --overwrite

Migrate gradually: warn first, then audit, then enforce. This lets you fix violations without breaking running workloads. Always test with --dry-run=server before enabling enforcement.

Custom Policies

PSS covers standard Kubernetes security controls. For custom policies (image registries, labels, resource patterns), use Kyverno or Gatekeeper alongside PSS. These engines extend PSS with application-specific rules.

Kyverno policy alongside PSS


apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-digest
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-image-digest
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "Images must use digest pinning"
      pattern:
        spec:
          containers:
          - image: "*@sha256:*"

Kyverno extends PSS with image digest pinning. PSS doesn't cover image policies — Kyverno fills the gap. Both run as admission controllers and can be combined for comprehensive security.

PSS exemption for system namespaces

Exempt system namespaces (kube-system, kube-public) from PSS enforcement. System components often need privileged access. Use --exempt-namespaces=kube-system,kube-public,kube-node-lease on the API server.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.