Lesson 06 — Pod Security

Welcome

Pods are the smallest deployable unit in Kubernetes and form the foundation of every application running inside a cluster.

Every workload—whether a web application, API, database, monitoring tool, or microservice—runs inside one or more Pods.

Because Pods execute application containers, they are one of the primary targets during Kubernetes security assessments. Misconfigured Pods can expose sensitive data, provide excessive privileges, allow lateral movement, or even enable attackers to compromise worker nodes.

As a Cloud Penetration Tester, understanding Pod Security is essential for evaluating workload security and identifying weaknesses before they become business risks.

In this lesson, you will learn how Kubernetes Pods are secured, common Pod security misconfigurations, and how consultants assess workloads during enterprise Kubernetes engagements.

Learning Objectives

After completing this lesson, you will be able to:

Understand Kubernetes Pod architecture.
Explain Pod Security concepts.
Identify insecure Pod configurations.
Assess container security settings.
Review Linux security controls.
Evaluate Pod Security Admission.
Identify common workload security risks.
Recommend enterprise workload hardening practices.

Business Scenario

CloudNova Technologies has been engaged to assess the Kubernetes environment of a financial services company.

The organization hosts hundreds of production workloads across multiple Kubernetes clusters.

Management wants assurance that Pods are securely configured and that workloads cannot be abused to compromise sensitive business applications or underlying infrastructure.

Your objective is to review Pod configurations, identify security weaknesses, and recommend improvements that align with enterprise security standards.

What is a Kubernetes Pod?

A Pod is the smallest deployable object in Kubernetes.

A Pod may contain:

One application container
Multiple tightly coupled containers
Shared networking
Shared storage
Shared lifecycle

Pods provide the runtime environment for containerized applications.

Pod Architecture

Kubernetes Cluster

↓

Node

↓

Pod

↓

Container

↓

Application

Each Pod contains:

Containers
Volumes
Networking
Service Account
Security Context

Why Attackers Target Pods

Pods often contain:

Business applications
Service Account tokens
API credentials
Cloud credentials
Database connections
Internal application secrets

Compromising a Pod may provide access to sensitive information or additional cloud resources.

Pod Security Components

Enterprise assessments should review:

Security Context
Service Account
Linux Capabilities
Mounted Volumes
Container Images
Environment Variables
Secrets
Resource Limits
Pod Security Admission

Security Context

The Security Context defines how containers run.

Review:

User ID (UID)
Group ID (GID)
Privilege Escalation
Read-only File System
Linux Capabilities
SELinux
AppArmor
Seccomp

Proper Security Context configuration significantly reduces workload risk.

Privileged Containers

A privileged container has elevated access to the underlying host operating system.

Risks include:

Host access
Device access
Kernel interaction
Container escape opportunities

During assessments identify workloads configured with unnecessary privileged access.

Running as Root

Containers should avoid running as the root user whenever possible.

Review:

User ID
Group ID
Root privileges
Non-root enforcement

Running applications as non-root reduces the impact of a compromised container.

Linux Capabilities

Linux Capabilities divide root privileges into smaller permission sets.

Review whether unnecessary capabilities have been granted.

Examples include:

NET_ADMIN
SYS_ADMIN
SYS_PTRACE
DAC_OVERRIDE

Minimizing capabilities supports the Principle of Least Privilege.

Read-Only Root Filesystem

Containers should use a read-only root filesystem where possible.

Benefits include:

Reduced malware persistence
Protection against unauthorized file modifications
Improved workload integrity

Review whether workloads require write access.

Resource Limits

Assess whether Pods define:

CPU Requests
CPU Limits
Memory Requests
Memory Limits

Resource limits improve workload stability and help reduce the impact of resource exhaustion.

Service Accounts

Every Pod may authenticate using a Kubernetes Service Account.

Review:

Assigned Service Account
RBAC permissions
Mounted API token
Namespace scope

Ensure workloads receive only the permissions required for their function.

Pod Security Admission

Pod Security Admission (PSA) is Kubernetes’ built-in mechanism for enforcing workload security standards.

Common policy levels include:

Privileged

Allows unrestricted Pod configuration.

Use only where absolutely necessary.

Baseline

Prevents common privilege escalation techniques while supporting most workloads.

Suitable for many production environments.

Restricted

Enforces the strongest security controls.

Typical requirements include:

Non-root containers
Restricted capabilities
No privileged containers
Limited host access

Recommended for highly sensitive workloads where application compatibility allows.

Enterprise Pod Security Review

During an enterprise assessment review:

Security Context
Privileged Pods
Root Containers
Service Accounts
Mounted Secrets
Resource Limits
HostPath Volumes
Host Networking
Host PID
Host IPC
Admission Policies

Document workloads that require additional security controls.

Common Pod Security Findings

Enterprise Kubernetes assessments frequently identify:

Privileged containers
Containers running as root
Missing Security Context
Excessive Linux Capabilities
Mounted Service Account tokens
Missing resource limits
HostPath volume usage
Disabled Pod Security Admission
Shared Service Accounts
Weak workload isolation

Enterprise Best Practices

Organizations should:

Run containers as non-root.
Enable Pod Security Admission.
Apply the Principle of Least Privilege.
Remove unnecessary Linux Capabilities.
Restrict privileged containers.
Use read-only root filesystems where possible.
Define CPU and memory limits.
Limit Service Account permissions.
Regularly review workload configurations.

Consultant Best Practices

Professional Kubernetes security consultants should:

Review Pod specifications before testing workloads.
Validate Security Context settings.
Identify privileged containers early in the assessment.
Review Service Account permissions separately.
Document workload ownership.
Prioritize business-critical applications.
Collect evidence for every finding.
Recommend practical workload hardening improvements.

Key Takeaways

Pods are the primary execution environment for Kubernetes applications.
Poor Pod security increases the risk of workload compromise.
Security Context, Service Accounts, and Pod Security Admission are critical security controls.
Containers should avoid unnecessary privileges and run as non-root users.
Enterprise Kubernetes assessments should evaluate workload security before testing higher-level attack paths.

Lesson Summary

In this lesson, you learned how Kubernetes Pods are secured, how consultants assess workload security, and the most common configuration weaknesses found during enterprise Kubernetes security assessments.

Strong Pod Security reduces the attack surface, limits privilege escalation opportunities, and improves the overall security posture of Kubernetes environments.

What’s Next?

➡️ Lesson 07 — Container Escape

In the next lesson, you will learn how container escape vulnerabilities occur, why they represent one of the highest risks in Kubernetes environments, and how Cloud Penetration Testers assess container isolation and host security during enterprise engagements.