Lesson 10 — Container & Kubernetes Attacks

Learning Objectives

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

Understand container attack techniques.
Learn how attackers compromise Kubernetes environments.
Identify common container and Kubernetes misconfigurations.
Understand privilege escalation within Kubernetes.
Learn how cloud-native attacks differ from traditional infrastructure attacks.
Apply enterprise Kubernetes security assessment methodologies.

Introduction

Modern enterprise applications increasingly run inside containers orchestrated by Kubernetes.

Cloud providers offer managed Kubernetes platforms such as:

Amazon Elastic Kubernetes Service (EKS)
Azure Kubernetes Service (AKS)
Google Kubernetes Engine (GKE)

Although Kubernetes improves scalability and automation, it also introduces new attack surfaces.

Rather than attacking a single server, attackers may target:

Container images
Kubernetes API Server
Pods
Service Accounts
RBAC
Secrets
Admission Controllers
Container Registries
Cluster Networking

Cloud Penetration Testers must understand these attack vectors to identify security weaknesses before they are exploited.

Why Attackers Target Kubernetes

A compromised Kubernetes cluster may provide access to:

Cloud credentials
Sensitive secrets
Customer applications
Databases
CI/CD pipelines
Internal APIs
Cloud storage
Entire production environments

One vulnerable workload can expose an entire cluster.

Container & Kubernetes Attack Lifecycle

Reconnaissance

↓

Container Discovery

↓

Kubernetes Enumeration

↓

Identity Discovery

↓

Privilege Escalation

↓

Container Escape

↓

Cluster Compromise

↓

Cloud IAM Access

↓

Lateral Movement

↓

Data Access

↓

Persistence

Enterprise Kubernetes Attack Surface

Internet

↓

Ingress Controller

↓

Application

↓

Container

↓

Pod

↓

Service Account

↓

Kubernetes API

↓

RBAC

↓

Secrets

↓

Cloud IAM

↓

Sensitive Resources

Common Attack Targets

Attackers frequently target:

Container Images
Kubernetes API Server
Service Accounts
RBAC
Secrets
ConfigMaps
Admission Controllers
Ingress Controllers
etcd
Container Runtime

Attack 1 — Vulnerable Container Images

Containers built from outdated images may contain:

Known CVEs
Weak packages
Unsupported software
Malware
Hardcoded credentials

Example:

Public Registry

↓

Old Image

↓

Known Vulnerability

↓

Container Compromise

Always scan container images before deployment.

Attack 2 — Running Containers as Root

Example:

securityContext:
  runAsUser: 0

Risks include:

Elevated privileges
Host access
Container escape
Increased impact of application compromise

Containers should run as non-root users whenever possible.

Attack 3 — Privileged Containers

Example:

securityContext:
  privileged: true

Privileged containers have extensive access to the host.

Potential attacker actions:

Mount host filesystem
Load kernel modules
Access host devices
Escape container isolation

Privileged containers should be avoided unless absolutely necessary.

Attack 4 — Container Escape

Container escape occurs when an attacker breaks out of the container and gains access to the underlying host.

Possible causes include:

Vulnerable container runtime
Privileged containers
Linux kernel vulnerabilities
Misconfigured mounts
HostPath volumes

Container escape significantly increases the impact of a compromise.

Attack 5 — Kubernetes API Abuse

The Kubernetes API controls the entire cluster.

Attackers attempt to:

List resources
Create workloads
Read Secrets
Modify RBAC
Deploy malicious Pods

Protect API access through strong authentication and authorisation.

Attack 6 — RBAC Misconfiguration

Overly permissive RBAC can allow attackers to escalate privileges.

Example:

cluster-admin

Questions to review:

Who has cluster-admin?
Are service accounts over-privileged?
Can developers modify RBAC?

RBAC should always follow the principle of least privilege.

Attack 7 — Service Account Abuse

Pods authenticate using service accounts.

Example attack:

Compromised Pod

↓

Service Account Token

↓

Kubernetes API

↓

Secrets

↓

Cloud Credentials

Review every service account during an assessment.

Attack 8 — Kubernetes Secrets

Secrets may contain:

Database passwords
API Keys
TLS Certificates
Cloud Credentials
Tokens

Review:

Encryption
RBAC permissions
Secret rotation
External secret management

Avoid storing plaintext secrets in manifests.

Attack 9 — ConfigMap Abuse

Sensitive information is sometimes incorrectly stored inside ConfigMaps.

Examples:

API Keys
Passwords
Tokens
Connection strings

ConfigMaps should contain configuration—not sensitive secrets.

Attack 10 — Insecure Network Policies

Without Network Policies:

Pod A

↓

Any Pod

↓

Database

↓

Secrets

Attackers may move freely throughout the cluster.

Implement network segmentation wherever possible.

Attack 11 — HostPath Volume Abuse

Example:

hostPath:
  path: /

Risks:

Access host filesystem
Modify host files
Read sensitive information
Escape isolation

HostPath volumes should be tightly controlled.

Attack 12 — Exposed Dashboard

