kyverno-pod-security-baseline

name	kyverno-pod-security-baseline
description	Implements Kyverno podSecurity rules to enforce the Kubernetes Pod Security Standards baseline profile across namespaces in a cluster.
license	MIT
compatibility	opencode
archetypes	["enforcement","tactical"]
anti_triggers	["brainstorming","vague ideation","non-security policy work"]
response_profile	{"verbosity":"medium","directive_strength":"high","abstraction_level":"operational"}
metadata	{"version":"1.0.0","domain":"cncf","triggers":"pod security baseline, PSS baseline, kubernetes pod security, container runtime policies, privileged container prevention, baseline profile enforcement, kubelet pod security","role":"implementation","scope":"implementation","output-format":"manifests","related-skills":"kyverno-pod-security-baseline, kyverno-pod-security-restricted"}

Kyverno Pod Security Standards — Baseline Profile

Implements Kyverno podSecurity rules to enforce the Kubernetes Pod Security Standards (PSS) baseline profile. This skill makes the model configure ClusterPolicy objects that deny pods violating baseline-level restrictions — such as privileged containers, host namespaces, and volume type restrictions — while allowing all other pod configurations. The baseline profile sits between unrestricted and restricted in the PSS hierarchy.

TL;DR Checklist

• Create ClusterPolicy with podSecurity rule at baseline level
• Set enforce mode on matching namespaces
• Add auditAnnotations for logging enforcement events
• Exclude kube-system and monitoring namespaces from enforcement
• Verify with PolicyReport showing pass/fail results

---

When to Use

• Enforcing baseline Pod Security Standards across all application namespaces
• Preventing privileged container execution in production environments
• Blocking host namespace sharing (hostNetwork, hostPID, hostIPC)
• Restricting dangerous volume types like hostPath, secret, and configMap
• Complying with organizational security policies that mandate minimum pod hardening
• Setting up progressive enforcement: baseline in production, restricted in staging

---

When NOT to Use

• When you need the restricted profile (hardened security for sensitive workloads) — use kyverno-pod-security-restricted instead
• For the kube-system namespace — baseline blocks many system components (use exemptions via kyverno-exemptions-management)
• When using legacy Kubernetes versions < 1.23 that lack built-in PSS support

---

Core Workflow

1. Define the podSecurity ClusterPolicy — Create a ClusterPolicy with a podSecurity rule. Set spec.rules[].podSecurity with level: baseline, version: "latest", enforce, audit, and warn modes. Apply the policy to matching namespaces via the match block. Checkpoint: Confirm the version field matches your cluster's Kubernetes minor version (e.g., "1.28" for K8s 1.28).

2. Configure namespace selection and exclusions — Use match to select all namespaces, then add exclude rules for critical system namespaces (kube-system, kube-public, openshift-*). This prevents Kyverno from blocking essential cluster operations. Checkpoint: Verify that kubectl get policyreport -A does not show failures for excluded namespaces.

3. Deploy, verify, and monitor — Apply the ClusterPolicy. Create a test pod that violates the baseline (e.g., privileged: true). Confirm the pod is denied at admission time. Check PolicyReport and Events for enforcement logs. Checkpoint: The violating pod should show Failed to create pod with a Kyverno enforcement message.

---

Implementation Patterns

Pattern 1: Cluster-wide Baseline Enforcement

This pattern enforces the PSS baseline profile on all namespaces except explicitly excluded system namespaces.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: pod-security-baseline
  annotations:
    policies.kyverno.io/title: Pod Security Standards — Baseline
    policies.kyverno.io/category: Pod Security
    policies.kyverno.io/description: >-
      Enforces the Pod Security Standards baseline profile on all
      non-system namespaces. Prevents privileged containers, host
      namespace sharing, and dangerous volume types.
