Pod security standards in Kubernetes - Deep Dive

Overview - Pod security standards

What is it?

Pod security standards are a set of rules in Kubernetes that control what security settings pods can use. They help ensure pods run safely by restricting risky actions like running as root or using privileged containers. These standards are grouped into levels like 'privileged', 'baseline', and 'restricted' to match different security needs. They make it easier to protect your cluster from unsafe pod configurations.

Why it matters

Without pod security standards, anyone could create pods that might harm the cluster or leak data by running with too many permissions. This could lead to security breaches or unstable systems. Pod security standards provide a clear, easy way to enforce safe pod settings automatically, protecting your applications and infrastructure. They help teams avoid costly mistakes and keep Kubernetes environments secure.

Where it fits

Before learning pod security standards, you should understand basic Kubernetes concepts like pods, containers, and namespaces. After this, you can explore advanced security topics like Pod Security Policies (deprecated), admission controllers, and Kubernetes RBAC. This topic fits into the security layer of Kubernetes cluster management.

Mental Model

Core Idea

Pod security standards are predefined security rule sets that control what pods are allowed to do, ensuring safe and consistent pod behavior in Kubernetes clusters.

Think of it like...

It's like setting house rules for guests: some guests can do anything (privileged), some have basic freedoms (baseline), and some have strict limits (restricted) to keep the house safe and orderly.

┌───────────────────────────────┐
│        Pod Security Levels     │
├─────────────┬─────────┬───────────┤
│ Privileged  │ Baseline│ Restricted│
├─────────────┼─────────┼───────────┤
│ Most access │ Moderate│ Least     │
│ Full root   │ Limited │ No root   │
│ Privileged  │ Controls│ Strict    │
│ containers  │ on risky│ rules     │
│             │ actions │           │
└─────────────┴─────────┴───────────┘

Build-Up - 7 Steps

1

Foundation

What are Pods in Kubernetes

Concept: Introduce the basic unit of deployment in Kubernetes: the pod.

A pod is the smallest unit you can deploy in Kubernetes. It usually contains one or more containers that share storage and network. Pods run your applications inside the cluster.

Result

You understand that pods are the building blocks where your app containers run.

Knowing what pods are is essential because pod security standards apply directly to these units.

2

Foundation

Why Pod Security Matters

Concept: Explain the risks of running pods without security controls.

Pods can run with powerful permissions like root user or privileged mode. If misused, this can let attackers escape containers or access sensitive data. Security standards help prevent these risks by limiting what pods can do.

Result

You see why controlling pod permissions is critical for cluster safety.

Understanding the risks motivates why Kubernetes enforces pod security standards.

3

Intermediate

Pod Security Standard Levels Explained

🤔Before reading on: do you think 'restricted' level allows pods to run as root? Commit to your answer.

Concept: Learn the three main pod security levels: privileged, baseline, and restricted.

Privileged level allows almost all actions, including running as root and privileged containers. Baseline blocks known risky actions but allows common use cases. Restricted is the strictest, blocking root and privileged containers to maximize security.

Result

You can identify which security level fits your cluster needs.

Knowing these levels helps you choose the right balance between security and functionality.

4

Intermediate

How Pod Security Standards Enforce Rules

🤔Before reading on: do you think pod security standards are enforced by default in Kubernetes? Commit to your answer.

Concept: Understand that pod security standards are enforced by admission controllers that check pods when created or updated.

Kubernetes uses a Pod Security admission controller that checks pod specs against the chosen security level for a namespace. If a pod breaks the rules, it is rejected. This happens automatically when you enable the controller.

Result

You know how pod security standards actively prevent unsafe pods from running.

Understanding enforcement helps you realize how security is automated and consistent.

5

Intermediate

Configuring Pod Security Standards in Namespaces

Concept: Learn how to apply pod security standards to namespaces using labels.

