Create Secure Kubernetes Pod Configurations

This skill implements Kubernetes pod security through Pod Security Standards (PSS), legacy Pod Security Policies (PSPs), and container security contexts, aligned with defense-in-depth and least-privilege principles enforced at admission, runtime, and network layers. Pods are scoped to one of three standard levels - privileged (unrestricted, development and debugging only), baseline (minimally restrictive, blocks known privilege escalations), and restricted (heavily restricted, current hardening best practice) - enforced either per-namespace via pod-security.kubernetes.io labels or cluster-wide via an AdmissionConfiguration with per-mode defaults and namespace exemptions (typically kube-system and kube-public).

Use it when hardening pod security for a production Kubernetes cluster - setting namespace or cluster-wide enforcement, writing security contexts, or migrating from legacy PSPs to PSS. It is not meant to be validated only on paper: security configurations should be tested in non-production environments first, and policy testing tools should confirm enforcement before rollout.

Given a workload, it produces a pod-level security context (non-root execution with explicit user, group, and fsGroup IDs, a RuntimeDefault seccomp profile, and supplemental groups) paired with a container-level security context (no privilege escalation, a read-only root filesystem, and all Linux capabilities dropped), a legacy restrictive PSP (privileged disabled, non-root enforced, capabilities dropped, a limited allowed-volume list, host network, IPC, and PID disabled) with matching RBAC granting a specific service account the use verb on that PSP, and a default-deny NetworkPolicy that blocks all ingress and restricts egress to DNS only.

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
    supplementalGroups: [4000]
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
      runAsNonRoot: true
      runAsUser: 1000

Compliance mapping ties directly to named CIS Kubernetes Benchmark controls (non-root users at 5.2.6, no privilege escalation at 5.2.5, no root containers at 5.2.6, no NET_RAW capability at 5.2.7, no dangerous capabilities at 5.2.8), and an OPA Gatekeeper ConstraintTemplate with a Rego rule can enforce runAsNonRoot as an admission-time policy independent of PSS. Migration from PSP to PSS follows a four-phase path (audit mode alongside existing PSPs, warn mode to surface non-compliant workloads, gradual per-namespace enforcement, then PSP cleanup), validated with kubectl apply --dry-run=server, kubectl-validate, and conftest against Rego policies.

Platform and security engineers hardening multi-tenant Kubernetes clusters who need namespace isolation with dedicated PSS levels, ResourceQuotas, per-application service accounts, and runtime security layered on top - Falco rules for runtime monitoring, CI/CD image scanning, and commercial runtime tools like Twistlock or Aqua Security for detecting policy violations in production.