Ready to supercharge your AI agents?

Install any skill in seconds. Free to start, no credit card required.

Implementing Pod Security Admission Controller · mukul975 | DecimalAI

Implementing Pod Security Admission Controller

NewSkillScoreMaintained

implementing-pod-security-admission-controller

Implement Kubernetes Pod Security Admission to enforce baseline and restricted security profiles at namespace level using built-in admission controller.

DevOpsby mukul975

Links this skill to your agents and keeps it current with the author’s updates.

Automatic

DevOps & SRE pack

1 · One-time — install the CLI (docs ↗)

pip install decimalai

2 · Get the skill — writes .claude/skills/implementing-pod-security-admission-controller/SKILL.md

decimalai skills pull implementing-pod-security-admission-controller --out .claude/skills/

No CLI? Get the same file — curl · raw file

curl -fsSL --create-dirs -o .claude/skills/implementing-pod-security-admission-controller/SKILL.md https://app.decimal.ai/s/implementing-pod-security-admission-controller/SKILL.md

Raw file: /s/implementing-pod-security-admission-controller/SKILL.md ↗ · machine-readable summary at /s/implementing-pod-security-admission-controller.json ↗

In productionGlobal

how this skill behaves on real traffic · last 30 days

No production data for this skill yet — usage numbers appear here once agents start running it.

Anonymized aggregate across every org using this skill — proof from real production use, not a demo.

Does this skill help? · Benchmark: with vs. withoutsign in to run this on your agents

22 test cases from the publisher’s eval.yaml · each run twice on gemini-3.6-flash — with the skill injected, then without · last run 23d ago

No measurable change+90% tokens0% turns82% of whole cases pass with skill (18/22)

Test case	Without → With	Effect	Δ tokens	Δ turns
case-01	✓→✓	＝ Same ✓	60%	0%
case-04	✓→✓	＝ Same ✓	128%	0%
case-05	✓→✓	＝ Same ✓	140%	0%
case-06	✓→✓	＝ Same ✓	217%	0%
case-07	✓→✓	＝ Same ✓	60%	0%

Showing 5 of 22 cases

SkillSafety

✓ 3 of 3 passed

Code scan15 of 15 checks clean

0 critical · 0 warning · 0 info — scanner v5 — 8/30/2026

live_secretremote_code_executionreverse_shelldata_exfiltrationssrf_metadataagent_snoopinganti_refusaldestructive_commandsobfuscated_unicodeunicode_homoglyphopaque_blobsuspicious_urltool_overreachtrigger_abuseprompt_injection_phrasing

IntentSafe

LLM judge · does the skill do what it claims

ContentClean

LLM judge · policy & harmful-content review

Source

Imported

mukul975 / Anthropic-Cybersecurity-Skills

skills/implementing-pod-security-admission-controller/SKILL.md

View on GitHub ↗

License Apache-2.0Imported 8/30/2026Version v2Bundled 12 files · scripts

Skill contents

scripts/

references/

assets/

SKILL.md

Implementing Pod Security Admission Controller

Overview

Pod Security Admission (PSA) is a built-in Kubernetes admission controller (stable since v1.25) that enforces Pod Security Standards at the namespace level. It replaces the deprecated PodSecurityPolicy (PSP) and provides three security profiles: Privileged, Baseline, and Restricted, with three enforcement modes: enforce, audit, and warn.

When to Use

Wiring PSA up on a cluster for the first time
Setting cluster-wide default enforcement via AdmissionConfiguration
Exempting system namespaces, service accounts, or runtime classes from enforcement
Debugging why a pod was rejected, or why enforcement is silently not firing
Staging a safe rollout: warn and audit first, enforce once violations reach zero
Pulling PSA violations out of the kube-apiserver audit log

Not this skill: deciding which profile a workload should run under, or what securityContext changes Restricted demands. Use implementing-kubernetes-pod-security-standards.

Prerequisites

Kubernetes v1.25+ (PSA is stable/GA)
kubectl with cluster-admin access
No dependency on external tools - PSA is built into kube-apiserver

Pod Security Standards

Privileged Profile

Unrestricted - No restrictions applied
Use case: System-level pods (kube-system, monitoring)

Baseline Profile

Minimally restrictive - Prevents known privilege escalation
Blocks: privileged containers, hostPID, hostIPC, hostNetwork, hostPorts, certain volume types, adding capabilities beyond runtime defaults

Restricted Profile

Heavily restricted - Follows security best practices
Requires: non-root, drop ALL capabilities, seccomp RuntimeDefault, read-only root filesystem considerations
Blocks: Everything in Baseline plus running as root, privilege escalation, non-approved volume types

Enforcement Modes

| Mode | Behavior | Use Case | |------|----------|----------| | enforce | Reject pods violating policy | Production enforcement | | audit | Log violations to audit log | Pre-enforcement assessment | | warn | Show warnings to user | Developer feedback |

