K8 - Banner

Introduction

For anyone in cybersecurity, two questions inevitably arise: What is Kubernetes, and what are the common security risks associated with it? These topics often seem complicated or are explained in overly technical terms.

This series provides a practical, hands-on journey through Kubernetes security. I will break down complex concepts into simple explanations, covering:

  • Kubernetes fundamentals
  • Setting up K8s pentesting labs
  • Common security issues and exploitation techniques
  • Remediation and defense strategies

I hope this series will transform your understanding of Kubernetes security. Let’s dive in.

What and Why of Kubernetes?

The name Kubernetes originates from Greek, meaning helmsman or pilot. The abbreviation K8s comes from counting the eight letters between “K” and “s”. Google open-sourced the Kubernetes project in 2014.

Companies use Kubernetes for several key reasons:

  • Automated deployment and scaling - Deploy applications and scale them automatically based on demand
  • Self-healing - Restarts failed containers, replaces unhealthy ones, and reschedules workloads when nodes fail
  • Load balancing and service discovery - Distributes traffic efficiently and allows services to find and communicate with each other
  • Storage orchestration - Manages persistent and ephemeral storage for applications
  • RBAC and security controls - Implements access control, network policies, and secrets management for secure workloads

One of the best examples we can see nowadays is JioHotstar. They have shared multiple blogs on Kubernetes, including how they shifted their entire infrastructure from Amazon EC2 to Kubernetes and how they scaled up during special events like IPL or the Cricket World Cup. If you’re interested in real-world Kubernetes engineering insights, I highly recommend checking out their blog at blog.hotstar.com.

It’s important to understand that such large-scale implementations help us see the real security challenges that come with Kubernetes. As we dive deeper into Kubernetes pentesting, we’ll explore potential misconfigurations, security risks, and how to protect such critical infrastructure.

Kubernetes Architecture

Let’s understand the Kubernetes architecture using this simple diagram.

Kubernetes Architecture

A Kubernetes deployment is called a cluster. A cluster consists of at least one Control Plane (also called Master Node) and one or more Worker Nodes. These can be physical devices, virtual machines, or instances in the cloud.

Control Plane

The Control Plane is the central management layer that maintains the desired state of the cluster. It’s essentially the “brain” of the Kubernetes cluster, making decisions about scheduling, detecting events, and ensuring the cluster operates as intended.

  • Key components include the API server, etcd, controller manager, scheduler, and cloud controller manager.
  • It receives information about cluster activity and requests, then uses this information to adjust cluster resources to the desired state.
  • It decides which nodes should run which pods, ensuring optimal resource utilization.
  • In production environments, the control plane usually runs across multiple machines for fault tolerance and high availability.

The Control Plane runs on dedicated master nodes, separate from worker nodes that run the actual application workloads. This separation ensures high availability and reliability of the management components.

Worker Node

A worker node, or simply a node, is a physical or virtual machine that runs containerized applications (Pods) in a Kubernetes cluster. While the Control Plane manages the cluster, worker nodes execute workloads by hosting and running Pods.

  • Each node can run multiple Pods, depending on its available resources. Worker nodes communicate with the Control Plane to receive instructions and report status.
  • As the core of the Kubernetes data plane, worker nodes handle application execution and networking, ensuring seamless communication between services within and outside the cluster.
  • If the Control Plane is the brain of Kubernetes, then worker nodes are its muscles, executing tasks and running applications.

Control Plane Components

Kube Control Manager

In Kubernetes, a controller is a control loop that watches the shared state of the cluster through the API server and makes changes to move the current state toward the desired state.

The kube-controller-manager component is a collection of multiple controllers included in a single binary. This design reduces complexity by running all controllers in a single process. It’s responsible for running multiple controllers that maintain the desired state of the cluster.

Examples of controllers include the replication controller, endpoints controller, namespace controller, and service accounts controller.

  • The kube-controller-manager constantly monitors the cluster’s state through the Kubernetes API server, tracking the configuration of Pods, Deployments, Services, and other resources.
  • It compares the desired state (as defined in Kubernetes manifests) with the actual state to identify discrepancies.
  • When deviations are detected, the appropriate controllers take action to rectify the situation, such as scaling Pods, restarting failed containers, or recreating resources as needed.

Etcd

  • etcd is a fast and highly available distributed key-value database that Kubernetes uses to store all cluster data. Each resource in a cluster has a key in the database.
  • Essentially, etcd stores all cluster data from which the API server can collect and decide how to bridge the current and desired state.

Scheduler

  • In Kubernetes, scheduling ensures that Pods are matched to Nodes so that the Kubelet can run them.
  • A scheduler watches for newly created Pods that have no Node assigned. For every Pod that the scheduler discovers, it becomes responsible for finding the best Node for that Pod to run on.
  • The kube-scheduler is a control plane component that determines which node a Pod will run on, ensuring pods are assigned to suitable nodes based on resource availability and constraints.

Cloud Controller Manager

  • The cloud-controller-manager is a Kubernetes control plane component that manages cloud-specific operations. It connects your cluster to your cloud provider’s API and separates cloud platform interactions from cluster-only operations.
  • This decoupling of cloud infrastructure logic allows cloud providers to develop and release their features independently from the main Kubernetes project.
  • The cloud-controller-manager uses a plugin architecture, enabling various cloud providers to integrate their platforms with Kubernetes.

Worker Node Components

Kubelet

  • The kubelet is the main Kubernetes agent that runs on every worker node and is responsible for running the actual containers.
  • Its primary job is to watch the API server for new work tasks. When it detects a task, it executes it and maintains a reporting channel back to the control plane.
  • If the kubelet cannot execute a task, it reports back to the control plane, which then decides what action to take.