You apply pod security standards by adding labels to namespaces like 'pod-security.kubernetes.io/enforce=restricted'. This tells Kubernetes which level to enforce for pods in that namespace. You can also audit or warn before enforcing.

Result

You can control pod security per namespace to fit different team needs.

Knowing namespace-level control allows flexible security policies across your cluster.

6

Advanced

Differences Between Pod Security Standards and Pod Security Policies

🤔Before reading on: do you think Pod Security Policies are still recommended for new Kubernetes clusters? Commit to your answer.

Concept: Compare the new pod security standards with the older Pod Security Policies (PSP).

Pod Security Policies were complex and hard to maintain, so Kubernetes deprecated them. Pod Security Standards are simpler, label-based, and easier to use. They cover common security needs without custom policy writing.

Result

You understand why pod security standards replaced PSP and when to use each.

Knowing this history helps avoid legacy tools and adopt modern best practices.

7

Expert

Customizing Pod Security Beyond Standards

🤔Before reading on: do you think pod security standards cover every possible security scenario? Commit to your answer.

Concept: Explore how to extend pod security with custom admission controllers or OPA Gatekeeper for complex policies.

Pod security standards cover common cases but not all. For advanced needs like custom labels or network policies, you can use tools like Open Policy Agent Gatekeeper or build your own admission controllers. These work alongside pod security standards.

Result

You know how to handle complex security requirements beyond built-in standards.

Understanding extension options prepares you for real-world cluster security challenges.

Under the Hood

Pod security standards work through the Pod Security admission controller in Kubernetes. When a pod is created or updated, this controller intercepts the request and checks the pod's security settings against the rules of the assigned security level for its namespace. If the pod violates any rule, the controller rejects the request with an error. This process happens before the pod runs, ensuring only compliant pods start.

Why designed this way?

Pod Security Standards were designed to replace the complex and hard-to-manage Pod Security Policies. The label-based approach simplifies enforcement by using namespace labels and built-in admission controllers, reducing configuration overhead and improving usability. This design balances security with ease of use, encouraging adoption and consistent security across clusters.

┌───────────────────────────────┐
│  Kubernetes API Server        │
│  ┌─────────────────────────┐  │
│  │ Pod Security Admission  │  │
│  │ Controller              │  │
│  └─────────────┬───────────┘  │
│                │ Checks pod specs
│                │ against rules
│  ┌─────────────▼───────────┐  │
│  │ Pod Creation Request     │  │
│  │ Accepted or Rejected    │  │
│  └─────────────────────────┘  │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think 'restricted' level allows pods to run as root? Commit yes or no.

Common Belief: Restricted level still allows pods to run as root if needed.

Reality: Restricted level explicitly forbids running pods as root or privileged containers.

Why it matters: Allowing root in restricted mode defeats the purpose and can lead to serious security breaches.

Quick: Are pod security standards enabled by default in all Kubernetes clusters? Commit yes or no.

Common Belief: Pod security standards are always active by default in Kubernetes.

Reality: Pod security standards must be explicitly enabled and configured; they are not active by default.

Why it matters: Assuming they are active can give a false sense of security and leave clusters vulnerable.

Quick: Do you think Pod Security Policies and Pod Security Standards are the same? Commit yes or no.

Common Belief: Pod Security Policies and Pod Security Standards are interchangeable and equally recommended.

Reality: Pod Security Policies are deprecated and replaced by Pod Security Standards, which are simpler and preferred.

Why it matters: Using PSP in new clusters wastes effort and risks future incompatibility.

Quick: Can pod security standards enforce network policies? Commit yes or no.

Common Belief: Pod security standards control all pod security aspects including network policies.

Reality: Pod security standards focus on pod-level security settings; network policies are managed separately.

Why it matters: Confusing these can lead to incomplete security coverage and gaps in cluster protection.

Expert Zone

1

Pod security standards use a label-based approach that allows gradual rollout with 'audit' and 'warn' modes before enforcement.

2

The baseline level is designed to allow most common workloads while blocking only known risky actions, balancing usability and security.