spec:
  rules:
    - name: enforce-baseline
      match:
        any:
          - resources:
              kinds:
                - Pod
      exclude:
        any:
          - namespaces:
              - kube-system
              - kube-public
              - kube-node-lease
              - local-path-storage
      podSecurity:
        level: baseline
        version: latest
        enforce: "latest"
        audit: "latest"
        warn: "latest"
    - name: audit-baseline
      match:
        any:
          - resources:
              kinds:
                - Pod
      exclude:
        any:
          - namespaces:
              - kube-system
              - kube-public
              - kube-node-lease
              - local-path-storage
      podSecurity:
        level: baseline
        version: latest
        audit: "latest"
    - name: warn-baseline
      match:
        any:
          - resources:
              kinds:
                - Pod
      exclude:
        any:
          - namespaces:
              - kube-system
              - kube-public
              - kube-node-lease
              - local-path-storage
      podSecurity:
        level: baseline
        version: latest
        warn: "latest"

Pattern 2: Namespace-scoped Baseline via Labels

Apply the baseline profile per-namespace using labels instead of a ClusterPolicy. This allows different namespaces to have different security levels.

# Label namespaces with baseline enforcement
apiVersion: v1
kind: Namespace
metadata:
  name: production-apps
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/audit-version: latest
    pod-security.kubernetes.io/warn: baseline
    pod-security.kubernetes.io/warn-version: latest

Kyverno PolicyReport Example:

apiVersion: wgpolicyk8s.io/v1alpha2
kind: PolicyReport
metadata:
  name: pod-security-baseline-report
  namespace: production-apps
results:
  - policy: pod-security-baseline
    rule: enforce-baseline
    result: fail
    severity: high
    message: "Pod violates baseline: container 'app' allows privilege escalation"
    scored: true
    source: kyverno
    timestamp:
      seconds: 1733501530
summary:
  error: 0
  fail: 1
  pass: 0
  skip: 0
  warn: 0

Pattern 3: BAD vs GOOD — Privileged Container Prevention

# ❌ BAD — Pod with privileged container that baseline rejects
apiVersion: v1
kind: Pod
metadata:
  name: bad-privileged-pod
  namespace: production-apps
spec:
  containers:
    - name: app
      image: nginx:latest
      securityContext:
        privileged: true           # baseline blocks this
        allowPrivilegeEscalation: true  # baseline blocks this
---
# ✅ GOOD — Pod that passes baseline enforcement
apiVersion: v1
kind: Pod
metadata:
  name: good-hardened-pod
  namespace: production-apps
spec:
  containers:
    - name: app
      image: nginx:latest
      securityContext:
        privileged: false
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true

---

Constraints

MUST DO

• Always include exclude rules for kube-system, kube-public, and kube-node-lease to avoid blocking cluster operations
• Set all three enforcement modes (enforce, audit, warn) to progressively tighten security over time
• Use version: latest to stay current with Kubernetes PSS version updates
• Verify PolicyReport shows results for each namespace to confirm enforcement is active
• Use podSecurity rule type rather than validate — it is purpose-built for PSS and handles versioning

MUST NOT DO

• Apply baseline enforcement to kube-system without an exemption strategy — it breaks DNS, metrics, and system pods
• Use enforce mode without first testing in audit or warn mode — this will block existing deployments
• Omit the exclude block — without it, system components will be blocked and the cluster will become unusable
• Set version to a specific minor version without correlating to your cluster's Kubernetes version
• Skip warn mode — audit-only enforcement produces no immediate feedback for developers

---

Related Skills

Skill	Purpose
kyverno-pod-security-restricted	For stricter hardening when baseline is insufficient
kyverno-exemptions-management	For managing namespace exemptions when baseline blocks valid system workloads

---

Live References

Authoritative documentation links for Kyverno pod security policies.

• Kyverno Documentation
• Kyverno CLI
• Kyverno Policies
• Kyverno GitHub
• Kyverno Installation
• Policy Report Schema
• Pod Security Standards
• Kyverno podSecurity Rule