Pod Security

🛡️ Kubernetes Pod Security: Your Container’s Bodyguard Team

Imagine your Kubernetes cluster is a super-secure castle. Every container is a guest trying to enter. Pod Security is like the team of guards at every gate, making sure only the right guests get in—and they follow the castle rules!

🎯 The Big Picture

When you run apps in Kubernetes, each little box (called a Pod) can do things on your computer—read files, talk to the network, even become super powerful. Pod Security is how we set rules so these boxes can only do what they NEED to do. Nothing more!

Think of it like giving your younger sibling a coloring book. You give them crayons (what they need), but NOT permanent markers (what they don’t need). Same idea here!

🏛️ Pod Security Standards (PSS)

What Are They?

Pod Security Standards are like three levels of strictness for your castle gates:

graph TD
    A["🚨 Privileged"] --> B["Everything Allowed"]
    C["⚠️ Baseline"] --> D["Some Risky Things Blocked"]
    E["✅ Restricted"] --> F["Only Safe Things Allowed"]

The Three Levels

Simple Example

# A Pod that follows "Restricted" rules
apiVersion: v1
kind: Pod
metadata:
  name: safe-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: nginx
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]

Why this matters: If someone hacks your app, they can’t become “king of the computer” because we already limited what the Pod can do!

🚪 Pod Security Admission (PSA)

What Is It?

Pod Security Admission is the actual guard that checks every Pod before letting it in. It looks at your Pod and asks: “Does this follow our rules?”

graph TD
    A["Pod Wants to Start"] --> B{PSA Guard Checks}
    B -->|Follows Rules| C["✅ Pod Starts"]
    B -->|Breaks Rules| D["❌ Pod Rejected"]

Three Actions PSA Can Take

1. Enforce 🛑 — Block the Pod completely
2. Audit 📝 — Let it in, but write it down for review
3. Warn ⚠️ — Let it in, but show a warning message

Simple Example

# Label a namespace to enforce rules
apiVersion: v1
kind: Namespace
metadata:
  name: my-secure-apps
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

What happens: Any Pod in the my-secure-apps namespace MUST follow “restricted” rules or it won’t start!

🎭 Security Contexts

What Are They?

Security Contexts are like ID cards for your containers. They tell Kubernetes:

• Who are you? (which user)
• What can you do? (permissions)
• What can you NOT do? (limits)

Pod-Level vs Container-Level

graph TD
    A["Security Context"] --> B["Pod Level"]
    A --> C["Container Level"]
    B --> D["Applies to ALL containers"]
    C --> E["Applies to ONE container"]

Key Settings

Simple Example

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: app
    image: myapp
    securityContext:
      runAsNonRoot: true
      readOnlyRootFilesystem: true

Why this matters: Even if bad code runs, it can’t mess with important files because it’s just a regular user, not the boss!

🔧 Container Capabilities

What Are They?

Linux has superpowers called capabilities. Instead of being “all-powerful” or “powerless,” you can pick exactly which powers a container gets.

Think of it like a superhero toolkit:

• 🔨 NET_BIND_SERVICE — Can use special network ports
• 🔓 CHOWN — Can change file owners
• ⚡ SYS_ADMIN — Super dangerous! Almost like being root

The Golden Rule

Drop ALL capabilities, then add only what you need!

Simple Example

apiVersion: v1
kind: Pod
metadata:
  name: minimal-powers-pod
spec:
  containers:
  - name: web
    image: nginx
    securityContext:
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE

What this does: The container can’t do ANYTHING special, except bind to port 80/443. That’s exactly what a web server needs—nothing more!

Common Capabilities to Know

🔇 Seccomp Profiles

What Is Seccomp?

Seccomp (Secure Computing Mode) is like a list of allowed phone calls your container can make to the computer’s brain (kernel).

Your container: “Hey computer, I want to read a file!” Seccomp: “Let me check my list… ✅ OK, that’s allowed.”

Your container: “Hey computer, I want to reboot you!” Seccomp: “Let me check… ❌ NOPE! Not on the list!”

graph TD
    A["Container Wants Something"] --> B{Seccomp Filter}
    B -->|On Allowed List| C["✅ Request Granted"]
    B -->|Not Allowed| D["❌ Request Blocked"]

Three Types of Profiles