3

Pod security standards do not replace all security controls; they work best combined with RBAC, network policies, and runtime security tools.

When NOT to use

Pod security standards are not suitable when you need highly customized or complex security policies beyond their scope. In such cases, use Open Policy Agent Gatekeeper or custom admission controllers for fine-grained control.

Production Patterns

In production, teams often apply 'restricted' level to sensitive namespaces like production, 'baseline' to development, and 'privileged' only to trusted system namespaces. They use 'audit' mode first to detect violations before enforcing policies cluster-wide.

Connections

Admission Controllers

Pod security standards are implemented as a type of admission controller in Kubernetes.

Understanding admission controllers helps grasp how Kubernetes enforces policies dynamically during pod creation.

Role-Based Access Control (RBAC)

Pod security standards complement RBAC by controlling pod permissions while RBAC controls user permissions.

Knowing both helps secure who can create pods and what those pods are allowed to do.

Operating System Mandatory Access Control (MAC)

Pod security standards conceptually resemble OS MAC systems that restrict program capabilities.

Recognizing this connection shows how layered security principles apply from OS to container orchestration.

Common Pitfalls

#1 Assuming pod security standards automatically protect all namespaces without configuration.

Wrong approach:

kubectl create namespace dev
# No labels set, pod security standards not enforced

Correct approach:

kubectl create namespace dev
kubectl label namespace dev pod-security.kubernetes.io/enforce=baseline

Root cause:

Misunderstanding that pod security standards require explicit namespace labeling to activate enforcement.

#2 Trying to run privileged containers in a namespace labeled with 'restricted' enforcement.

Wrong approach:

apiVersion: v1
kind: Pod
spec:
containers:
- name: app
image: nginx
securityContext:
privileged: true

Correct approach:

Use 'baseline' or 'privileged' enforcement level for namespaces where privileged containers are needed.

Root cause:

Not matching pod security level to pod requirements causes pod creation failures.

#3 Continuing to use Pod Security Policies in new Kubernetes clusters.

Wrong approach:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: example-psp

Correct approach:

Use Pod Security Standards with namespace labels and admission controller instead.

Root cause:

Not updating to current Kubernetes security best practices leads to deprecated and unsupported configurations.

Key Takeaways

Pod security standards are built-in Kubernetes rules that control pod permissions to keep clusters safe.

They use three levels—privileged, baseline, and restricted—to balance security and usability.

Enforcement happens via an admission controller that checks pods against namespace labels before they run.

Pod security standards replaced the older Pod Security Policies for simpler, more effective security management.

For complex needs, pod security standards can be extended with custom policies using tools like Open Policy Agent.

Practice

1. What is the main purpose of Kubernetes Pod Security Standards?

easy

A. To control pod permissions and prevent risky behaviors

B. To increase pod resource limits automatically

C. To schedule pods on specific nodes

D. To monitor pod network traffic

Solution

1. Step 1: Understand Pod Security Standards

   Pod Security Standards define rules to restrict pod permissions and behaviors.

2. Step 2: Identify the main goal

   The goal is to prevent risky pod behaviors like running as root or privileged mode.

3. Final Answer:

   To control pod permissions and prevent risky behaviors -> Option A

4. Quick Check:

   Pod Security Standards = Control permissions [OK]

Hint: Pod Security Standards limit pod permissions to keep cluster safe [OK]

Common Mistakes:

• Confusing security standards with resource management
• Thinking it schedules pods on nodes
• Assuming it monitors network traffic

2. Which of the following is the correct way to label a namespace to enforce the 'restricted' Pod Security Standard in Kubernetes?

easy

A. kubectl set security namespace myns restricted

B. kubectl label pod mypod pod-security.kubernetes.io/enforce=restricted

C. kubectl annotate namespace myns pod-security.kubernetes.io/enforce=restricted

D. kubectl label namespace myns pod-security.kubernetes.io/enforce=restricted

Solution

