Pod security admission controller in Kubernetes - Deep Dive

Overview - Pod security admission controller

What is it?

The Pod Security Admission Controller is a Kubernetes feature that checks pods when they are created or updated to make sure they follow security rules. It helps enforce policies about what pods can and cannot do, like what permissions they have or what settings they use. This controller works automatically inside the Kubernetes system to keep pods safe and compliant. It replaces older methods by providing a simpler, built-in way to secure pods.

Why it matters

Without this controller, pods might run with unsafe settings that could let attackers access sensitive data or control the system. It helps prevent security mistakes by stopping risky pods before they start. This protects the whole cluster and the applications running inside it. Without it, teams would have to rely on complex external tools or manual checks, increasing the chance of errors and breaches.

Where it fits

Before learning about the Pod Security Admission Controller, you should understand basic Kubernetes concepts like pods, namespaces, and admission controllers. After this, you can explore advanced Kubernetes security topics like Network Policies, Role-Based Access Control (RBAC), and Pod Security Policies (legacy). This controller is part of the journey from basic cluster setup to hardened, secure Kubernetes environments.

Mental Model

Core Idea

The Pod Security Admission Controller automatically checks and enforces security rules on pods as they are created or changed to keep the cluster safe.

Think of it like...

It's like a security guard at the entrance of a building who checks everyone's ID and belongings before letting them inside, making sure no one carries anything dangerous.

┌───────────────────────────────┐
│ Kubernetes API Server          │
│                               │
│  ┌─────────────────────────┐  │
│  │ Pod Security Admission  │  │
│  │ Controller              │  │
│  └─────────────┬───────────┘  │
│                │ Checks pod   │
│                ▼             │
│          Pod Creation/Update  │
└───────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is an Admission Controller

Concept: Admission controllers are plugins in Kubernetes that intercept requests to the API server to enforce rules or modify objects before they are saved.

When you create or change something in Kubernetes, like a pod, the API server can run admission controllers. These controllers can accept, reject, or change the request based on policies. They act like gatekeepers to keep the cluster healthy and secure.

Result

Requests to create or update Kubernetes objects are checked and possibly modified or rejected before they take effect.

Understanding admission controllers is key because the Pod Security Admission Controller is one of these gatekeepers that enforce security rules automatically.

2

Foundation

Basics of Pod Security in Kubernetes

Concept: Pods can have security settings that control what they can do, like running as root or accessing the host system.

Pods have settings such as securityContext that define permissions and restrictions. Without controls, pods might run with too many privileges, risking cluster security. Kubernetes needs a way to enforce safe defaults and policies on pods.

Result

Pods have configurable security settings, but without enforcement, unsafe pods can be created.

Knowing pod security basics helps understand why automatic enforcement by admission controllers is necessary to prevent risky configurations.

3

Intermediate

How Pod Security Admission Controller Works

Concept: This controller checks pods against predefined security standards during creation or update and blocks those that don't comply.

The controller uses three policy levels: privileged, baseline, and restricted. Each level defines what pod settings are allowed. When a pod request comes in, the controller compares it to the policy for the namespace and either allows or denies it.

Result

Pods that violate security policies are rejected before they run, ensuring cluster safety.

Understanding the policy levels clarifies how Kubernetes balances security with flexibility for different workloads.

4

Intermediate

Configuring Pod Security Admission Controller Policies

🤔Before reading on: do you think policies are set globally or per namespace? Commit to your answer.

Concept: Policies are applied per namespace using labels that specify the security level and enforcement mode.

You label namespaces with keys like 'pod-security.kubernetes.io/enforce=restricted' to set the policy level. Enforcement modes include enforce (block bad pods), audit (log violations), and warn (show warnings). This lets teams gradually adopt policies.

Result

Namespaces enforce different security levels, and pods are checked accordingly during creation or update.

Knowing that policies are namespace-scoped and support gradual enforcement helps teams adopt security without breaking workloads suddenly.

5

Intermediate

Differences from Legacy Pod Security Policies

🤔Before reading on: do you think Pod Security Admission Controller is more complex or simpler than Pod Security Policies? Commit to your answer.

Concept: Pod Security Admission Controller is a simpler, built-in replacement for the older Pod Security Policies which were complex and hard to maintain.

Pod Security Policies required writing detailed YAML rules and enabling a separate admission controller. The new controller uses simple labels and predefined policy levels, making it easier to use and understand.

Result

Security enforcement is easier to configure and maintain with the new controller compared to legacy policies.

Recognizing the simplification helps understand why Kubernetes moved to this new approach for pod security.

