Ever woken up in a cold sweat, realizing every single pod in your cluster is mining Bitcoin without your permission and your cloud bill has officially surpassed your company’s valuation? If you haven't, you're either incredibly lucky or you just haven't met that 'critical' misconfiguration yet.
Hey there, I'm Sedat. Today, we’re going to step into the shiny, flexible, and utterly chaotic labyrinth of Kubernetes (K8s). But we're not just bringing a flashlight; we’re looking at it through the eyes of a Red Teamer.
When we dive into the world of K8s, we all fall in love with that massive scalability. But when it comes to security, the 'let me just copy-paste this YAML and hope it works' mentality usually wins. Well, let me tell you—that copy-pasted YAML might just be your cluster's death warrant.
Kube-API Server: The Gateway to Your Kingdom
In the K8s world, the API Server is everything. If you aren't protecting this properly, you’re basically leaving the keys in the ignition with the door wide open. When I’m trying to breach a cluster as a Red Teamer, the first things I check are ports 6443 or 8443 at https://example-cluster.com. If 'Anonymous Authentication' is enabled, my life gets a whole lot easier.
Imagine what I could learn about your cluster with just this simple command:
# Defanged example query
curl -k https://127.0.0.1:6443/api/v1/namespaces/default/pods
If this command dumps a list of pods instead of returning a 'Forbidden' error, well, game over. I'm in. The fix? Start by adding the --anonymous-auth=false flag to your API Server configuration. It’s that simple, yet that critical.
RBAC: Who Has Their Hand in Whose Pocket?
Role-Based Access Control (RBAC) is the heart of K8s security, but it’s also the most misunderstood part. The biggest mistake I see in the field is giving cluster-admin privileges to every microservice or CI/CD tool. It’s like giving the janitor the master key to every single room in the building.
I once audited a project for testCompany and noticed a pod's service account had unnecessary permissions to read secrets. The moment I compromised that pod (which is easy enough with an RCE vulnerability), I pulled every database password in the cluster.
Here’s an example of bad RBAC (Don't do this!):
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: the-do-everything-role
rules:
- apiGroups: [""]
resources: ["*"]
verbs: ["*"] # This 'all access' point is where it all ends
Instead, follow the principle of 'Least Privilege.' Only give the permissions that are absolutely necessary. Does the pod only need to read a configmap? Then only give it that.
Network Policies: The 'Default-Allow' Disaster
By default in K8s, every pod can talk to every other pod. What does that mean? Your frontend pod can reach out directly to your payment system pod and say, 'Hey, how's it going?' If an attacker takes over the frontend, they can scan your entire cluster (lateral movement).
If you haven't defined a NetworkPolicy, your internal network traffic is no different than a crowded bazaar. You should apply a 'default-deny' policy for every namespace to shut everything down, and then open only what's needed.