CG
SkillsImplementing Kubernetes Pod Security Standards
Start Free
Back to Skills Library
Container & Cloud-Native Security🟡 Intermediate

Implementing Kubernetes Pod Security Standards

Pod Security Standards (PSS) define three levels of security policies -- Privileged, Baseline, and Restricted -- enforced by the Pod Security Admission (PSA) controller built into Kubernetes 1.25+. PS.

3 min read8 code examples

Prerequisites

  • Kubernetes cluster 1.25+ (PSA GA)
  • kubectl configured with cluster-admin access
  • Understanding of Linux capabilities and security contexts

Implementing Kubernetes Pod Security Standards

Overview

Pod Security Standards (PSS) define three levels of security policies -- Privileged, Baseline, and Restricted -- enforced by the Pod Security Admission (PSA) controller built into Kubernetes 1.25+. PSA replaces the deprecated PodSecurityPolicy and provides namespace-level enforcement with three modes: enforce, audit, and warn.

Prerequisites

  • Kubernetes cluster 1.25+ (PSA GA)
  • kubectl configured with cluster-admin access
  • Understanding of Linux capabilities and security contexts

Core Concepts

Three Security Profiles

ProfilePurposeRestrictions
PrivilegedUnrestricted, system workloadsNone
BaselinePrevents known escalationsNo hostNetwork, hostPID, hostIPC, privileged containers, dangerous capabilities
RestrictedHardened best practicesNon-root, drop ALL caps, seccomp required, read-only rootfs recommended

Three Enforcement Modes

ModeBehavior
enforceRejects pods that violate the policy
auditLogs violations in audit log but allows pod
warnReturns warning to user but allows pod

Implementation Steps

Step 1: Label Namespaces for PSA

# Restricted namespace - production workloads
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest
# Baseline namespace - general workloads
apiVersion: v1
kind: Namespace
metadata:
  name: staging
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest
# Privileged namespace - system components only
apiVersion: v1
kind: Namespace
metadata:
  name: kube-system
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/enforce-version: latest

Step 2: Apply Labels to Existing Namespaces

# Apply restricted enforcement to production
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted \
  --overwrite

# Apply baseline to staging with restricted warnings
kubectl label namespace staging \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted \
  --overwrite

# Check labels on all namespaces
kubectl get namespaces -L pod-security.kubernetes.io/enforce

Step 3: Create Compliant Pod Specs

# Restricted-compliant deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: secure-app
  template:
    metadata:
      labels:
        app: secure-app
    spec:
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 65534
        runAsGroup: 65534
        fsGroup: 65534
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: app
          image: myregistry.com/myapp:v1.0.0@sha256:abc123
          ports:
            - containerPort: 8080
              protocol: TCP
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL
            runAsNonRoot: true
            runAsUser: 65534
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"
            limits:
              memory: "256Mi"
              cpu: "500m"
          volumeMounts:
            - name: tmp
              mountPath: /tmp
            - name: cache
              mountPath: /var/cache
      volumes:
        - name: tmp
          emptyDir:
            sizeLimit: 100Mi
        - name: cache
          emptyDir:
            sizeLimit: 50Mi

Step 4: Gradual Migration Strategy

# Phase 1: Audit mode - discover violations without blocking
kubectl label namespace my-namespace \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

# Check audit logs for violations
kubectl logs -n kube-system -l component=kube-apiserver | grep "pod-security"

# Phase 2: Enforce baseline, warn on restricted
kubectl label namespace my-namespace \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/warn=restricted \
  --overwrite

# Phase 3: Full restricted enforcement
kubectl label namespace my-namespace \
  pod-security.kubernetes.io/enforce=restricted \
  --overwrite

Step 5: Dry-Run Enforcement Testing

# Test what would happen with restricted enforcement
kubectl label --dry-run=server --overwrite namespace my-namespace \
  pod-security.kubernetes.io/enforce=restricted

# Example output:
# Warning: existing pods in namespace "my-namespace" violate the new
# PodSecurity enforce level "restricted:latest"
# Warning: nginx-xxx: allowPrivilegeEscalation != false,
#   unrestricted capabilities, runAsNonRoot != true, seccompProfile

Baseline Profile Restrictions