6

Advanced

Handling Exceptions and Custom Policies

🤔Before reading on: do you think the Pod Security Admission Controller supports custom policies? Commit to your answer.

Concept: The built-in controller uses fixed policies, so for custom or complex rules, other tools or admission controllers are needed.

If your security needs go beyond the predefined levels, you can use Open Policy Agent (OPA) Gatekeeper or Kyverno to write custom policies. These tools integrate as admission controllers and allow fine-grained control.

Result

You can enforce advanced security rules beyond the built-in controller by combining it with other admission controllers.

Knowing the limits of the built-in controller prevents overreliance and encourages using complementary tools for complex security needs.

7

Expert

Internal Admission Flow and Performance Impact

🤔Before reading on: do you think enabling Pod Security Admission Controller significantly slows down pod creation? Commit to your answer.

Concept: The controller runs synchronously during pod admission but is optimized to minimize latency and resource use.

When a pod creation request arrives, the API server calls the admission controller which quickly checks labels and pod specs against policy rules. It uses cached data and simple checks to avoid delays. However, complex policies in other controllers can add latency.

Result

Pod creation is slightly delayed by the security check but remains fast enough for production use.

Understanding the internal flow and performance helps balance security enforcement with cluster responsiveness.

Under the Hood

The Pod Security Admission Controller hooks into the Kubernetes API server's admission chain. When a pod creation or update request is received, the controller reads the namespace labels to determine the security policy level and mode. It then inspects the pod's security-related fields, such as securityContext, capabilities, and volume types, comparing them against the policy's allowed settings. If the pod violates the policy in enforce mode, the request is rejected with an error. In audit or warn modes, the request passes but logs or warnings are generated. This process happens synchronously before the pod is persisted.

Why designed this way?

Kubernetes needed a simple, built-in way to enforce pod security without the complexity and maintenance burden of Pod Security Policies. Using namespace labels and fixed policy levels reduces configuration errors and eases adoption. The design balances security enforcement with usability by supporting multiple enforcement modes, allowing gradual policy rollout. Alternatives like custom admission controllers exist but add complexity. This design fits Kubernetes' declarative and label-driven model.

┌───────────────────────────────┐
│ Kubernetes API Server          │
│                               │
│  ┌─────────────────────────┐  │
│  │ Admission Chain          │  │
│  │ ┌─────────────────────┐ │  │
│  │ │ Pod Security Admission│ │  │
│  │ │ Controller           │ │  │
│  │ └─────────┬───────────┘ │  │
│  └───────────│──────────────┘  │
│              │ Reads namespace  │
│              │ labels & pod spec│
│              ▼                │
│      Compares pod to policy   │
│              │                │
│    ┌─────────┴─────────┐      │
│    │ Accept / Reject /  │      │
│    │ Warn / Audit      │      │
│    └───────────────────┘      │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does the Pod Security Admission Controller allow custom security policies? Commit yes or no.

Common Belief: The controller lets you write any custom pod security rules you want.

Reality: It only supports three fixed policy levels (privileged, baseline, restricted) and does not allow custom rules.

Why it matters: Expecting custom policies here can lead to security gaps or confusion; for custom needs, other tools must be used.

Quick: Does labeling a namespace automatically fix existing pods violating the policy? Commit yes or no.

Common Belief: Applying a security label to a namespace immediately secures all pods inside it.

Reality: The controller only checks pods on creation or update; existing pods violating the policy remain until changed or deleted.

Why it matters: Assuming instant enforcement can cause false security confidence and leave vulnerable pods running.

Quick: Does enabling the Pod Security Admission Controller slow down pod creation significantly? Commit yes or no.

Common Belief: This controller causes major delays in pod startup times.

Reality: It performs quick checks with minimal impact; delays are usually negligible compared to other admission controllers.

Why it matters: Overestimating performance impact might discourage enabling this important security feature.

Quick: Is the Pod Security Admission Controller the same as Pod Security Policies? Commit yes or no.

Common Belief: They are the same feature with different names.

Reality: They are different; the admission controller is a newer, simpler replacement for the deprecated Pod Security Policies.

Why it matters: Confusing them can lead to misconfiguration and using outdated methods.

Expert Zone

1

The controller's enforcement modes (enforce, audit, warn) allow gradual policy adoption, which is crucial for large clusters with legacy workloads.

2

Namespace labels control policy application, but pod-level overrides are not supported, requiring careful namespace design.

3

The controller only validates pod specs, so runtime security issues like container escapes require complementary tools.

When NOT to use