Implementation

Apply to Namespace via Labels

yaml
# Restricted enforcement with audit and warn
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.28
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.28
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.28

yaml
# Baseline enforcement for staging
apiVersion: v1
kind: Namespace
metadata:
  name: staging
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.28
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.28
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.28

yaml
# Privileged for system namespaces
apiVersion: v1
kind: Namespace
metadata:
  name: kube-system
  labels:
    pod-security.kubernetes.io/enforce: privileged

Apply Labels with kubectl

bash
# Set restricted enforcement
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=v1.28 \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

# Set baseline enforcement
kubectl label namespace staging \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

# Check current labels
kubectl get namespace production -o jsonpath='{.metadata.labels}' | jq .

Dry-Run Testing

bash
# Test what would happen with restricted policy on a namespace
kubectl label --dry-run=server --overwrite namespace staging \
  pod-security.kubernetes.io/enforce=restricted

# Output shows existing pods that would violate the policy
# Warning: existing pods in namespace "staging" violate the new PodSecurity enforce level "restricted:latest"

Cluster-Wide Defaults (AdmissionConfiguration)

yaml
# /etc/kubernetes/psa-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: PodSecurity
    configuration:
      apiVersion: pod-security.admission.config.k8s.io/v1
      kind: PodSecurityConfiguration
      defaults:
        enforce: baseline
        enforce-version: latest
        audit: restricted
        audit-version: latest
        warn: restricted
        warn-version: latest
      exemptions:
        usernames: []
        runtimeClasses: []
        namespaces:
          - kube-system
          - kube-public
          - kube-node-lease
          - calico-system
          - gatekeeper-system
          - monitoring
          - falco

Apply to API Server

bash
# Add to kube-apiserver manifests
# /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
  containers:
  - command:
    - kube-apiserver
    - --admission-control-config-file=/etc/kubernetes/psa-config.yaml
    volumeMounts:
    - name: psa-config
      mountPath: /etc/kubernetes/psa-config.yaml
      readOnly: true
  volumes:
  - name: psa-config
    hostPath:
      path: /etc/kubernetes/psa-config.yaml
      type: File

Compliant Pod Examples

Restricted-Compliant Pod

yaml
apiVersion: v1
kind: Pod
metadata:
  name: restricted-pod
  namespace: production
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  automountServiceAccountToken: false
  containers:
    - name: app
      image: myregistry/myapp:v1.0.0
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL
      resources:
        limits:
          cpu: 500m
          memory: 256Mi
        requests:
          cpu: 100m
          memory: 128Mi
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir: {}

Baseline-Compliant Pod

yaml
apiVersion: v1
kind: Pod
metadata:
  name: baseline-pod
  namespace: staging
spec:
  containers:
    - name: app
      image: myregistry/myapp:v1.0.0
      securityContext:
        allowPrivilegeEscalation: false
      resources:
        limits:
          cpu: 500m
          memory: 256Mi

Migration from PodSecurityPolicy

Step 1: Audit Current State

bash
# Check existing PSPs
kubectl get psp

# Check which service accounts use which PSP
kubectl get clusterrolebinding -o json | \
  jq '.items[] | select(.roleRef.name | startswith("psp-")) | {name: .metadata.name, subjects: .subjects}'

Step 2: Map PSP to PSA Profiles

bash
# For each namespace, determine required PSA level
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
  echo "Namespace: $ns"
  kubectl label --dry-run=server namespace $ns \
    pod-security.kubernetes.io/enforce=restricted 2>&1 | head -5
done

Step 3: Apply PSA Labels (Audit First)

bash
# Start with audit mode
kubectl label namespace production \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

Step 4: Review and Fix Violations

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

Step 5: Enable Enforcement

bash
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted

Monitoring

bash
# Check PSA violations in events
kubectl get events --all-namespaces --field-selector reason=FailedCreate

# Check audit logs
kubectl logs -n kube-system kube-apiserver-* | grep "pod-security.kubernetes.io"

# List namespace PSA labels
kubectl get namespaces -L pod-security.kubernetes.io/enforce

Best Practices

Start with audit+warn before enforce to assess impact
Use dry-run to test enforcement before applying
Exempt system namespaces (kube-system, monitoring) in cluster defaults
Pin version (enforce-version) for predictable behavior across upgrades
Set cluster-wide baseline as default, then restrict specific namespaces
Combine with Gatekeeper for additional custom policies beyond PSA
Use restricted profile for all production workloads
Document exemptions with clear justification

Illustrative Want to see what implementing-pod-security-admission-controller would put in front of your model? Preview the rendered body and check its trigger phrases — no LLM call, no signup.

Latest benchmark · publisher runVerified

8/30/2026, 06:09 UTC · 22 cases

Lift

