Lesson 06 — Privileged Containers

Learning Objectives

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

Understand what privileged containers are
Learn how privileged mode works in Linux and Kubernetes
Understand the risks associated with privileged containers
Learn how attackers abuse privileged containers
Identify legitimate enterprise use cases
Restrict privileged workloads in Amazon EKS
Apply enterprise security best practices

Why This Matters

Containers are designed to isolate applications from the host operating system.

This isolation protects:

The Linux kernel
Other containers
Kubernetes worker nodes
Sensitive system resources

However, when a container runs in privileged mode, much of this isolation disappears.

If an attacker compromises a privileged container, they may gain extensive access to the underlying Kubernetes node, increasing the risk of a complete cluster compromise.

For this reason, privileged containers are considered one of the most dangerous workload configurations in Kubernetes.

What is a Privileged Container?

A privileged container is a container that has almost unrestricted access to the host operating system.

Instead of operating inside an isolated container environment, it can interact directly with host resources.

Example:

Application

↓

Privileged Container

↓

Host Kernel

↓

Host Operating System

Privileged containers bypass many of the security controls normally provided by container runtimes.

Normal Container vs Privileged Container

Standard Container

Application

↓

Container Runtime

↓

Isolated Environment

↓

Host Operating System

The container is restricted.

Privileged Container

Application

↓

Privileged Container

↓

Direct Host Access

↓

Operating System

The application gains significantly more control over the host.

Why Privileged Containers are Dangerous

Privileged containers receive access to many host resources, including:

Linux devices
Kernel interfaces
Network configuration
System capabilities
Host file systems
Process namespaces

This dramatically increases the attack surface.

What Can an Attacker Do?

If an attacker compromises a privileged container, they may attempt to:

Escape the container
Access host files
Read Kubernetes Secrets stored on the node
Capture network traffic
Modify firewall rules
Install malware
Access other containers
Create persistence
Escalate privileges

A single compromised privileged container can threaten the entire cluster.

Container Escape

One of the biggest risks is container escape.

Example:

Compromised Container

↓

Access Host Resources

↓

Escape Isolation

↓

Compromise Kubernetes Node

Once the host is compromised, attackers often target:

kubelet
Container runtime
Kubernetes credentials
Other running workloads

Privileged Mode in Kubernetes

Privileged mode is enabled through the Security Context.

Example:

securityContext:
  privileged: true

When enabled, Kubernetes instructs the container runtime to launch the container with elevated privileges.

Capabilities vs Privileged Mode

Linux Capabilities	Privileged Mode
Grants selected privileges	Grants nearly all privileges
Supports least privilege	Bypasses least privilege
Recommended when necessary	Avoid whenever possible
Fine-grained control	Broad system access

Whenever possible, use Linux Capabilities instead of privileged mode.

Host Resource Access

Privileged containers can access resources such as:

Host

├── Devices

├── Kernel

├── File System

├── Network Interfaces

├── Process Information

└── Runtime Resources

Standard containers should never require this level of access.

HostPath + Privileged Containers

A particularly dangerous combination is:

Privileged Container
HostPath Volume

Example:

Container

↓

HostPath Mount

↓

/

↓

Entire Host Filesystem

An attacker may be able to modify host files, steal credentials or tamper with system binaries.

Host Networking

Privileged containers are often combined with:

hostNetwork: true

This allows direct access to the node’s network stack.

Potential abuse includes:

Packet capture
Network reconnaissance
Traffic interception
Firewall manipulation

Host PID Namespace

If host PID access is enabled:

Container

↓

Host Processes

↓

View Running Processes

↓

Interact with Processes

Attackers gain visibility into processes running outside the container.

Legitimate Enterprise Use Cases

Some infrastructure components legitimately require privileged mode.

Examples include:

Container Network Interface (CNI) plugins
CSI storage drivers
Device plugins (GPU, FPGA)
Node monitoring agents
Low-level security agents
Hardware management tools

These workloads are carefully reviewed, tightly controlled and isolated.

Business applications should not require privileged mode.

Amazon EKS Architecture

Developer

↓

Git Repository

↓

CI/CD Pipeline

↓

Amazon EKS API Server

↓

Pod Security Admission

↓

Worker Node

↓

Container Runtime

↓

Privileged Container (Approved Only)

Only approved infrastructure components should be deployed as privileged containers.

Restricting Privileged Containers

Enterprise environments typically enforce:

Pod Security Standards (Restricted)
Pod Security Admission
Admission Controllers
Kyverno Policies
OPA Gatekeeper
CI/CD validation
Security reviews

These controls prevent unauthorized privileged workloads from reaching production.

Enterprise Example

A global financial institution operates over 4,000 Pods across multiple Amazon EKS clusters.

Its policy states:

Business applications must not run as privileged.
Only approved infrastructure DaemonSets may request privileged mode.
Every privileged deployment requires security approval.
CI/CD pipelines reject unauthorized privileged workloads.