Avoid relying solely on this controller when you need fine-grained or custom security policies; instead, use Open Policy Agent Gatekeeper or Kyverno for advanced policy enforcement.

Production Patterns

In production, teams label namespaces with 'baseline' or 'restricted' policies and use 'audit' mode first to identify violations before enforcing. They combine this controller with RBAC and network policies for layered security.

Connections

Open Policy Agent (OPA) Gatekeeper

Builds-on

Understanding the Pod Security Admission Controller clarifies why OPA Gatekeeper is needed for custom, complex policies beyond fixed levels.

Role-Based Access Control (RBAC)

Complementary

Pod security enforcement works best combined with RBAC, which controls who can create or modify pods, adding a layer of access control.

Airport Security Screening

Similar process

Just like airport security checks passengers and luggage against rules before boarding, the controller checks pods against security policies before running.

Common Pitfalls

#1 Assuming the controller fixes existing pods automatically.

Wrong approach:

kubectl label namespace my-namespace pod-security.kubernetes.io/enforce=restricted
# Expect existing pods to be blocked or fixed automatically

Correct approach:

kubectl label namespace my-namespace pod-security.kubernetes.io/enforce=restricted
# Then manually delete or update existing pods to comply

Root cause:

Misunderstanding that the controller only checks pods on creation or update, not retroactively.

#2 Trying to write custom pod security rules using this controller.

Wrong approach:

Creating custom YAML policies for Pod Security Admission Controller to allow specific capabilities

Correct approach:

Use OPA Gatekeeper or Kyverno for custom pod security policies instead

Root cause:

Confusing the built-in fixed policy levels with a fully customizable policy engine.

#3 Not labeling namespaces and expecting cluster-wide enforcement.

Wrong approach:

# No labels set on namespaces
# Expect all pods to be checked by Pod Security Admission Controller

Correct approach:

kubectl label namespace my-namespace pod-security.kubernetes.io/enforce=baseline
# Policies apply only to labeled namespaces

Root cause:

Not knowing that the controller uses namespace labels to decide which policy to apply.

Key Takeaways

The Pod Security Admission Controller is a built-in Kubernetes feature that enforces pod security policies automatically during pod creation or update.

It uses simple namespace labels and three fixed policy levels to balance security and usability without complex configuration.

This controller only checks pods when they are created or changed; it does not affect existing pods until they are updated or restarted.

For custom or advanced security policies, additional tools like OPA Gatekeeper or Kyverno are necessary.

Combining this controller with other Kubernetes security features like RBAC and network policies creates a strong, layered defense.

Practice

1. What is the primary purpose of the Pod Security Admission Controller in Kubernetes?

easy

A. To monitor pod resource usage

B. To manage network traffic between pods

C. To schedule pods on specific nodes

D. To enforce security policies on pods based on predefined security levels

Solution

1. Step 1: Understand the role of Pod Security Admission Controller

   This controller enforces security policies on pods to ensure they meet security standards.

2. Step 2: Differentiate from other controllers

   It does not manage networking, scheduling, or resource monitoring, which are handled by other components.

3. Final Answer:

   To enforce security policies on pods based on predefined security levels -> Option D

4. Quick Check:

   Pod Security Admission = Enforce security policies [OK]

Hint: Remember: Pod Security Admission controls pod security levels [OK]

Common Mistakes:

• Confusing it with network or scheduling controllers
• Thinking it monitors resource usage
• Assuming it manages pod lifecycle

2. Which of the following is the correct way to specify the enforce mode for the Pod Security Admission Controller in a Kubernetes API server configuration?

easy

A. --enable-admission-plugins=PodSecurity --pod-security-enforce=audit

B. --enable-admission-plugins=PodSecurity --pod-security-mode=enforce

C. --enable-admission-plugins=PodSecurity --pod-security-enforce=restricted

D. --admission-control=PodSecurity --pod-security-enforce=baseline

Solution

1. Step 1: Identify correct flag names for Pod Security Admission

   The correct flags are --enable-admission-plugins=PodSecurity and --pod-security-enforce=LEVEL where LEVEL is one of privileged, baseline, or restricted.

2. Step 2: Verify option syntax and values

   --enable-admission-plugins=PodSecurity --pod-security-enforce=restricted: --enable-admission-plugins=PodSecurity --pod-security-enforce=restricted uses correct flag names and a valid security level 'restricted'. Options A uses invalid level, B uses incorrect flag --pod-security-mode, and C uses deprecated --admission-control.

3. Final Answer:

   --enable-admission-plugins=PodSecurity --pod-security-enforce=restricted -> Option C

