Kubernetes has basically become the operating system of the cloud. If you're running containers at scale, you're almost certainly using K8s. It’s powerful, it’s flexible, and it handles orchestration like a dream. But here is the thing: that same power comes with a massive amount of complexity. When you move from a traditional VM-based setup to a containerized orchestration layer, your attack surface doesn't just shift—it expands in directions you might not even be looking at.
Most teams start their Kubernetes journey by following a few basic tutorials, spinning up a cluster on EKS, GKE, or AKS, and deploying their apps. Everything works. Then, they add some namespaces, a few ingress controllers, and maybe some basic Role-Based Access Control (RBAC). It feels secure. But "it works" and "it's secure" are two very different things in the world of cloud-native infrastructure. A single misconfigured YAML file or an over-privileged ServiceAccount can be the difference between a secure production environment and a total cluster takeover.
This is where cloud pentesting comes into play. You can't just run a standard network scanner against a Kubernetes cluster and call it a day. K8s has its own internal networking, its own API server, and its own set of identity management quirks. To actually secure a cluster, you have to think like an attacker. You need to ask: "If I compromise one pod, can I reach the API server? Can I steal a token from the filesystem? Can I move laterally to another namespace?"
In this guide, we're going to dive deep into the reality of securing Kubernetes. We'll move past the generic "use strong passwords" advice and look at the actual attack vectors that keep security engineers awake at night. Most importantly, we'll explore how a cloud-native approach to penetration testing—like what we've built at Penetrify—allows you to find these holes before someone else does.
Understanding the Kubernetes Attack Surface
Before we talk about how to test the cluster, we need to understand what we're actually testing. Kubernetes isn't one single thing; it's a collection of components that all have to talk to each other. If any one of those communication channels is open or improperly authenticated, the whole house of cards can come down.
The Control Plane: The Brain of the Cluster
The control plane is the primary target for any serious attacker. Why? Because if you control the API server, you control everything. The kube-apiserver is the gateway for all administrative tasks. If it's exposed to the public internet without strict authentication, or if there's a vulnerability in the version you're running, an attacker can essentially issue commands to your cluster as if they were the admin.
Then you have etcd. This is the cluster's database. It stores everything—secrets, config maps, and the state of every pod. If an attacker gets access to etcd, they don't even need to talk to the API server; they can just read your secrets directly from the disk.
The Worker Nodes and the Kubelet
The worker nodes are where your actual code runs. The kubelet is the agent running on each node that communicates back to the control plane. A common mistake is leaving the Kubelet API open or allowing unauthenticated access. If I can talk to a Kubelet, I might be able to execute commands inside a pod or even pull sensitive information about the node's environment.
The Pods and Containers
This is the most common entry point. Most attacks start with a vulnerability in the application code—maybe a Log4j-style RCE or a simple SQL injection. Once the attacker is inside a container, they start "pod escaping." They look for ways to get out of the container and onto the underlying host node. From there, they look for the ServiceAccount token usually mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.
The Network Layer (CNI)
Kubernetes networking is often a "flat" network by default. This means that by default, any pod in the cluster can talk to any other pod, regardless of the namespace. If your frontend web server is compromised, it can potentially send requests to your internal payment processing API or your database without any one-stop firewall in between.
Common Kubernetes Misconfigurations That Lead to Breaches
When we do penetration testing at Penetrify, we rarely find "zero-day" vulnerabilities in the Kubernetes core code. Instead, we find "zero-day" mistakes in how the cluster was configured. These are the low-hanging fruits that attackers love.
Over-Privileged RBAC Roles
Role-Based Access Control (RBAC) is the most misunderstood part of K8s security. It's very easy to get frustrated with "Permission Denied" errors during deployment and just give a ServiceAccount the cluster-admin role.
Imagine a simple monitoring pod that only needs to list pods to check their health. If that pod is given cluster-admin permissions and the application inside it is compromised, the attacker now has full control over the entire cluster. They can delete namespaces, steal secrets, and deploy their own malicious pods (like crypto miners).
The "Privileged" Container Trap
Running a container as privileged: true basically tells Kubernetes to disable most of the security boundaries between the container and the host. A privileged container has almost the same access to the host kernel as a process running directly on the node. For a pentester, a privileged container is a golden ticket. It makes escaping to the host trivial, allowing them to access the Docker socket or the Kubelet API.
Exposed Dashboard and API Server
The Kubernetes Dashboard is great for visibility, but it is a nightmare if not secured. We've seen clusters where the dashboard was exposed to the internet with a default service account that had administrative privileges. It's essentially a web-based GUI for destroying your own infrastructure. Similarly, leaving the API server open to 0.0.0.0/0 without MFA or strict IP whitelisting is a recipe for disaster.
Unprotected Secrets
Many teams store "secrets" in Kubernetes Secrets objects. While this sounds right, remember that by default, K8s secrets are only base64 encoded, not encrypted. Anyone with access to the API or the etcd database can decode them in seconds. If you aren't using a dedicated KMS (Key Management Service) or a tool like HashiCorp Vault, your secrets aren't actually secret.
The Cloud Pentesting Workflow for Kubernetes
Traditional pentesting is often a "point-in-time" event: a consultant comes in for two weeks, writes a report, and leaves. But Kubernetes environments change every time you run kubectl apply. You need a more continuous, cloud-native approach to testing.
Phase 1: Reconnaissance and External Mapping
The first step in a cloud pentest is seeing what the world sees. We start by scanning for exposed endpoints.
- Is the API server reachable?
- Is there a Kubelet port (10250) open?
- Are there any exposed dashboards or Prometheus metrics pages?
- Which ingress rules are allowing traffic into the cluster?
Phase 2: Initial Access (The "Footprint")
Once we find an entry point—say, a vulnerable web app—we establish a foothold. This usually involves getting a reverse shell. But once we're in, the goal changes from "attacking the app" to "attacking the cluster."
The first thing a pentester does is check for the ServiceAccount token:
cat /var/run/secrets/kubernetes.io/serviceaccount/token
If that token exists, we can use it to authenticate to the API server from within the pod.
Phase 3: Internal Enumeration and Privilege Escalation
Now we ask: "What can I actually do with this token?" We use tools like kubectl auth can-i --list to see our permissions.
If we have permissions to create pods, we can launch a "malicious" pod that mounts the host's root filesystem. If we have permissions to get secrets, we can dump every password and API key in the namespace. This is where the "chess game" of Kubernetes security happens—moving from a low-privileged pod to a high-privileged node.
Phase 4: Lateral Movement
If the cluster doesn't have Network Policies (the K8s version of a firewall), we can move laterally. We scan the internal pod network to find other services. We might find an unauthenticated Redis cache or an internal database that trusts any connection coming from within the cluster.
Phase 5: Exfiltration and Persistence
The final stage is seeing if we can steal data or maintain access. Can we create a "backdoor" Deployment that restarts itself if deleted? Can we steal the cloud provider's IAM metadata from the node (e.g., accessing 169.254.169.254 on AWS) to move from the Kubernetes cluster into the wider AWS account?
Practical Steps to Hardening Your Cluster
If you've read this far and are thinking, "My cluster might be vulnerable," don't panic. Security is a process of continuous improvement. Here is a practical checklist to move your cluster from "standard" to "hardened."
1. Implement Strict Network Policies
Stop assuming the internal network is safe. By default, implement a "deny-all" policy for both ingress and egress traffic within your namespaces. Then, explicitly allow only the connections that are necessary.
- Pod A should only talk to Pod B on port 8080.
- Pod B should only talk to the Database on port 5432.
- Block all pods from talking to the cloud metadata API unless they absolutely need it.
2. Clean Up Your RBAC
Audit your roles. Stop using cluster-admin for everything.
- Use Namespaced Roles instead of ClusterRoles whenever possible.
- Follow the Principle of Least Privilege (PoLP). If a pod only needs to read a ConfigMap, don't give it the ability to update it.
- Regularly audit who has access to the cluster using tools like
rbac-lookup.
3. Use Pod Security Admissions (PSA)
Stop allowing privileged containers. Kubernetes has built-in Pod Security Admissions that allow you to enforce different levels of security:
- Privileged: Unrestricted (basically "do whatever you want"). Avoid this in production.
- Baseline: Prevents known privilege escalations.
- Restricted: Enforces a very high security standard (no root users, no host network access).
Aim for the restricted profile for all your application workloads.
4. Secure Your Secrets
Move away from base64-encoded K8s secrets.
- Enable Encryption at Rest for your
etcddatabase. - Use a cloud-native secret manager. For example, use the AWS Secrets Manager or Azure Key Vault and integrate them with your pods using the Secret Store CSI Driver. This ensures that secrets are injected into the pod at runtime and never stored as plain text in the K8s API.
5. Keep Your Components Updated
This sounds basic, but it's where many breaches happen. Vulnerabilities in the kube-apiserver or kubelet are patched quickly, but if you're running a version from two years ago, you're an easy target. Automate your cluster upgrades to stay current with the latest security patches.
A Comparison: Manual Pentesting vs. Automated Scanning vs. Cloud-Native Platforms
Many people ask: "Can't I just run a vulnerability scanner?" The answer is yes, but a scanner is not a pentest. Here is the difference.
| Feature | Automated Vulnerability Scanner | Traditional Manual Pentest | Cloud-Native Platform (Penetrify) |
|---|---|---|---|
| Scope | Finds known CVEs in packages. | Deep dive into logic and config. | Combines CVE scanning with config analysis. |
| Context | Doesn't understand RBAC or network flow. | Understands context but is slow. | Maps the attack surface in real-time. |
| Frequency | Can run daily. | Once or twice a year. | Continuous and on-demand. |
| Actionability | Gives a long list of "potential" bugs. | Gives a detailed report. | Provides remediation paths and integrates with SIEM. |
| Cost | Low to Moderate. | High (Consultant fees). | Scalable subscription. |
scanners are great for finding a version of Nginx that has a bug. But a scanner won't tell you that your RBAC policy allows a developer's pod to delete your production database. A manual pentester will find that, but they are expensive and can't be everywhere at once.
A platform like Penetrify bridges this gap. It uses cloud-native architecture to simulate these attacks automatically and consistently, giving you the depth of a pentest with the speed of a scanner.
Advanced Scenario: The "Pod-to-Cloud" Escape
To really understand why cloud pentesting is different, let's look at a realistic attack scenario. This is a common path we find during assessments.
Step 1: The Entry An attacker finds a Server-Side Request Forgery (SSRF) vulnerability in a public-facing Django application running in a Kubernetes pod.
Step 2: The Metadata Hit
The attacker uses the SSRF to hit the cloud provider's metadata endpoint: http://169.254.169.254/latest/meta-data/iam/security-credentials/. Because the node's IAM role is over-privileged, the attacker retrieves a temporary AWS access key.
Step 3: Scanning the Account
Using those keys, the attacker realizes they have S3:ListBucket and S3:GetObject permissions for the entire AWS account. They find a bucket containing production database backups.
Step 4: The Cluster Takeover
While digging through the S3 bucket, they find a backup of a kubeconfig file that was accidentally uploaded. This file contains a certificate for a cluster-admin user.
Step 5: Total Control
The attacker uses the kubeconfig to connect to the API server from their own laptop. They now have absolute power over the cluster. They deploy an encrypted tunnel (like Ngrok) inside the cluster to maintain a permanent backdoor, bypassing all perimeter firewalls.
The Lesson? The vulnerability wasn't just in the Django app. It was a chain: SSRF $\rightarrow$ Over-privileged Node IAM $\rightarrow$ Leaked Secret in S3 $\rightarrow$ Admin Kubeconfig. a simple pod scanner would have only found the Django vulnerability; it wouldn't have shown you that your entire AWS account was at risk.
Integrating Security into the CI/CD Pipeline (DevSecOps)
You can't just "do" security at the end. By the time a pentester finds a hole in your production cluster, the damage (or the cost of fixing it) is already high. You have to move security "left."
Shift-Left Testing
Integrate security checks into your GitLab or GitHub pipelines.
- Static Analysis (SAST): Scan your Dockerfiles for "USER root" and your YAML files for
privileged: true. - Image Scanning: Use tools to ensure your base images don't have known CVEs before they ever reach the registry.
- Policy as Code: Use OPA (Open Policy Agent) or Kyverno. These tools act as admission controllers. If a developer tries to deploy a pod that doesn't have resource limits or is running as root, the cluster simply rejects the deployment.
The Feedback Loop
The real magic happens when you connect your pentesting results back to your development cycle. When a platform like Penetrify identifies a misconfiguration in your development cluster, that insight should automatically create a ticket in Jira for the team to fix.
Security shouldn't be a "gate" that stops deployment; it should be a "guardrail" that guides deployment. When developers know exactly why a certain configuration is dangerous (because a pentest simulated an attack and proved it), they are much more likely to write secure code from the start.
Common Mistakes When Securing Kubernetes
Even experienced teams trip up on these. If you're managing a cluster, check if you're doing any of these things.
Mistake 1: Trusting the "Cloud Managed" Label
Many people assume that because they use EKS or GKE, Google or Amazon is handling the security. While the cloud provider secures the control plane (the master nodes), you are still responsible for the data plane (your worker nodes, your pods, and your network policies). The "Shared Responsibility Model" is real. If you leave your API server open, AWS isn't going to stop an attacker from entering.
Mistake 2: Ignoring the "Default" Namespace
The default namespace is often a dumping ground for tests and random pods. Many teams forget to apply the same strict RBAC and network policies to the default namespace as they do to production. An attacker who gets into a "test" pod in the default namespace can often use it as a jumping-off point to attack other parts of the cluster.
Mistake 3: Over-Reliance on Image Scanning
Scanning an image for CVEs is important, but it's not enough. An image can have zero known vulnerabilities but still be configured to run as root with full access to the host's PID namespace. You have to secure the runtime configuration, not just the binary.
Mistake 4: Failing to Log and Monitor
You can't stop an attack you can't see. Many teams forget to enable Kubernetes Audit Logs. Audit logs tell you who did what, when, and how. Without them, if an attacker steals a token and creates a backdoor, you'll have no record of how it happened.
FAQ: Securing Kubernetes with Cloud Pentesting
Q: How often should I perform a penetration test on my Kubernetes cluster? A: It depends on your change frequency. If you push code daily, a once-a-year pentest is useless. You should have automated scanning daily and deep-dive pentesting every quarter or after every major architectural change. Cloud-native platforms allow for "continuous pentesting," which is the gold standard.
Q: Do I need to install agents on my nodes for cloud pentesting? A: Not necessarily. Many modern platforms, including Penetrify, use a combination of API-based scanning and controlled "attacker pods" to simulate threats without needing to install invasive agents on every single node. This reduces the performance overhead and the security risk of the testing tool itself.
Q: Can pentesting break my production cluster? A: There is always a risk with any active testing. This is why we recommend testing in a staging environment that mirrors production. However, professional cloud pentesting tools are designed to be non-destructive. They look for "proof of concept" access (like reading a file) rather than performing "denial of service" attacks.
Q: What is the difference between a vulnerability scan and a pentest? A: A scan is like a home security system that checks if the doors are locked. A pentest is like hiring someone to actually try and break into your house. The scanner tells you the door might be open; the pentester actually walks through the door and tells you they can reach your jewelry box in the bedroom.
Q: Is RBAC enough to secure a cluster? A: No. RBAC is just one layer. You also need Network Policies (to stop lateral movement), Pod Security Admissions (to stop escapes), and Secret Management (to protect sensitive data). Think of it as "defense in depth."
Final Takeaways and Next Steps
Securing Kubernetes isn't about checking a single box; it's about reducing the "blast radius." You have to assume that at some point, a pod will be compromised. The goal is to make sure that when that happens, the attacker finds themselves in a locked room with no keys and no way to talk to the rest of the house.
If you're feeling overwhelmed, start with these three immediate actions:
- Audit your RBAC: Find every ServiceAccount with
cluster-adminand figure out if it actually needs it. (Hint: It probably doesn't). - Enable Network Policies: Start by blocking all egress traffic from your pods to the cloud metadata API (
169.254.169.254). - Run a real test: Stop guessing if you're secure. Use a tool or a service to actually simulate an attack.
The complexity of Kubernetes is its greatest strength, but also its greatest weakness. The only way to truly know your posture is to test it under real-world conditions.
If you want to stop guessing and start knowing, Penetrify can help. We provide the cloud-native infrastructure to run professional-grade security assessments without the massive overhead of traditional consulting. We help you find the gaps in your RBAC, the holes in your network policies, and the paths to privilege escalation before a malicious actor does.
Don't wait for a breach to find out your "secure" cluster had a wide-open door. Visit Penetrify.cloud today and get a clear, actionable view of your security posture.