Pod security admission controller in Kubernetes - Step-by-Step Execution

Process Flow - Pod security admission controller

Pod Creation Request

↓

Admission Controller Intercepts

↓

Check Pod Security Policy

↓

Allow

↓

Pod Created or Denied

When a pod is created, the admission controller checks its security settings. It either allows, warns, or denies the pod based on policy.

Execution Sample

Kubernetes

kubectl apply -f pod.yaml
# Pod creation intercepted
# Pod security admission controller checks policy
# Pod allowed or denied based on policy

This simulates creating a pod and how the admission controller checks its security before allowing creation.

Process Table

Step	Action	Pod Security Check	Result	Effect
1	Pod creation request received	N/A	Intercepted	Admission controller activated
2	Check pod against policy	Pod spec matches 'restricted' profile	Pass	Pod allowed
3	Pod creation proceeds	N/A	Success	Pod created in cluster
4	End	N/A	No further checks	Process complete

💡 Pod matches security policy, so creation is allowed and completes successfully

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
pod_creation_status	Not started	Intercepted	Allowed	Created	Created
security_check_result	None	Pending	Pass	N/A	Pass

Key Moments - 3 Insights

Why does the pod creation get intercepted before it is created?

The admission controller intercepts all pod creation requests to enforce security policies, as shown in execution_table step 1.

What happens if the pod does not meet the security policy?

If the pod fails the security check, it would be rejected and not created. This is implied by the 'Fail' branch in the concept_flow.

Why is there a 'warn' option in the policy check?

The 'warn' option allows the pod creation but logs a warning for administrators, helping them notice potential issues without blocking pods, as shown in concept_flow.

Visual Quiz - 3 Questions

Look at the execution_table, what is the pod_creation_status after step 2?

A Intercepted

B Allowed

C Created

D Rejected

💡 Hint

Check the variable_tracker row for pod_creation_status after step 2

At which step does the pod get created in the cluster?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at execution_table 'Effect' column for when pod creation completes

If the pod failed the security check, what would happen according to the concept_flow?

A Pod creation is rejected

B Pod creation is allowed with a warning

C Pod creation proceeds normally

D Pod creation is delayed

💡 Hint

Refer to the 'Fail' branch in the concept_flow diagram

Concept Snapshot

Pod Security Admission Controller intercepts pod creation requests.
It checks pods against security policies.
Pods can be allowed, warned, or rejected.
Allows enforcing cluster security automatically.
Configured via Kubernetes admission controllers.

Full Transcript

When you create a pod in Kubernetes, the Pod Security Admission Controller steps in before the pod is actually created. It checks the pod's security settings against predefined policies. If the pod meets the policy, it is allowed and created. If it only partially meets the policy, it may be allowed but with a warning logged. If it fails the policy, the pod creation is rejected. This process helps keep the cluster secure by enforcing rules automatically on every pod creation request.

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