Kube-proxy

  • Kube-proxy runs on every node and handles local cluster networking by routing network communication between pods and the network.
  • It assigns each node a unique IP address and implements local tables or IPVS rules to manage the routing and load balancing of Pod network traffic.

Container Runtime

  • Each node requires a container runtime. The kubelet relies on this runtime to perform container-related tasks such as pulling images, starting containers, and stopping containers.

Security Landscape Overview

As organizations rapidly migrate to Kubernetes, security teams find themselves in a paradox: the very features that make containers powerful like isolation, orchestration, and their ephemeral nature also create unique security blind spots that traditional tools can’t address.

Converting monolithic application deployments into microservices using Kubernetes streamlines the entire process. But does this mean it’s a more secure architecture? No. Kubernetes has multiple components that can be easily misconfigured and become targets for attackers. These misconfigurations are commonly overlooked when deploying applications. Ignoring such basic configuration settings can lead to serious security vulnerabilities.

The Kubernetes Security Report 2025 by Wiz reveals several concerning findings:

  • 21% of publicly exposed pods are running with at least one critical or high vulnerability.
  • Over 9% of pods have sensitive host mapping, and 10% of pods are running as root.
  • More than 60% of clusters exposed sensitive information like secrets and config maps.
  • Many clusters lack proper network segmentation or access controls.

These statistics highlight that securing Kubernetes requires a deeper understanding of its architecture, configurations, and runtime behavior not just default deployments or surface-level hardening.

The gap between Kubernetes adoption and security maturity creates a critical window of vulnerability for many organizations. In most cases, security is implemented after operational deployment and that delay is part of the problem.

To accelerate and strengthen security implementation, we’ve seen significant research and tooling development around Kubernetes. The Cloud Native Computing Foundation (CNCF) has developed comprehensive security frameworks, and numerous specialized tools have emerged for Kubernetes security assessment and hardening. Notable tools include Kube-bench, Calico, KubeLinter, Kube-hunter, Kubeaudit, Kubescape, Cilium, Falco, Checkov, and many more.

Introduction Kubernetes Threat Modeling

Before diving into attacks, it’s important to understand the complexity of Kubernetes. It consists of multiple interconnected components. The API Server acts as the central control point, the Control Plane manages cluster operations, Pods host your applications, and etcd stores all cluster state and configuration data. This architectural complexity creates both power and risk. This is precisely why threat modeling becomes essential for Kubernetes environments.

Microsoft has developed a comprehensive threat matrix specifically for Kubernetes that catalogs the most common attack techniques and tactics. This matrix serves as both a checklist and a roadmap, helping security teams understand not just what attacks are possible, but how they typically unfold in real-world scenarios.

You can use tools like Mermaid or diagrams.net to visualize your own Kubernetes threat models.

Microsoft Threat Matrix for Kubernetes

Microsoft Threat Matrix

One of the most widely recognized frameworks for understanding Kubernetes threats is the Microsoft Threat Matrix. It maps out common attacker goals and techniques specific to Kubernetes environments. Some notable examples include exposed sensitive interfaces, sidecar injection, and privilege escalation through service account tokens.

This matrix provides a structured way to visualize how attackers can navigate through various components of a cluster-making it an essential reference for anyone building a Kubernetes threat model.

These techniques serve as a starting point for building a tailored threat model based on your specific cluster configuration and risk surface.

Attack Paths in Kubernetes

Threat Model

Key Kubernetes components from a threat modeling lens:

  • API Server: Validates and configures data for API objects including pods, services, replication controllers, and others
  • etcd: Fast and highly available distributed key-value database
  • Kubelet: Main Kubernetes agent that runs on every worker node and is responsible for running the actual containers
  • Control Plane: Manages clusters and resources such as worker nodes and pods
  • Node: Physical or virtual machine in the cluster that runs your application containers

How attackers exploit these components and impact of it:

  • API Server: Unauthorized access or privilege escalation via insecure RBAC or misconfigured API endpoints can lead to full cluster compromise
  • etcd: Access to unencrypted etcd data store exposes secrets, configurations, and credentials, enabling full control over the cluster
  • Kubelet: Exploitation of insecure Kubelet API or read-only port allows attackers to execute commands on pods or extract sensitive data
  • Control Plane: Compromise of control plane components allows attackers to manipulate workloads, scheduling, and cluster-wide behavior
  • Node: Container escape or compromised node via vulnerable runtime leads to host-level compromise and lateral movement within the cluster

Conclusion: Why Kubernetes Threat Modeling is Crucial

Kubernetes is not just an container orchestration platform. It’s complex distributed system where it helps to make entire deployment process easy and flexible but it also comes with misconfigurations, trust boundaries and expanded attack surface.

That’s where Threat modeling comes into the picture.

Threat modeling helps you in:

  • Understand how an attacker thinks by identifying the components and trust boundaries
  • Prioritize the defense based on the real world risk not just compliance related checks
  • Uncover the possibly weakest path ealy before they’re exploited in production

🧠TL;DR

Threat modeling in kubernetes is not an optional - It’s early warning system

  • Transform chaos into clarity
  • Turn assumption into verified controls
  • Helps to prevent security breach before it starts.

In a Kubernetes environment, where shared responsibility, and rapid deployments are the norm, threat modeling provides a structured way to think offensively while acting defensively.

References

🚀Coming next

In the next blog post, we will shift from theory to action, exploring initial access and reconnaissance techniques in Kubernetes.

We will also examine how exposed clusters are attacked and what you can do to stop them.

Stay tuned. The attack surface is waiting.