1. Step 1: Identify correct resource and command

   Pod Security Standards are enforced by labeling namespaces, not pods.

2. Step 2: Check correct syntax for labeling namespace

   The correct command is 'kubectl label namespace <name> pod-security.kubernetes.io/enforce=restricted'.

3. Final Answer:

   kubectl label namespace myns pod-security.kubernetes.io/enforce=restricted -> Option D

4. Quick Check:

   Label namespace with enforce=restricted [OK]

Hint: Label namespaces, not pods, to enforce Pod Security Standards [OK]

Common Mistakes:

• Labeling pods instead of namespaces
• Using annotate instead of label
• Using invalid kubectl commands

3. Given this pod spec snippet, which Pod Security Standard will it most likely violate?

{
  "securityContext": {
    "runAsUser": 0,
    "privileged": true
  }
}

medium

A. Baseline

B. Restricted

C. Privileged

D. None

Solution

1. Step 1: Analyze pod securityContext

   The pod runs as user 0 (root) and uses privileged mode, which is risky.

2. Step 2: Match with Pod Security Standards

   Restricted standard forbids running as root and privileged mode, so this pod violates Restricted.

3. Final Answer:

   Restricted -> Option B

4. Quick Check:

   Root + privileged = violates Restricted [OK]

Hint: Root user and privileged mode break Restricted standard [OK]

Common Mistakes:

• Confusing Baseline and Restricted standards
• Thinking privileged mode is allowed in Restricted
• Assuming no violation if pod runs as root

4. You labeled a namespace with pod-security.kubernetes.io/enforce=restricted, but pods running as root are still allowed. What is the most likely reason?

medium

A. The Pod Security Admission controller is not enabled in the cluster

B. The label was applied to the pod instead of the namespace

C. The pod spec is missing the securityContext field

D. The namespace label should be 'pod-security.kubernetes.io/warn=restricted'

Solution

1. Step 1: Understand enforcement mechanism

   Pod Security Standards enforcement requires the Pod Security Admission controller enabled in the cluster.

2. Step 2: Check other options

   Labeling pod instead of namespace or missing securityContext won't bypass enforcement if controller is active. Warning label only warns, does not enforce.

3. Final Answer:

   The Pod Security Admission controller is not enabled in the cluster -> Option A

4. Quick Check:

   Admission controller must be enabled for enforcement [OK]

Hint: Enforcement needs admission controller enabled [OK]

Common Mistakes:

• Applying label to pod instead of namespace
• Confusing warn label with enforce label
• Assuming missing securityContext disables enforcement

5. You want to enforce the 'baseline' Pod Security Standard but allow some pods to run as root for legacy reasons. Which approach best balances security and flexibility?

hard

A. Disable Pod Security Admission controller and manually review pods

B. Label the namespace with 'pod-security.kubernetes.io/enforce=restricted' and remove root user from all pods

C. Label the namespace with 'pod-security.kubernetes.io/enforce=baseline' and use Pod Security Exceptions for specific pods

D. Label each pod with 'pod-security.kubernetes.io/enforce=baseline' individually

Solution

1. Step 1: Understand baseline enforcement with exceptions

   Baseline standard is less strict than restricted and allows some flexibility.

2. Step 2: Use exceptions for legacy pods

   Pod Security Exceptions allow specific pods to bypass some rules while enforcing baseline on the namespace.

3. Step 3: Evaluate other options

   Restricted is stricter, disabling admission controller removes security, labeling pods individually is not standard practice.

4. Final Answer:

   Label the namespace with 'pod-security.kubernetes.io/enforce=baseline' and use Pod Security Exceptions for specific pods -> Option C

5. Quick Check:

   Baseline + exceptions = balance security and legacy needs [OK]

Hint: Use baseline label plus exceptions for legacy pods [OK]

Common Mistakes:

• Using restricted standard which is too strict
• Disabling admission controller reduces security
• Labeling pods individually instead of namespace