Lesson 01 — Pod Security Standards (PSS)

Learning Objectives

By the end of this lesson, you will be able to:

Understand why Pod Security Standards (PSS) exist
Learn the three Pod Security Standards profiles
Understand how Pod Security Admission enforces PSS
Learn how PSS protects Kubernetes workloads
Identify insecure Pod configurations
Implement PSS in Amazon EKS
Apply enterprise workload security best practices

Why This Matters

Containers are the foundation of Kubernetes.

Every application you deploy ultimately runs inside one or more Pods.

If an attacker compromises a Pod with excessive privileges, they may be able to:

Escape the container
Access sensitive data
Modify the host operating system
Steal Kubernetes Secrets
Attack other workloads
Move laterally across the cluster

For this reason, Kubernetes introduced Pod Security Standards (PSS) to provide a standardized approach for securing workloads.

What are Pod Security Standards?

Pod Security Standards (PSS) define security requirements that Kubernetes workloads should follow.

Rather than allowing every Pod to run with unrestricted permissions, PSS establishes different security levels that determine what a Pod is allowed to do.

PSS provides a consistent baseline for securing workloads across Kubernetes clusters.

Why Were Pod Security Standards Introduced?

Earlier versions of Kubernetes relied on PodSecurityPolicy (PSP).

Although PSP was powerful, it was also:

Difficult to configure
Hard to troubleshoot
Complex for developers
Inconsistent across environments

Because of these challenges, PodSecurityPolicy was deprecated and replaced with:

Pod Security Standards (PSS)
Pod Security Admission (PSA)

These newer mechanisms are easier to understand, simpler to manage, and better suited for enterprise environments.

The Three Pod Security Standards

Kubernetes defines three security profiles.

Privileged

↓

Baseline

↓

Restricted

Each profile progressively reduces the permissions granted to workloads.

Privileged Profile

The Privileged profile imposes very few restrictions.

Pods may:

Run as root
Use privileged containers
Access host networking
Mount host file systems
Access host devices
Use host PID and IPC namespaces

Example:

Pod

↓

Privileged Container

↓

Host Operating System

This profile should only be used for trusted infrastructure components such as networking plugins or storage drivers.

Baseline Profile

The Baseline profile prevents many common privilege escalation techniques while allowing most applications to function normally.

It blocks:

Known dangerous Linux capabilities
Some host namespace access
Dangerous volume types
Certain privileged operations

Baseline is suitable for many general-purpose business applications.

Restricted Profile

The Restricted profile provides the strongest security.

It requires workloads to follow Kubernetes security best practices.

Typical requirements include:

Run as non-root
No privileged containers
No hostPath volumes
No privilege escalation
Drop unnecessary Linux capabilities
Read-only root filesystem where possible
Use Seccomp profiles

Restricted is the recommended profile for production workloads.

Comparing the Three Profiles

Feature	Privileged	Baseline	Restricted
Run as Root	✅	Limited	❌
Privileged Containers	✅	❌	❌
Host Network	✅	Limited	❌
Host PID	✅	❌	❌
HostPath Volumes	✅	Limited	❌
Privilege Escalation	✅	Limited	❌
Recommended for Production	❌	Sometimes	✅

How Pod Security Standards Work

Pod Security Standards define what is allowed.

Pod Security Admission enforces those rules.

Developer

↓

Deploy Pod

↓

Pod Security Admission

↓

Policy Evaluation

↓

Allowed

or

Rejected

Every Pod is evaluated before it is created.

Pod Security Admission (PSA)

Pod Security Admission is the built-in Kubernetes admission controller responsible for enforcing Pod Security Standards.

It evaluates Pod specifications during creation or update.

If the Pod violates the configured security profile, Kubernetes can:

Allow it
Warn about violations
Reject it completely

Enforcement Modes

Pod Security Admission supports three modes.

Enforce

Policy Violation

↓

Deployment Rejected

Pods that violate the configured policy are blocked.

Warn

Policy Violation

↓

Deployment Allowed

↓

Warning Generated

Useful during migration to stricter security policies.

Audit

Deployment Allowed

↓

Audit Event Recorded

Allows organizations to understand policy violations before enforcement.

Namespace-Based Enforcement

Pod Security Standards are applied at the Namespace level.

Example:

Production Namespace

↓

Restricted

--------------------

Development Namespace

↓

Baseline

Different environments can enforce different security requirements.

Example Namespace Labels

Namespaces can be labelled to enforce a specific security level.

Example:

pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/warn: baseline
pod-security.kubernetes.io/audit: baseline

These labels instruct Kubernetes how to evaluate workloads deployed into the Namespace.

Common Security Controls in Restricted Profile

Restricted Pods commonly enforce:

runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
seccompProfile: RuntimeDefault
Drop unnecessary Linux capabilities
Avoid host namespaces
Avoid privileged containers

These controls significantly reduce the attack surface.

Example Deployment Flow

Developer

↓

kubectl apply

↓

API Server

↓

Pod Security Admission

↓

Restricted Policy Check

↓

Pod Created

If the Pod violates the Restricted profile, deployment is denied.