4. Quick Check:

   Correct flags + valid level = --enable-admission-plugins=PodSecurity --pod-security-enforce=restricted [OK]

Hint: Look for exact flag names and valid security levels [OK]

Common Mistakes:

• Using wrong flag names like --admission-control
• Confusing enforce mode with audit or warn
• Using invalid security levels

3. Given this Pod Security Admission configuration snippet:

apiVersion: policy/v1
kind: PodSecurity
metadata:
  name: enforce-baseline
spec:
  enforce:
    level: baseline
    version: "latest"
  warn:
    level: restricted
    version: "latest"
  audit:
    level: privileged
    version: "latest"

What will happen if a pod with privileged permissions is created?

medium

A. The pod creation will be blocked due to enforcement at baseline level

B. The pod creation will succeed but a warning will be logged

C. The pod creation will succeed without any warnings or audits

D. The pod creation will be audited but allowed

Solution

1. Step 1: Understand enforcement level

   The enforce level is set to baseline, which blocks pods that do not meet baseline security standards, including privileged pods.

2. Step 2: Analyze pod permissions against levels

   Privileged pods exceed baseline restrictions, so enforcement blocks creation. Warnings and audits apply to lower levels but enforcement is strictest.

3. Final Answer:

   The pod creation will be blocked due to enforcement at baseline level -> Option A

4. Quick Check:

   Enforce baseline blocks privileged pods [OK]

Hint: Enforce blocks pods below level; privileged > baseline [OK]

Common Mistakes:

• Confusing warn or audit with enforce
• Assuming privileged pods pass baseline enforcement
• Ignoring enforcement priority over warnings

4. You configured the Pod Security Admission Controller with --pod-security-enforce=restricted, but pods with privileged containers are still being created. What is the most likely cause?

medium

A. The pods are created in namespaces labeled to exempt enforcement

B. The admission controller is not enabled in the API server

C. The pod spec has incorrect securityContext fields

D. The Kubernetes version does not support Pod Security Admission Controller

Solution

1. Step 1: Check admission controller enablement

   If the controller was not enabled, no enforcement would occur cluster-wide, but the question implies partial enforcement.

2. Step 2: Understand namespace labels impact

   Namespaces can be labeled to exempt or relax enforcement, allowing privileged pods despite cluster-wide settings.

3. Step 3: Consider other options

   Incorrect pod specs or Kubernetes version issues would cause errors or no enforcement at all, not selective allowance.

4. Final Answer:

   The pods are created in namespaces labeled to exempt enforcement -> Option A

5. Quick Check:

   Namespace labels can exempt enforcement [OK]

Hint: Check namespace labels for enforcement exemptions [OK]

Common Mistakes:

• Assuming controller is disabled without checking labels
• Ignoring namespace-level exemptions
• Blaming pod spec errors for enforcement bypass

5. You want to enforce the Pod Security Admission Controller to block all pods that request hostPath volumes except in a specific namespace called trusted. How should you configure this?

hard

A. Set cluster-wide enforcement to restricted and label the trusted namespace with pod-security.kubernetes.io/enforce: baseline

B. Set cluster-wide enforcement to restricted and label the trusted namespace with pod-security.kubernetes.io/enforce: privileged

C. Set cluster-wide enforcement to baseline and label the trusted namespace with pod-security.kubernetes.io/enforce: baseline

D. Set cluster-wide enforcement to privileged and label the trusted namespace with pod-security.kubernetes.io/enforce: restricted

Solution

1. Step 1: Understand security levels and hostPath restrictions

   The restricted level blocks hostPath volumes, while privileged allows them.

2. Step 2: Apply cluster-wide enforcement and namespace override

   Set cluster-wide enforcement to restricted to block hostPath everywhere by default. Label the trusted namespace with pod-security.kubernetes.io/enforce: privileged to allow exceptions.

3. Step 3: Verify option correctness

   Set cluster-wide enforcement to restricted and label the trusted namespace with pod-security.kubernetes.io/enforce: privileged correctly sets cluster-wide to restricted and trusted namespace to privileged, allowing hostPath only there.

4. Final Answer:

   Set cluster-wide enforcement to restricted and label the trusted namespace with pod-security.kubernetes.io/enforce: privileged -> Option B

5. Quick Check:

   Cluster restricted + trusted privileged = hostPath allowed only in trusted [OK]

Hint: Cluster restrict + namespace privileged allows exceptions [OK]

Common Mistakes:

• Setting cluster enforcement too low to block hostPath
• Using baseline instead of privileged for exceptions
• Labeling trusted namespace with a stricter level