Hey team, Sedat here. Grab your coffee; today we’re going to stir things up a bit and put our beloved conductor, Kubernetes (K8s), on the operating table.
There’s a massive K8s craze in the industry right now. 'Let’s containerize everything, deploy it on K8s, and scale it.' Sounds great, but what about security? That’s where things get messy. For most dev and ops teams, Kubernetes is a black box that magically solves everything. But in the kitchen—on the Red Team side—we see every day how those tiny 'default' settings turn into absolute disasters.
That Famous Critique: Helm Install and the 'It Won't Happen to Me' Mentality
Let me dive straight into the deep end: Using popular Helm Charts you find on the internet just because they have a lot of stars is, quite frankly, madness. Yeah, you heard me right. The moment you run helm install x-tool, if you aren't checking which permissions are granted to which ServiceAccount or which pod is accessing the host's file system, you're essentially handing the keys to your system to a stranger. Don't say 'but thousands of people use it'—supply chain attacks are built exactly on that 'trust.'
1. RBAC: The 'Make Everyone Admin So We Can Work Faster' Disaster
One of the most common vulnerabilities I encounter in the K8s world is over-privileging in Role-Based Access Control (RBAC) configurations. Usually, the scenario goes like this: A monitoring tool needs to be installed, it throws a 'Permission Denied' error, and suddenly someone slaps a * (wildcard) into the ClusterRole just to get it moving.
Look, if a pod has the permission to read secrets and that pod is exposed to the internet (like a web app), an attacker who compromises that pod can harvest all the database passwords and API keys in the entire cluster and walk away.
Defanged Bad Example (Bad RBAC):
# THIS IS A SECURITY RISK, DO NOT USE!
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: monitoring-role-bad
rules:
- apiGroups: [""]
resources: ["*"] # Access to everything!
verbs: ["get", "list", "watch"]
Instead, you must always act with the 'Least Privilege' principle. Give only the necessary verb to only the necessary resource.
2. Container Escape: The Breakout Plan
If you think 'I'm in a container, I'm safe,' you're mistaken. If your pod is running with privileged: true or mounting critical host paths, that container is nothing but a paper tiger.
Specifically, when /var/run/docker.sock (or similar sockets in modern runtimes) is mounted via hostPath, an attacker can break out of the container and gain root privileges directly on the host machine. This is our favorite 'pivot' point during Red Team operations.
Defanged Risky Pod Definition:
# WARNING: Leads to host escape risk!
spec:
containers:
- name: test-container
image: example.com/app:latest
securityContext:
privileged: true # NEVER IN PROD
volumeMounts:
- mountPath: /host/var/run/docker.sock
name: docker-sock
volumes:
- name: docker-sock
hostPath:
path: /var/run/docker.sock
Stay safe, double-check your YAMLs, and remember: if you don't secure your conductor, the whole orchestra will play the wrong tune.