82% vs 82%

Agent turns

1.0 vs 1.0

Tokens

+90%

4,098.36 vs 2,158.45

pass → pass · 18fail → fail · 4

Per-case results (22)

Case	Status	Duration (ms)			Turns			Tokens			Tool calls
Case	Status	Without	With	Δ	Without	With	Δ	Without	With	Δ	Without	With	Δ
case-01 We are preparing a Deployment manifest for a web application and need to modify its container spec `securityContext` to add `seccompProfile` and drop capabilities so it passes Restricted profile checks. Someone suggested configuring this inside the Pod Security Admission controller setup. Show how to modify the container securityContext or direct us to the correct topic.	pass→pass	17,057	13,371	-22%	1	1	0%	2,399	3,834	+60%	0	0	—
case-02 Our application uses hostPath volumes and specific Linux capabilities. We need a detailed evaluation of our application's system calls and volume mounts to decide whether our workload should run under Baseline or Restricted profile. Explain how to evaluate our application code for this profile selection.	fail→fail	30,359	29,053	-4%	1	1	0%	4,494	6,738	+50%	0	0	—
case-03 We want to write an OPA/Gatekeeper Rego constraint and ConstraintTemplate to block hostPath volume mounts across custom CRDs in our cluster. Provide the Rego code and policy definition.	fail→fail	22,843	20,791	-9%	1	1	0%	3,289	5,524	+68%	0	0	—
case-04 Write a Kubernetes Namespace YAML manifest named `staging` that enables baseline enforcement for workloads, but also sets up audit and warn modes at the restricted level to catch upcoming violations, pinning the version to v1.28. Someone suggested using PodSecurityPolicy annotations on the namespace instead.	pass→pass	12,117	9,671	-20%	1	1	0%	1,388	3,165	+128%	0	0	—
case-05 Create a cluster-wide Kubernetes `AdmissionConfiguration` YAML file (`/etc/kubernetes/psa-config.yaml`) for Pod Security Admission. The team wants default enforcement set to baseline, audit and warn set to restricted, and version set to latest. Someone proposed using `ImagePolicyWebhook` as the plugin name.	pass→pass	12,216	11,109	-9%	1	1	0%	1,513	3,624	+140%	0	0	—
case-06 Provide the `kubectl label` command to apply restricted enforcement to the `production` namespace. The operator wants to use Kubernetes API version `v1.28` to guarantee predictable evaluation across cluster upgrades. Someone suggested setting `--overwrite` without specifying `enforce-version`.	pass→pass	9,581	9,455	-1%	1	1	0%	945	2,996	+217%	0	0	—
case-07 Write a bash command loop to evaluate all namespaces across a Kubernetes cluster before migrating from PodSecurityPolicy to Pod Security Admission, testing which namespaces would fail if enforced at restricted level, without making any persistent API changes. An engineer suggested running kubectl apply with a test label.	pass→pass	18,708	12,588	-33%	1	1	0%	2,408	3,843	+60%	0	0	—
case-08 Configure `kube-apiserver` static pod manifest `/etc/kubernetes/manifests/kube-apiserver.yaml` to load a local Pod Security Admission configuration file located at `/etc/kubernetes/psa-config.yaml`. A developer suggested using `--admission-control-config-file` or `--enable-admission-plugins`. Show the exact command-line flag and volume configuration.	pass→pass	14,455	13,123	-9%	1	1	0%	1,999	3,714	+86%	0	0	—
case-09 In a cluster-wide `PodSecurityConfiguration` file, configure system namespaces (`kube-system`, `calico-system`, `monitoring`) so they are not blocked by the cluster default `baseline` enforcement level. A team member suggested putting these under `usernames`.	pass→pass	7,610	13,519	+78%	1	1	0%	1,593	3,919	+146%	0	0	—
case-10 Describe the recommended step-by-step rollout sequence when introducing Pod Security Admission to a production cluster currently running without security admission labels. A colleague suggested applying `enforce=restricted` immediately to all namespaces.	fail→fail	21,510	20,061	-7%	1	1	0%	2,903	5,061	+74%	0	0	—
case-11 Construct a complete Kubernetes Pod manifest named `restricted-pod` for namespace `production` that complies with PSA Restricted profile requirements. Include container security settings, seccomp, non-root user settings, and volume configurations.	pass→pass	17,005	11,838	-30%	1	1	0%	2,620	3,809	+45%	0	0	—
case-12 Provide a Pod manifest for `staging` namespace under Baseline PSA enforcement that prevents privilege escalation while keeping security settings minimal. Someone suggested adding explicit seccomp and readOnlyRootFilesystem which are only required in Restricted.	pass→pass	10,991	5,026	-54%	1	1	0%	1,109	3,159	+185%	0	0	—
case-13 Show the `kubectl` command to query Kubernetes cluster events specifically for Pod creation failures caused by Pod Security Admission enforcement rejections across all namespaces.	pass→pass	13,674	11,474	-16%	1	1	0%	1,582	3,305	+109%	0	0	—
case-14 Show how to extract Pod Security Admission audit log entries from the `kube-apiserver` pod logs in the `kube-system` namespace to investigate policy violations.	pass→pass	19,667	16,437	-16%	1	1	0%	2,708	4,382	+62%	0	0	—
case-15 Write a single `kubectl get namespaces` command that displays the current `enforce` level of every namespace in a clean tabular format using custom column labels.	fail→fail	8,244	5,885	-29%	1	1	0%	1,629	3,178	+95%	0	0	—
case-16 Demonstrate how to dry-run test upgrading a namespace `staging` from `baseline` to `restricted` enforcement when `pod-security.kubernetes.io/enforce` is already present on the namespace.	pass→pass	12,213	12,753	+4%	1	1	0%	2,224	3,682	+66%	0	0	—
case-17 Provide the YAML for the `kube-system` namespace metadata labels to explicitly set PSA enforcement mode to `privileged` so core cluster components are never restricted by default policies.	pass→pass	4,986	3,132	-37%	1	1	0%	964	2,865	+197%	0	0	—
case-18 Explain how to audit existing PodSecurityPolicy bindings prior to replacing PSP with Pod Security Admission, including finding which ClusterRoleBindings reference PSPs.	pass→pass	20,210	18,334	-9%	1	1	0%	3,585	5,905	+65%	0	0	—
case-19 Explain why `pod-security.kubernetes.io/enforce-version` should be set to a specific Kubernetes minor version (e.g., `v1.28`) rather than omitting it or relying solely on `latest` in production namespace labels.	pass→pass	13,143	19,056	+45%	1	1	0%	2,303	4,630	+101%	0	0	—
case-20 A security architect asks whether Pod Security Admission makes Gatekeeper/OPA obsolete in Kubernetes v1.28+. Explain the relationship and recommended operational approach when using both.	pass→pass	15,222	17,303	+14%	1	1	0%	2,597	5,073	+95%	0	0	—
case-21 State the correct `apiVersion` and `kind` for both the top-level admission configuration file and the nested configuration object used for cluster-wide Pod Security Admission.	pass→pass	6,061	9,898	+63%	1	1	0%	945	3,025	+220%	0	0	—
case-22 Compare the operational behavior and target consumer of PSA `audit` mode versus PSA `warn` mode when a pod manifest violates a namespace security profile.	pass→pass	13,379	14,605	+9%	1	1	0%	2,289	4,733	+107%	0	0	—

