Kubernetes and Cloud Native Security Associate (KCSA)
Kubernetes Threat Model
Compromised Applications in Containers
Containers are designed to isolate applications, but a single compromised app can lead to full container takeover—and ultimately threaten your entire Kubernetes cluster. In this lesson, we explore how vulnerabilities and misconfigurations enable attackers to pivot from application-level flaws to cluster-wide breaches.
Attack Scenario
An attacker exploits a vulnerability in your application or backend service to gain shell access inside a container. From this foothold, they move laterally to compromise other resources in the cluster.
Compromised-Container Attack Tree
Attack Vector | Description |
---|---|
Poisoned Images | Inject malicious code into a container image and push the poisoned image to your registry. |
Repository Breach | Gain unauthorized access to your image repository, pull down images, and harvest secrets or vulnerabilities. |
Data Exfiltration | Extract sensitive data—API tokens, database credentials, environment variables—or deploy ransomware against connected data stores. |
Privilege Escalation | Abuse service account tokens or other credentials to interact with the Kubernetes API: list secrets, modify ConfigMaps, or create new resources. |
Credential and Secret Misuse
Attackers often exploit misconfigured Kubernetes secrets and image-pull credentials:
- Pull-only secrets misconfigured for push
An image-pull secret accidentally granted push permissions lets attackers upload malicious images to your registry.
Warning
Misconfigured secrets can grant attackers both pull and push access to your container registry. Always follow the principle of least privilege.
Extracting secrets from Kubernetes
By deploying a malicious pod that mounts existing secrets, attackers gain immediate access to environment variables and service tokens.Attaching to a running container
If RBAC allows, an attacker can execute a shell inside a live pod and inspect its environment:kubectl exec -it <pod-name> -- /bin/sh
This command exposes all mounted secrets and tokens visible in the container’s filesystem and env vars.
Escalation via the Kubernetes API
With a valid service account or user token in hand, attackers can abuse the Kubernetes API:
- List and read Secrets
kubectl get secrets --all-namespaces
- Inspect or modify ConfigMaps, Pods, Deployments, and Services
- Create or delete resources to maintain persistence
- Potentially escalate to cluster-admin by exploiting overly permissive RBAC rules
By chaining these steps—container compromise, secret extraction, and API abuse—attackers move laterally across your cluster, accessing more sensitive data and resources.
Best Practices for Prevention
Practice | Description |
---|---|
Use Minimal Base Images | Reduce OS-level vulnerabilities with lightweight, well-maintained images (e.g., distroless). |
Enforce Image Signing | Scan and sign images using tools like Notary or Cosign before deployment. |
Rotate Secrets Regularly | Automate secret rotation and avoid long-lived credentials. |
Apply Least-Privilege RBAC | Grant each service account only the permissions it needs. |
Implement Network Policies | Segment pod communication and limit egress to the Kubernetes API server. |
Note
Regularly audit your cluster and registries to detect unauthorized changes. Consider tools like Kube-bench and Clair for ongoing security assessments.
Links and References
- Kubernetes Security Best Practices
- Docker Image Security
- HashiCorp Vault for centralized secret management
Watch Video
Watch video content