An exposed Kubernetes Dashboard may allow attackers to:

Enumerate workloads
View secrets
Create Pods
Modify deployments
Access logs

The dashboard should never be publicly accessible.

Attack 13 — etcd Exposure

etcd stores cluster state including:

Secrets
RBAC
Pods
Nodes
Deployments

An exposed etcd instance may expose the entire cluster configuration.

Attack 14 — Admission Controller Bypass

Weak or missing admission policies may allow:

Privileged Pods
Root containers
Untrusted images
Host networking
Dangerous capabilities

Admission Controllers enforce security standards before workloads are deployed.

Attack 15 — Cloud IAM Integration

Managed Kubernetes clusters often integrate with cloud IAM.

Examples:

IAM Roles for Service Accounts (IRSA)
Azure Workload Identity
Google Workload Identity

Misconfigured workload identities may allow attackers to access cloud resources beyond the cluster.

Kubernetes Enumeration

Review:

Nodes
Pods
Deployments
Services
Ingress
Secrets
ConfigMaps
Service Accounts
RBAC
Network Policies
Namespaces
Admission Controllers

Example commands:

kubectl get nodes

kubectl get pods --all-namespaces

kubectl get secrets --all-namespaces

kubectl get clusterroles

kubectl get networkpolicies --all-namespaces

Enterprise Kubernetes Assessment

Review:

API Server Security
RBAC
Authentication
Authorization
Pod Security Standards
Runtime Security
Image Security
Secrets Management
Logging
Audit Policies
Network Policies
Workload Identity

Enterprise Scenario

CloudNova Technologies operates three Amazon EKS clusters.

Assessment findings:

Six privileged Pods.
Three containers running as root.
Kubernetes Dashboard accessible from the internet.
Multiple service accounts with cluster-admin privileges.
Secrets stored in ConfigMaps.
No Network Policies configured.
Untrusted images deployed from public registries.
Audit logging disabled.
HostPath volumes mounted on production workloads.

These findings create multiple attack paths within the Kubernetes environment.

Example Enterprise Attack Path

Public Application

↓

Container Exploit

↓

Pod Access

↓

Service Account Token

↓

Kubernetes API

↓

Cluster Admin

↓

Cloud IAM

↓

Amazon S3

↓

Sensitive Customer Data

Enterprise Deliverables

A Kubernetes security assessment should include:

Cluster Architecture Review
Kubernetes Resource Inventory
RBAC Assessment
Service Account Review
Secrets Assessment
Network Policy Review
Pod Security Assessment
Container Image Assessment
Runtime Security Review
Executive Summary
Technical Findings Report

Defensive Controls

Organizations should implement:

Pod Security Admission
Least Privilege RBAC
Non-root Containers
Read-only Root Filesystems
Image Signing
Image Vulnerability Scanning
Network Policies
Runtime Threat Detection (Falco)
Admission Controllers
Audit Logging
Workload Identity
External Secrets Management

Best Practices

Run containers as non-root.
Remove unnecessary Linux capabilities.
Scan images before deployment.
Apply least privilege RBAC.
Secure service accounts.
Enable audit logging.
Implement Network Policies.
Protect the Kubernetes API.
Enforce Pod Security Admission.
Monitor runtime activity continuously.

Common Mistakes

Avoid:

Running privileged containers.
Using cluster-admin unnecessarily.
Storing secrets in ConfigMaps.
Allowing public dashboard access.
Using untrusted images.
Ignoring runtime monitoring.
Leaving audit logging disabled.

Knowledge Check

1. Why are Kubernetes service accounts attractive targets?

Answer: Service accounts authenticate workloads to the Kubernetes API and may also have permissions to access cloud resources. Overly privileged service accounts can enable attackers to expand a compromise.

2. Why should containers avoid running as the root user?

Answer: Running as root increases the impact of a compromise and may make container escape or host-level attacks easier if other security controls fail.

3. What is the purpose of Kubernetes RBAC?

Answer: RBAC controls which users, groups and service accounts can perform actions within the cluster, enforcing the principle of least privilege.

4. Why are Network Policies important?

Answer: Network Policies restrict communication between workloads, limiting lateral movement and reducing the attack surface within a Kubernetes cluster.

5. What are the most important areas to assess during a Kubernetes security review?

Answer: API security, RBAC, service accounts, secrets, container images, Pod Security Admission, runtime security, audit logging, network policies and workload identities.

Key Takeaways

Containers and Kubernetes introduce cloud-native attack surfaces that require specialised security assessments.
Service accounts, RBAC and workload identities are common targets during Kubernetes attacks.
Secure container images, strong runtime controls and least privilege significantly reduce risk.
Kubernetes security depends on both platform configuration and workload hardening.
Cloud Penetration Testers must evaluate the complete cloud-native stack, from container images to cloud IAM integrations.

What’s Next?

In the next lesson, we will explore Lesson 11 — Enterprise Cloud Attack Scenarios & Case Studies, where you will analyse real-world cloud breaches, map attacker techniques, identify root causes and learn how enterprise security teams investigate and remediate cloud compromises.