These cases were also screened by the skill’s intent / safety pass.See the Trust review ↗Reproduce this benchmark in Colab ↗

How this skill was measured

DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of 0 percentage points is the difference between those two pass rates over the 22 comparable cases.

Model measured: gemini-3.6-flash
Graded by: gemini-3.6-flash
Grading method: judged
Verification: verified
Pass rate without the skill: 81.8%
Pass rate with the skill: 81.8%
Cases attempted: 22
Cases counted toward lift: 22
Cases that regressed: 0
Skill version measured: v2
Run completed: 8/30/2026, 06:09 UTC

SkillScore blends 4 signalsno signals yet

BenchmarkRun a verified benchmark with positive lift

Live evalNeeds ≥10 evaluated traces in 30 days

AI ratingNeeds ≥10 rated traces

AdoptionNeeds ≥10 serves across ≥2 orgs in 30 days

Efficiency · separate axis (at equal correctness)+0% turns+98% tokens

Shown for transparency; not credited unless a verified run shows no correctness regression.

No signals yet — run a benchmark or collect evaluated traces to earn a score.

Verified on gemini-3.6-flash · re-tested 22 days ago

Model	Method	Date	Lift
gemini-3.6-flash	verified	7/28/2026	+14%

Other measured skills in the registry, with their headline benchmark lift.

Ready to supercharge your AI agents?

Implementing Pod Security Admission Controller

SkillSafety

Source

Implementing Pod Security Admission Controller

Overview

When to Use

Prerequisites

Pod Security Standards

Privileged Profile

Baseline Profile

Restricted Profile

Enforcement Modes

Implementation

Apply to Namespace via Labels

Apply Labels with kubectl

Dry-Run Testing

Cluster-Wide Defaults (AdmissionConfiguration)

Apply to API Server

Compliant Pod Examples

Restricted-Compliant Pod

Baseline-Compliant Pod

Migration from PodSecurityPolicy

Step 1: Audit Current State

Step 2: Map PSP to PSA Profiles

Step 3: Apply PSA Labels (Audit First)

Step 4: Review and Fix Violations

Step 5: Enable Enforcement

Monitoring

Best Practices

How this skill was measured

Related skills