In March 2023, Dero cryptocurrency miners hijacked thousands of Kubernetes clusters by exploiting a single misconfiguration: anonymous authentication enabled on the API server. The attackers didn't need to break container isolation or exploit application vulnerabilities. They walked straight through an open door at the cluster layer.
This attack illustrates a principle that experienced security professionals understand intuitively: security is only as strong as your weakest layer. You can run the most secure containerized application in the world, but if your cluster accepts anonymous requests, none of that container security matters.
Kubernetes security isn't about deploying a single tool or enabling a single feature. It's about understanding that your application exists within layers—each layer providing distinct protections, each layer depending on the layers surrounding it.
The Cloud Native Computing Foundation (CNCF) formalizes Kubernetes security as four concentric layers, each wrapping the previous:
Think of these layers like the walls of a castle:
The key principle: Outer layers must be secure before inner layers matter. A perfectly secure container means nothing if the cluster allows anonymous API access.
The outermost layer is your cloud infrastructure. For Docker Desktop Kubernetes, this layer is minimal because you control the physical machine. In production cloud environments (AWS, Azure, GCP), this layer includes:
Task API Example (Cloud Layer):
Your Task API runs on Docker Desktop Kubernetes for development. In production, you would:
Why It Matters: If your cloud account is compromised, attackers control everything—they can delete clusters, exfiltrate data, or spin up cryptocurrency miners on your bill.
The cluster layer secures Kubernetes itself: the API server, nodes, and communication between pods.
Task API Example (Cluster Layer):
Your Task API needs cluster-layer security:
Why It Matters: The Dero mining attack exploited cluster-layer weaknesses. RBAC and NetworkPolicies would have stopped it.
The container layer protects your running application through image security and runtime constraints.
Task API Example (Container Layer):
Your Task API Deployment should include:
Why It Matters: Container escapes are real. The runAsNonRoot and capabilities: drop: ["ALL"] settings significantly reduce attack surface.
The innermost layer is your application code—the logic you write and the dependencies you include.
Task API Example (Code Layer):
Your FastAPI application should:
Why It Matters: Even with perfect infrastructure security, code vulnerabilities let attackers extract data or execute arbitrary commands.
Imagine pouring water through four stacked buckets. Each bucket has some holes (vulnerabilities). The water (attacks) passes through any hole it finds.
Critical insight: Patching holes in the bottom bucket (Code) doesn't matter if the top bucket (Cloud) is completely missing.
Real-world example: The Dero attack could have been stopped at:
Here's a complete security map for the Task API you'll secure throughout this chapter:
By Lesson 9, every row shows "Implemented" or "Covered."
Test your understanding by classifying these 10 security controls. For each, identify which layer (Cloud, Cluster, Container, or Code) it belongs to:
Score yourself: 9-10 correct = Excellent. 7-8 = Good. Below 7 = Review the layer definitions above.
In Chapter 1, you created a cloud-security skill. Now evaluate it against the 4C model:
Questions to consider:
Try this test:
If your skill:
What's missing? Make a note. You'll improve your skill throughout this chapter.
What you're learning: The dependency between layers—how ignoring Cluster security undermines Container and Code protections.
What you're learning: Layer classification isn't always obvious—some controls span layers or could be implemented at multiple layers.
What you're learning: Practical application of 4C to your specific context—balancing security rigor with development velocity.
The 4C model is a framework for understanding, not a guarantee of security. Implementing controls at every layer is necessary but not sufficient. Security requires ongoing monitoring, patching, and threat modeling. Start with the outer layers (Cloud, Cluster) before investing in inner layers (Container, Code).