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.