Kubernetes Pivot Off Service Token

Introduction⌗

This is a very quick blog post that talks about AutomountServiceAccountToken. These two blog posts inspired some of my research into Kubernetes, but even then they briefly cover service account tokens and their misuse:

• https://hackersvanguard.com/abuse-kubernetes-with-the-automountserviceaccounttoken/
• The DUCTF2020 infrastructure write-up includes a nice nod to this attack being seen in the wild https://link.medium.com/LFIpI9pjrwb.

Kuber-what-now?⌗

I have a nice introductory post that covers some of the basics of Kubernetes and can help you spin up a test cluster.

Takeaways⌗

The main takeaways for this blog post are:

• AutomountServiceAccountToken is a rarely talked about and (enabled by default) dangerous feature
• There are platform specific considerations for service accounts
• We (as penetration testers) can use these tokens to pivot to different levels of access (depending on the access of the service account of course)

Service Account Tokens⌗

What is AutomountServiceAccountToken?⌗

The automountServiceAccountToken field, enabled to true by default, mounts the namespace’s default service account into the /var/run/secrets/kubernetes.io/serviceaccount/ directory.

This allows pods to have base-level permissions that can query information from the cluster. Pods can also be configured to use the non-default service account, but this is usually only in cases where pods require some sort of cluster management or logging privileges.

The official Kubernetes documentation briefly mentions the parameter, and never discusses its security considerations. In fact, although it seems to be generally¹² considered a risky permission by in-the-know administrators, it’s very rarely discussed or mentioned outside of specific hardening guides and documents.

Patching⌗

Users can explicitly disable the feature by adding this line to the specification of every single Pod, ReplicaSet, DaemonSet and Deployment (how easy 🤦‍♂️):

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  automountServiceAccountToken: false

This is similar to how administrators are expected to configure safe securityContexts and resource limits.

Google Cloud Platform⌗

GKE service accounts are very confusingly documented, but the wording gives me worry:

https://cloud.google.com/kubernetes-engine/docs/how-to/service-accounts#default-gke-service-agent

Let me know if I’m misunderstanding this one :).

Pivot Time⌗