Skip to main content
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 VectorDescription
Poisoned ImagesInject malicious code into a container image and push the poisoned image to your registry.
Repository BreachGain unauthorized access to your image repository, pull down images, and harvest secrets or vulnerabilities.
Data ExfiltrationExtract sensitive data—API tokens, database credentials, environment variables—or deploy ransomware against connected data stores.
Privilege EscalationAbuse service account tokens or other credentials to interact with the Kubernetes API: list secrets, modify ConfigMaps, or create new resources.
The image is a flowchart titled "Compromised Container Attack Tree," illustrating various attack vectors and methods for compromising container environments, such as pushing poisoned images, exfiltrating data, and performing ransomware attacks.

​
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.
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

PracticeDescription
Use Minimal Base ImagesReduce OS-level vulnerabilities with lightweight, well-maintained images (e.g., distroless).
Enforce Image SigningScan and sign images using tools like Notary or Cosign before deployment.
Rotate Secrets RegularlyAutomate secret rotation and avoid long-lived credentials.
Apply Least-Privilege RBACGrant each service account only the permissions it needs.
Implement Network PoliciesSegment pod communication and limit egress to the Kubernetes API server.
Regularly audit your cluster and registries to detect unauthorized changes. Consider tools like Kube-bench and Clair for ongoing security assessments.

Watch Video