ControlRestrictedRequirement
HostProcessMust not setPods cannot use Windows HostProcess
Host NamespacesMust not setNo hostNetwork, hostPID, hostIPC
PrivilegedMust not setNo privileged: true
CapabilitiesBaseline list onlyOnly NET_BIND_SERVICE, drop ALL for restricted
HostPath VolumesMust not useNo hostPath volume mounts
Host PortsMust not useNo hostPort in container spec
AppArmorDefault/runtimeCannot set to unconfined
SELinuxLimited typesOnly container_t, container_init_t, container_kvm_t
/proc Mount TypeDefault onlyMust use Default proc mount
SeccompRuntimeDefault or LocalhostMust specify seccomp profile (restricted)
SysctlsSafe set onlyLimited to safe sysctls

Validation Commands

# Verify namespace labels
kubectl get ns --show-labels | grep pod-security

# Test pod creation against policy
kubectl run test-pod --image=nginx --namespace=production --dry-run=server

# Check for violations in audit logs
kubectl get events --field-selector reason=FailedCreate -A

# Scan with Kubescape for PSS compliance
kubescape scan framework nsa --namespace production

Compliance Framework Mapping

This skill supports compliance evidence collection across multiple frameworks:

  • SOC 2: CC6.1 (Logical Access), CC7.1 (Monitoring), CC8.1 (Change Management)
  • ISO 27001: A.14.2 (Secure Development), A.12.6 (Technical Vulnerability Mgmt)
  • NIST 800-53: CM-7 (Least Functionality), SI-2 (Flaw Remediation), SC-28 (Protection at Rest)
  • NIST CSF: PR.IP (Information Protection), PR.DS (Data Security)

Claw GRC Tip: When this skill is executed by a registered agent, compliance evidence is automatically captured and mapped to the relevant controls in your active frameworks.

Deploying This Skill with Claw GRC

Agent Execution

Register this skill with your Claw GRC agent for automated execution:

# Install via CLI
npx claw-grc skills add implementing-kubernetes-pod-security-standards

# Or load dynamically via MCP
grc.load_skill("implementing-kubernetes-pod-security-standards")

Audit Trail Integration

When executed through Claw GRC, every step of this skill generates tamper-evident audit records:

  • SHA-256 chain hashing ensures no step can be modified after execution
  • Evidence artifacts (configs, scan results, logs) are automatically attached to relevant controls
  • Trust score impact — successful execution increases your agent's trust score

Continuous Compliance

Schedule this skill for recurring execution to maintain continuous compliance posture. Claw GRC monitors for drift and alerts when re-execution is needed.

References

  • Pod Security Standards - Kubernetes
  • Pod Security Admission - Kubernetes
  • Migrate from PodSecurityPolicy
  • Kubescape PSS Scanner

Use with Claw GRC Agents

This skill is fully compatible with Claw GRC's autonomous agent system. Deploy it to any registered agent via MCP, and every execution will be logged in the tamper-evident audit trail.

// Load this skill in your agent
npx claw-grc skills add implementing-kubernetes-pod-security-standards
// Or via MCP
grc.load_skill("implementing-kubernetes-pod-security-standards")

Tags

containerskubernetessecuritypod-securityPSA

Related Skills

Container & Cloud-Native Security

Auditing Kubernetes RBAC Permissions

3m·intermediate
Container & Cloud-Native Security

Implementing Network Policies for Kubernetes

3m·intermediate
Container & Cloud-Native Security

Securing Container Registry with Harbor

3m·intermediate
Container & Cloud-Native Security

Detecting Container Escape Attempts

5m·advanced
Container & Cloud-Native Security

Performing Kubernetes Penetration Testing

4m·advanced
Container & Cloud-Native Security

Performing Docker Bench Security Assessment

3m·intermediate

Skill Details

Domain
Container & Cloud-Native Security
Difficulty
intermediate
Read Time
3 min
Code Examples
8

On This Page

OverviewPrerequisitesCore ConceptsImplementation StepsBaseline Profile RestrictionsValidation CommandsReferencesCompliance Framework MappingDeploying This Skill with Claw GRC

Deploy This Skill

Add this skill to your Claw GRC agent and start automating.

Get Started Free →