Infrastructure components such as the Amazon VPC CNI plugin are deployed in dedicated system namespaces with strict RBAC and continuous monitoring.

This minimizes risk while supporting required cluster functionality.

Common Risks

Cloud Security Engineers frequently identify:

Privileged application containers
HostPath volume abuse
Host networking enabled unnecessarily
Host PID access enabled
Missing Pod Security Admission
Weak admission policies
Excessive Linux capabilities
Unreviewed infrastructure workloads
Privileged third-party images
Lack of monitoring for privileged Pods

These misconfigurations significantly increase the likelihood of container escape and host compromise.

Enterprise Monitoring

Security teams should monitor:

Privileged Pod deployments
Changes to Security Contexts
HostPath volume usage
Host network usage
Host PID namespace usage
Admission Controller denials
Runtime security events
Kubernetes audit logs
CI/CD validation failures
Node-level security alerts

Continuous monitoring helps identify unauthorized privileged workloads before they become security incidents.

Enterprise Implementation Strategy

A recommended approach:

Step 1

↓

Inventory Existing Workloads

↓

Step 2

↓

Identify Privileged Pods

↓

Step 3

↓

Determine Business Justification

↓

Step 4

↓

Replace with Linux Capabilities Where Possible

↓

Step 5

↓

Restrict Remaining Privileged Workloads

↓

Step 6

↓

Enable Admission Policies

↓

Step 7

↓

Continuously Monitor

This approach reduces privileged workloads while maintaining operational requirements.

Best Practices

As a Kubernetes Security Engineer:

Never deploy business applications as privileged containers.
Use Linux Capabilities instead of privileged mode whenever possible.
Restrict privileged workloads to trusted infrastructure components.
Enable the Restricted Pod Security Standard for production Namespaces.
Use Pod Security Admission and policy engines to block unauthorized privileged Pods.
Review all privileged workload requests through a formal security approval process.
Continuously monitor privileged container activity.
Avoid combining privileged mode with HostPath, hostNetwork or hostPID unless absolutely necessary.
Validate Security Contexts during CI/CD.
Regularly audit privileged workloads across the cluster.

Privileged containers should be treated as exceptions, not the default.

Real-World Scenario

A software vendor deploys a monitoring agent into an Amazon EKS cluster.

During testing, a developer mistakenly enables:

privileged: true
hostNetwork: true
hostPID: true
HostPath access to /

The organization’s admission policies evaluate every deployment.

Because the workload is being deployed into an application namespace rather than the approved infrastructure namespace:

Pod Security Admission rejects the deployment.
The CI/CD pipeline fails.
Security teams receive an alert.
Developers replace privileged mode with the minimum required Linux Capabilities.

The monitoring agent functions correctly without unnecessary host-level access, significantly reducing the risk of container escape.

Key Takeaways

After completing this lesson, you should understand:

What privileged containers are
Why privileged mode is considered high risk
How attackers exploit privileged workloads
The relationship between privileged mode and container escape
Legitimate enterprise use cases
How Amazon EKS organizations restrict privileged workloads
Enterprise governance and monitoring best practices

Privileged containers remove many of the security boundaries that make containers safe. By restricting privileged workloads, enforcing Pod Security Standards, validating Security Contexts and continuously monitoring deployments, organizations can significantly reduce the risk of host compromise and protect their Amazon EKS environments.

Knowledge Check

Question 1

What is a privileged container?

A. A container with unrestricted network bandwidth
B. A container that has extensive access to host resources and the Linux kernel
C. A container running in a private subnet
D. A container using a read-only filesystem

Answer: B

Question 2

Which Kubernetes Security Context setting enables privileged mode?

A. runAsNonRoot: true
B. allowPrivilegeEscalation: false
C. privileged: true
D. readOnlyRootFilesystem: true

Answer: C

Question 3

Which of the following is considered a legitimate enterprise use case for privileged containers?

A. Public web applications
B. Customer-facing APIs
C. Container Network Interface (CNI) plugins
D. Database applications

Answer: C

Question 4

Which security risk is most closely associated with privileged containers?

A. Slow Pod scheduling
B. Container escape and host compromise
C. Increased storage costs
D. DNS resolution failures

Answer: B

Question 5

Which represents an enterprise best practice?

A. Deploy all workloads as privileged containers.
B. Use privileged mode only for approved infrastructure components and enforce policies to block unauthorized privileged workloads.
C. Enable host networking for every application.
D. Grant every container full Linux capabilities.

Answer: B

What’s Next?

Learn why running containers as non-root is a fundamental Kubernetes security best practice, understand the risks of root containers, and implement secure workload execution in Amazon EKS using Security Contexts and enterprise governance.

➡️ Next Lesson: Lesson 07 — Root vs Non-Root Containers