Simple Example

apiVersion: v1
kind: Pod
metadata:
  name: seccomp-pod
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp

Why this matters: Even if an attacker gets into your container, they can only make “phone calls” that are on the approved list!

🏃 RuntimeClass

What Is It?

RuntimeClass lets you choose different container engines for different workloads. It’s like choosing between different types of cars for different jobs.

graph TD
    A["RuntimeClass"] --> B["gVisor - Extra Sandbox"]
    A --> C["Kata Containers - Mini VMs"]
    A --> D["Default - Normal Containers"]

When Would You Use This?

• Running untrusted code? → Use gVisor or Kata (extra isolation)
• Need maximum performance? → Use default runtime
• Processing sensitive data? → Use a hardened runtime

Simple Example

# First, create a RuntimeClass
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: secure-runtime
handler: runsc  # gVisor handler
---
# Then use it in your Pod
apiVersion: v1
kind: Pod
metadata:
  name: sandboxed-pod
spec:
  runtimeClassName: secure-runtime
  containers:
  - name: untrusted-app
    image: some-app

Why this matters: If you’re running code you don’t fully trust, you can put it in an extra-strong sandbox!

🚨 Admission Controllers

What Are They?

Admission Controllers are like bouncers at a club. When you try to create or change something in Kubernetes, they check if it’s allowed.

graph TD
    A["You: Create Pod"] --> B["API Server"]
    B --> C{Admission Controllers}
    C -->|All Say Yes| D["✅ Pod Created"]
    C -->|One Says No| E["❌ Rejected"]

Two Types

How They Work Together

1. You submit a Pod request
2. Mutating controllers run → might add security defaults
3. Validating controllers run → check if everything is OK
4. If all pass → Pod is created!

🏗️ Built-in Admission Controllers

Kubernetes comes with many admission controllers already installed. Here are the security-related ones:

PodSecurity

The star of the show! Enforces Pod Security Standards.

# Enabled by default in Kubernetes 1.25+
# Configured via namespace labels
pod-security.kubernetes.io/enforce: restricted

LimitRanger

Sets default limits if you forget to add them.

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "256Mi"
    type: Container

ServiceAccount

Automatically mounts service account tokens. Important: You might want to disable this for security!

apiVersion: v1
kind: Pod
spec:
  automountServiceAccountToken: false

NodeRestriction

Stops nodes from modifying things they shouldn’t. Kubelets can only modify their own node’s objects.

AlwaysPullImages

Forces images to be pulled every time (prevents using cached malicious images).

Security-Related Controllers Summary

🎯 Putting It All Together

Here’s a super-secure Pod using everything we learned:

apiVersion: v1
kind: Pod
metadata:
  name: fortress-pod
spec:
  runtimeClassName: secure-runtime
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: secure-app
    image: myapp:latest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL
    resources:
      limits:
        cpu: "500m"
        memory: "128Mi"

🧠 Remember This!

graph TD
    A["Pod Security"] --> B["Standards - The Rules"]
    A --> C["Admission - The Guard"]
    A --> D["Context - The ID Card"]
    A --> E["Capabilities - The Powers"]
    A --> F["Seccomp - The Filter"]
    A --> G["RuntimeClass - The Engine"]
    A --> H["Controllers - The Bouncers"]

The Security Sandwich:

1. 🍞 Standards define WHAT is safe
2. 🥬 Admission checks BEFORE entry
3. 🧀 Context sets WHO can do WHAT
4. 🍅 Capabilities limit SUPERPOWERS
5. 🥓 Seccomp filters SYSTEM CALLS
6. 🍞 RuntimeClass chooses the ENGINE

🚀 You’ve Got This!

You now understand how Kubernetes keeps your containers safe:

• Pod Security Standards = The rulebook (Privileged, Baseline, Restricted)
• Pod Security Admission = The guard checking the rulebook
• Security Contexts = ID cards for containers
• Capabilities = Specific superpowers (drop them all!)
• Seccomp = System call filter
• RuntimeClass = Choose your container engine
• Admission Controllers = Bouncers at every door

Your containers are now as safe as a treasure in a dragon-guarded castle! 🏰🐉

Remember: Security isn’t about making things impossible—it’s about making sure everything only does what it needs to do. Nothing more, nothing less!