Kubernetes Security, From Build to Deploy
Intro to k8s
Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services that facilitate both declarative configuration and automation. It has a large, rapidly growing ecosystem
Name Meaning: Kubernetes comes from Greek, meaning “helmsman” or “pilot”, symbolizing its role in steering applications.
Why k8s became so Important these days
It plays a crucial role in production environments where services must remain available, resilient, and easily updatable. without an orchestrator, managing hundreds or thousands of containers manually would be error-prone, inefficient, and unsustainable especially in environments that demand high availability, dynamic scaling, and automated recovery from failure.
Orchestration solves key challenges like:
- Service discovery & load balancing
- Health checks
- Resource scheduling
- Automated rollouts and rollbacks
- Self-healing of applications
- Centralized control over distributed infrastructure
K8s Architecture overview
Control Plane
The Control Plane or (Master Node) controls your K8s cluster, and it consists of multiple components that are responsible for managing that cluster. The main components that form K8s and are related to your control plane are:
- kube-api-server: Interacting with K8s cluster is done through the kube-api-server which is the primary interface to the control plane and the cluster.
- etcd: A key-value store that K8s uses as its data store for the cluster. It is highly available and reliable storage for fast data access and retrieval.
- kube-scheduler: When creating and running containers, kube-scheduler makes sure to select the right available node to run the container.
- kube-controller-manager: Contains multiple logical controllers that handle the state of K8s objects. Some of those controllers are node-controller, job-controller, and service-account-controller.
- cloud-controller-manager: Provides an interface between K8s and different cloud platforms. (only relevant when running on a cloud provider)
Nodes
One or more nodes can be installed, whether it be on-prem or in the cloud, virtual or physical, depending on the cluster. Each node is managed by the control plane, and contains the necessary services to run pods and communicate directly with the control plane. These are made up of:
- kubelet: An agent that runs on each node it communicates with the control plane to ensure that the containers run on the node as required by the control plane. Also, it reports back the state of the running containers to the control plane.
- kube-proxy: A network proxy that runs on each node and that handles network rules on nodes. These network rules allow network communication between your Pods, from network sessions inside or outside of your cluster.
- container runtime: The container runtime is the software that is responsible for running containers: you need to install a container runtime in each node within the cluster so that Pods can run there. K8s supports several container runtimes, the most popular of which are Docker & containerd.
K8S Security
Kubernetes environments are inherently complex with many moving parts. As organizations adopt containerization, they face unique security challenges:
- Dynamic Workloads Pods spin up and down rapidly, making traditional security approaches insufficient
- Shared Responsibility Cloud providers secure infrastructure, but you must secure applications
- Expanded Attack Surface Each component (API server, etcd, kubelet) introduces potential vulnerabilities
- Supply Chain Risks Dependencies and images can introduce vulnerabilities at any stage
3 Kubernetes risks I think matter most
K01: Insecure Workload Configurations
security defaults do not have strong security posture so it is easier for attackers to compromise applications and expand their compromise to other workloads or the cluster control
Here’s what that looks like in practice:
Get The_Witch’s stories in your inbox
Join Medium for free to get updates from this writer.
spec:
containers:
— name: risky-pod
image: nginx
securityContext:
privileged: true
hostPID: true
hostPID: true lets the container see and interact with processes on the host itself
Impact: An attacker can escape the container and gain root access on the host node.
K03: Secrets Management Failures
A common mistake is leaving credentials, passwords, or API keys unhardened. By default, Kubernetes stores secrets in etcd as base64-encoded strings not encrypted. Teams often skip encryption at rest or rotating secrets dynamically, leaving long-lived plaintext-equivalent secrets sitting in the cluster’s datastore.
K07: Misconfigured And Vulnerable Cluster Components
As we mentioned before there are many components therefore, one misconfigured component can compromise or give a lateral movement for an attacker
For example, an exposed kubelet API with no authentication lets an attacker run arbitrary commands on the node
Here’s the rest of the OWASP Kubernetes Top 10 →
Build Phase
So we did get the overview on how the k8s works and some of OWASP Top 10 now we are going to talk about how to build k8s securely
1.Hardening
We mentioned previously that the k8s are inherently complex with many moving parts so firstly we have to
- Minimal Base Images and Their Role
Always choose the images that has the minimum number of components so it reduce the attack surface
- Enforcing Least Privilege Principles
Default configs are not the best practice so we have to change to the least privilege so attacker cannot escalate
2.Managing Open-Source Dependency Risk
- SCA ( SOFTWARE COMPOSITION ANALYSIS )
All the modern or day to day apps/software we use today depend on open source / external libraries which is a vulnerability on its own so the best practice is using SCA ( tools specifically analyze open source dependencies for known issues)
- Dependency Security Management
Mitigating Supply Chain Risks: Use trusted registries and provenance tracking to secure the dependency lifecycle. Trusted registries enforce access controls and metadata standards; provenance documents the origin and build process of dependencies, ensuring they’re legitimate.
3.Securing Build Environments
- Protecting Build Infrastructure
Isolate build infrastructure using ephemeral runners and network restrictions to prevent compromise. Temporary runners reset after each job, reducing persistence risks; network restrictions block unauthorized outbound traffic, limiting lateral movement if a build is compromised.
- Managing Secrets During Build
Secure sensitive data (e.g., API keys, registry credentials) used in the build phase to prevent leaks. Technical Insight: Secrets should be stored in encrypted vaults and injected dynamically, avoiding hardcoding in scripts or configs, which could lead to exposure.
Pre-Deployment
IAC (Infrastructure as Code)
Involves defining infrastructure using code, such as Terraform scripts or Ansible playbooks, to automate the provisioning of resources like Kubernetes clusters, cloud VMs, or networking components. In the Build phase, IaC scripts are prepared and validated to ensure the infrastructure they create (e.g., a Kubernetes cluster for the Flask app) is secure before deployment.
What are risks related to IAC ?
Identify and mitigate risks like misconfigurations or exposed secrets in IaC scripts. Misconfigurations (e.g., overly permissive IAM roles or allowing pods to run as root) or hardcoded secrets in Terraform files can lead to vulnerabilities if not caught early.
Deployment Phase
The Deploy stage is the step in the CI/CD pipeline where containerized applications, built and secured in the Build phase, are deployed into a production environment
How to secure integration into CI/CD ?
1.Static Application Security Testing (SAST)
scanning the source code without running the code catching issues early
2.Dynamic Application Security Testing (DAST)
tests the running app to identify issues that only appear at runtime.
3.Software Composition Analysis (SCA)
(Covered above)
4.Interactive Application Security Testing (IAST)
combines SAST and DAST by analyzing the app as it runs.
Ending
K8S are widely used so securing it is not a luxury anymore especially they are evolving a lot and work on their own so we have to make sure that all the default configurations are changed and hardened secrets are hidden
it may seem alot but every step there is a tool that we can use to save time and effort we can talk about them in another post :)
