Configuring Pod Security Admission for Kubernetes

Configuring Pod Security Admission for Kubernetes

Your Kubernetes cluster is running, pods are starting, but pod security often remains a blind spot. One wrong privilege in the manifest — and container compromise opens access to the node. For example, during an audit on one project, we discovered that 30% of pods in production had allowPrivilegeEscalation: true — a direct path to node compromise. Pod Security Admission (PSA) solves this at the namespace level without external webhooks. According to official documentation, PSA is the recommended mechanism for pod security. Our engineers have configured PSA on clusters ranging from 10 to 500 nodes with over 5 years of experience. We will assess your cluster in one day, select profiles, and adapt manifests without stopping workloads. Order a security audit of your cluster.

Three Policy Levels — Pod Security Configuration

PSA defines three security profiles. Compare them in the table:

Three Enforcement Modes

For each profile, you can set a mode via namespace labels. Compare the modes:

kubectl label namespace production \
  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

This combination is useful: enforce baseline (block obviously dangerous), audit + warn restricted (see what needs fixing for a transition to restricted, but without breaking workloads).

How to Implement PSA Without Pod Downtime?

Start with audit mode on all namespaces — no workloads are affected, but the audit log shows everything violating the target profile. Implementation steps:

1. Set audit and warn modes on all namespaces.
2. Analyze violations via kubectl get events and kube-apiserver audit logs.
3. Fix application manifests: add securityContext, seccompProfile, drop root.
4. Switch namespaces to enforce one by one, starting with the least critical.

Timeline: 1 day for basic configuration, 2–3 days if application manifests need adaptation to Restricted profile. Our engineers guarantee that no pod will be stopped during the process. Get a consultation on PSA implementation.

Typical Violations When Moving to Restricted

Most standard Helm charts will not pass Restricted without adaptation. Statistics from over 30 projects show that about 90% of violations fall into three categories:

• runAsNonRoot: true is not set. Dockerfile must have USER 1000 or securityContext.runAsUser explicitly set and not equal to 0.
• No seccompProfile. In recent Kubernetes versions, RuntimeDefault is available on most nodes, but must be explicitly specified in the manifest:

securityContext:
  seccompProfile:
    type: RuntimeDefault
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL

• Old images with built-in root processes. The official Nginx image before version 1.24 requires root to run on port 80. Alternative: nginxinc/nginx-unprivileged with port 8080.
• System DaemonSets. Calico, Cilium, Fluentd, node-exporter often require hostNetwork, hostPID, or privileges. Their namespaces should remain at Privileged or Baseline — they are not user workloads.

Advantages of PSA Over PodSecurityPolicy

PSA is a built-in mechanism, does not require external resources, and is managed with simple namespace labels. Unlike PSP, PSA does not block namespaces completely but allows combining modes. According to our projects, PSA implementation is 3 times faster than configuring PSP via webhooks, and reduces security incidents by 60% (from an average of 5 to 2 per quarter).

Exemptions at the Namespace Level

PSA does not support exemptions at the individual Pod level within a namespace — only at the namespace level. Therefore, system components must be in separate namespaces with the appropriate policy level. kube-system is completely excluded from PSA by default. To add exemptions for specific namespaces in admission configuration:

---
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
        audit: restricted
        warn: restricted
      exemptions:
        namespaces:
          - kube-system
          - calico-system
          - monitoring
---

Why Choose the Restricted Profile?

The Restricted profile provides maximum protection against pod compromise. If your application can run without root and with limited permissions, Restricted is the right choice. It aligns with container security best practices and is recommended for production environments. Our engineers will help adapt manifests to Restricted without losing functionality. Contact us to discuss details.

What's Included in Turnkey PSA Setup

We offer a comprehensive approach that includes:

• Audit of current namespaces and violation detection
• Label configuration with optimal enforce/audit/warn combination
• Adaptation of application manifests to selected profiles
• Testing in a sandbox environment
• Documentation and team training
• Security guarantee — no running pods are stopped during implementation

Our clients save an average of 40% of incident response time after PSA implementation. Setup cost is calculated individually depending on cluster size, but starts at $500 for a basic audit and $2,000 for full implementation (clusters up to 50 nodes). Typically, this investment is recovered through risk reduction — one prevented security incident can save $10,000 or more. Order a security audit of your cluster to get started.