Whilst spending some more time looking at Kubernetes, to help out with the forthcoming CIS Security standard, I was looking at cluster component authentication and noticed something that might not be known by everyone using Kubernetes, so I thought it’d be worth a post.
When pods are deployed to a cluster, in most default installs, the Admission Contoller will run and take a set of pre-defined actions before the pods go live. One of those actions is to mount a Service Account inside the containers that make up the pod.
This service account includes a token which is mounted at a predictable location /var/run/secrets/kubernetes.io/serviceaccount/token .
What’s interesting is that, by default unless RBAC is deployed, it’s likely that this token provides cluster admin privileges.
This means that any attacker with access to a container can, fairly easily, get full access to the cluster API (in fact it’s kind of easier than the kubelet exploit ).
If you want to check this to see if it affects your cluster, just run a pod inside the cluster, attach to one of the containers, get a copy of kubectl and point it at your API Server with something like
./kubectl config set-cluster test --server=https://[API_SERVER_IP]:[API_SERVER_PORT]
then try out some kubernetes commands…
Fortunately this issue has been addressed with Kubernetes 1.6 setups which make use of the default RBAC policy, so if you’re concerned about container breakout scenarios, I’d thoroughly recommend upgrading and making sure that you’re using a restrictive RBAC policy.
