KCSA — The 4Cs of Cloud Native Security
What Are the 4Cs of Cloud Native Security?
The 4Cs of Cloud Native Security is the foundational security model recommended by the Kubernetes project itself. It describes four concentric layers, each building on the one beneath it:
- Cloud — the outermost layer (infrastructure, cloud provider)
- Cluster — the Kubernetes cluster itself
- Container — the container images and runtime
- Code — the application code running inside containers
The key idea is simple: each layer depends on the security of the layer below it. If your cloud infrastructure is compromised, no amount of RBAC or image scanning will save you. If your code has a critical vulnerability, a perfectly configured cluster can’t prevent exploitation.
This is the principle of defense in depth — you don’t rely on a single security boundary. You secure every layer.
The Castle Analogy
Think of cloud native security like protecting a medieval castle:
| Layer | Castle Analogy | Cloud Native Equivalent |
|---|---|---|
| Cloud | The kingdom’s borders — walls, moats, guarded roads | Cloud provider infrastructure, VPCs, firewalls |
| Cluster | The castle itself — gates, drawbridges, watchtowers | API server, etcd, RBAC, network policies |
| Container | Individual rooms with their own locks | Container images, runtime security, resource limits |
| Code | The valuables inside the safes | Application logic, secrets handling, dependencies |
An attacker must breach the outer walls before reaching the castle, then get past the locks on the rooms, and finally crack the safes. Each layer adds friction and reduces the blast radius of an attack.
Visual Model — The 4Cs Layers
┌─────────────────────────────────────────────────┐
│ CLOUD │
│ (Infrastructure, VPC, IAM, Cloud Provider) │
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ CLUSTER │ │
│ │ (API Server, etcd, RBAC, Networking) │ │
│ │ │ │
│ │ ┌─────────────────────────────────┐ │ │
│ │ │ CONTAINER │ │ │
│ │ │ (Images, Runtime, Isolation) │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────────────┐ │ │ │
│ │ │ │ CODE │ │ │ │
│ │ │ │ (App Logic, Deps, │ │ │ │
│ │ │ │ Secrets, Libraries) │ │ │ │
│ │ │ └─────────────────────────┘ │ │ │
│ │ │ │ │ │
│ │ └─────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────┘
Each inner layer inherits the security (or insecurity) of the layers that surround it.
Layer 1 — Cloud (Infrastructure)
The Cloud layer is your foundation. It includes everything the cloud provider manages plus the infrastructure choices you make.
Key Security Concerns
| Concern | Description |
|---|---|
| Shared Responsibility | The cloud provider secures the infrastructure; you secure what you deploy on it |
| IAM | Identity and Access Management — who can do what in your cloud account |
| Network Isolation | VPCs, subnets, security groups, firewalls |
| Encryption | Data encryption at rest (disk) and in transit (TLS) |
| Physical Security | Data center access, hardware — handled by the provider |
| Compliance | Regional data residency, certifications (SOC 2, ISO 27001) |
Shared Responsibility Model
This is a critical concept for the KCSA exam.
| Responsibility | Cloud Provider | You (Customer) |
|---|---|---|
| Physical data centers | ✅ | ❌ |
| Hypervisor / host OS | ✅ | ❌ |
| Network infrastructure | ✅ | ❌ |
| IAM configuration | ❌ | ✅ |
| Kubernetes cluster config | ❌ (partially ✅ in managed K8s) | ✅ |
| Application security | ❌ | ✅ |
| Data encryption config | ❌ | ✅ |
| OS patching (worker nodes) | ❌ (partially ✅ in managed K8s) | ✅ |
| Network policies | ❌ | ✅ |
With managed Kubernetes (EKS, AKS, GKE), the provider takes on some cluster-level responsibilities like the control plane. But you’re always responsible for your workloads, RBAC, network policies, and application security.
What If This Layer Is Breached?
If an attacker compromises your cloud account (e.g., leaked AWS root credentials), they can:
- Delete or modify your entire cluster
- Access all data in storage buckets and databases
- Spin up crypto-mining instances on your bill
- Pivot to other services in your cloud environment
Impact: Catastrophic. Everything above this layer is compromised.
Layer 2 — Cluster
The Cluster layer is about securing the Kubernetes cluster itself — the control plane, worker nodes, and the communication between them.
Key Security Concerns
| Concern | Description |
|---|---|
| API Server Access | The front door to your cluster — must be restricted and authenticated |
| etcd Encryption | etcd stores all cluster state including Secrets — must be encrypted at rest |
| RBAC | Role-Based Access Control — limit who can do what inside the cluster |
| Network Policies | Control Pod-to-Pod and Pod-to-external traffic |
| Admission Controllers | Intercept and validate/mutate requests before persistence |
| Audit Logging | Record who did what and when in the cluster |
| Node Security | Harden the OS, restrict SSH, apply CIS benchmarks |
Critical Cluster Security Controls
- Disable anonymous authentication to the API server
- Enable audit logging so you can investigate incidents
- Encrypt etcd at rest — by default, Secrets are stored in plaintext in etcd
- Use RBAC with least-privilege Roles — never grant
cluster-adminbroadly - Apply network policies — by default, all Pods can talk to all other Pods
- Rotate certificates regularly
What If This Layer Is Breached?
If an attacker gains cluster-admin access:
- They can read all Secrets (database passwords, API keys)
- Deploy malicious workloads (crypto miners, reverse shells)
- Modify or delete existing deployments
- Potentially escape to the node and then to the cloud layer
Impact: Severe. All containers and code in the cluster are at risk.
Layer 3 — Container
The Container layer focuses on securing the container images you build and the runtime environment they execute in.
Key Security Concerns
| Concern | Description |
|---|---|
| Base Image Selection | Use minimal, trusted base images (distroless, Alpine) |
| Image Scanning | Scan images for known vulnerabilities (CVEs) before deployment |
| Image Signing | Cryptographically sign images to verify authenticity |
| Immutable Images | Reference images by digest, not mutable tags |
| Runtime Security | Monitor container behavior at runtime for anomalies |
| Resource Limits | Set CPU/memory limits to prevent resource abuse |
| Read-Only Filesystem | Prevent containers from writing to the filesystem where possible |
| Non-Root Users | Run containers as non-root to limit privilege escalation |
Container Security Checklist
- ✅ Use minimal base images (fewer packages = fewer vulnerabilities)
- ✅ Scan images in CI/CD with tools like Trivy or Grype
- ✅ Sign images with cosign and verify before deployment
- ✅ Reference images by digest (
sha256:...), not just tags - ✅ Set
runAsNonRoot: truein the Pod security context - ✅ Apply resource limits to every container
- ✅ Use read-only root filesystem where possible
- ✅ Drop all Linux capabilities and add back only what’s needed
What If This Layer Is Breached?
If a container image has a known vulnerability that gets exploited:
- The attacker gains a foothold inside the container
- They might escalate privileges if the container runs as root
- They could access Secrets mounted into the container
- From there, they may try to escape the container to the node
Impact: Significant. The scope depends on how well the cluster layer restricts lateral movement.
Layer 4 — Code
The Code layer is the innermost layer — your actual application source code and its dependencies.
Key Security Concerns
| Concern | Description |
|---|---|
| Dependency Management | Track and update third-party libraries; scan for known vulnerabilities |
| Secrets Handling | Never hardcode secrets; use Kubernetes Secrets or external vaults |
| Input Validation | Prevent injection attacks (SQL injection, XSS) |
| Secure Communication | Use TLS for all service-to-service communication |
| Least Privilege | Application should request only the permissions it needs |
| SBOM | Generate a Software Bill of Materials for transparency |
Common Code-Level Security Mistakes
| Mistake | Risk | Fix |
|---|---|---|
| Hardcoded secrets in source | Credential leakage via Git | Use environment variables or Secret managers |
| Outdated dependencies | Known CVEs exploitable | Automate dependency updates (Dependabot, Renovate) |
| No input validation | Injection attacks | Validate and sanitize all user input |
| HTTP instead of HTTPS | Man-in-the-middle attacks | Enforce TLS everywhere |
| Overly permissive service accounts | Privilege escalation | Apply least-privilege principle |
| No SBOM generated | No visibility into dependencies | Generate SBOM with Syft or Trivy |
What If This Layer Is Breached?
If the application code is vulnerable (e.g., a Log4Shell-style vulnerability):
- An attacker can execute arbitrary code inside the container
- They can steal data the application has access to
- They may pivot to other services using the app’s network access or credentials
Impact: High. But a well-secured container and cluster layer can contain the blast radius.
How Attacks Propagate Across Layers
Attacks don’t stay in one layer — they move inward or outward:
Code vulnerability exploited
↓
Container escape (if running as root, no seccomp, etc.)
↓
Node compromise (access to kubelet, other Pods)
↓
Cluster-wide access (if RBAC is too permissive)
↓
Cloud account compromise (if node has overprivileged IAM role)
This is exactly why defense in depth matters. Each layer is a speed bump that slows down or stops the attacker.
A breach at the Code layer doesn’t have to become a cloud account compromise — but it will if the other layers are misconfigured.
Defense in Depth — Mapped to the 4Cs
| Defense Strategy | Which Layer? | Example |
|---|---|---|
| VPC and firewall rules | Cloud | Restrict API server access to corporate IP range |
| IAM least-privilege | Cloud | Node IAM role can only access its own S3 bucket |
| RBAC | Cluster | Developers get view role, not cluster-admin |
| Network policies | Cluster | Frontend Pods can’t talk to the database directly |
| Admission controllers | Cluster | Block images from untrusted registries |
| Image scanning | Container | CI pipeline fails if critical CVEs are found |
| Non-root containers | Container | runAsNonRoot: true in security context |
| Dependency scanning | Code | Dependabot alerts for vulnerable libraries |
| Secrets management | Code | Use HashiCorp Vault instead of hardcoded passwords |
Key Takeaways for the Exam
- The 4Cs are Cloud → Cluster → Container → Code — from outermost to innermost
- Each layer depends on the one below it — a secure Code layer can’t compensate for a compromised Cloud layer
- Defense in depth = securing every layer, not just one
- The shared responsibility model defines what the cloud provider secures vs. what you secure
- Container security = minimal images + scanning + signing + non-root + resource limits
- Code security = dependency management + secrets handling + input validation + SBOM
- The exam will ask you to identify which layer a given security control belongs to — practice mapping controls to layers
The 4Cs model isn’t just a nice framework — it’s the organizing principle for almost everything else on the KCSA exam. Master this, and the rest of the security topics will make much more sense.
Next up: Cloud Provider & Infrastructure Security — a deeper dive into the outermost “C” and the shared responsibility model.