Enterprise Amazon EKS Architecture

Developer

↓

Git Repository

↓

CI/CD Pipeline

↓

Amazon EKS API Server

↓

Pod Security Admission

↓

Namespaces

↓

Application Pods

Every workload is evaluated before reaching production.

Enterprise Example

A financial institution runs more than 2,000 workloads across several Amazon EKS clusters.

The organization defines:

Environment	PSS Profile
Development	Baseline
Testing	Baseline
Production	Restricted
Platform Components	Privileged (limited)

Only infrastructure components such as the Amazon VPC CNI plugin are allowed to run with elevated privileges.

All business applications must comply with the Restricted profile.

This approach minimizes risk while maintaining operational flexibility.

Common Pod Security Risks

Cloud Security Engineers frequently encounter:

Pods running as root
Privileged containers
HostPath volume mounts
Host networking enabled unnecessarily
Privilege escalation enabled
Excessive Linux capabilities
Missing Seccomp profiles
Containers with unrestricted file system access
Shared Service Accounts
Missing Namespace security policies

These misconfigurations increase the likelihood of container escape and privilege escalation.

Enterprise Monitoring

Security teams should monitor:

Pod Security Admission denials
Policy violations
Namespace label changes
Privileged workload deployments
HostPath volume usage
Host network usage
Security Context changes
Audit logs
Kubernetes API activity
Unauthorized workload deployments

Monitoring these events helps detect insecure deployments before they become production incidents.

Enterprise Implementation Strategy

A recommended approach:

Step 1

↓

Identify Workloads

↓

Step 2

↓

Classify Risk

↓

Step 3

↓

Apply Baseline Policy

↓

Step 4

↓

Test Applications

↓

Step 5

↓

Migrate to Restricted

↓

Step 6

↓

Enable Enforce Mode

↓

Step 7

↓

Continuously Monitor

Gradual adoption reduces operational risk while improving security.

Best Practices

As a Kubernetes Security Engineer:

Use the Restricted profile for all production workloads.
Limit the Privileged profile to trusted infrastructure components only.
Apply Pod Security Standards at the Namespace level.
Begin with Audit or Warn mode before enabling Enforce.
Regularly review Namespace labels and admission policies.
Combine Pod Security Standards with Security Contexts and Network Policies.
Monitor policy violations through Kubernetes audit logs.
Continuously validate workloads through CI/CD pipelines.
Educate development teams on secure Pod configurations.
Review workloads regularly to ensure compliance with evolving security requirements.

Real-World Scenario

A global healthcare organization deploys patient management applications on Amazon EKS.

A developer accidentally attempts to deploy a Pod with:

Privileged mode enabled
Host network access
HostPath volume mounted
Root user enabled

The Production Namespace enforces the Restricted Pod Security Standard.

When the deployment reaches the Kubernetes API Server:

Pod Security Admission evaluates the request.
The Pod violates multiple Restricted policy requirements.
Kubernetes rejects the deployment.
The CI/CD pipeline fails immediately.
Security teams receive alerts through Amazon CloudWatch and Security Hub.

Because the insecure Pod never reaches production, the organization prevents a potential privilege escalation attack before it can occur.

Key Takeaways

After completing this lesson, you should understand:

Why Pod Security Standards were introduced
The differences between Privileged, Baseline and Restricted profiles
How Pod Security Admission enforces policies
Namespace-based policy enforcement
Enterprise implementation strategies
Common workload security risks
Best practices for securing Pods in Amazon EKS

Pod Security Standards provide a simple yet powerful framework for securing Kubernetes workloads. By enforcing consistent security requirements across Namespaces and integrating them into CI/CD pipelines, organizations can significantly reduce the risk of insecure deployments and improve the overall security posture of their Amazon EKS environments.

Knowledge Check

Question 1

What is the primary purpose of Pod Security Standards (PSS)?

A. Schedule Pods across Nodes
B. Define security requirements for Kubernetes workloads
C. Configure persistent storage
D. Manage Kubernetes networking

Answer: B

Question 2

Which Pod Security Standard profile is recommended for production workloads?

A. Privileged
B. Baseline
C. Restricted
D. Development

Answer: C

Question 3

Which Kubernetes component enforces Pod Security Standards?

A. kube-proxy
B. Pod Security Admission
C. CoreDNS
D. etcd

Answer: B

Question 4

Which enforcement mode blocks non-compliant Pods from being created?

A. Audit
B. Warn
C. Enforce
D. Observe

Answer: C

Question 5

Which of the following is considered a best practice for production environments?

A. Run all Pods as privileged.
B. Enable host networking for every workload.
C. Use the Restricted Pod Security Standard with continuous monitoring.
D. Disable Pod Security Admission.

Answer: C

What’s Next?

In the next lesson, you will learn about Security Contexts, where you’ll explore how to configure secure execution settings for Pods and containers, including running as non-root users, controlling Linux capabilities, preventing privilege escalation, applying Seccomp profiles and enforcing secure runtime behavior in Amazon EKS.

➡️ Next Lesson: Lesson 02 — Security Contexts