The obvious answer is: It’s a container orchestrator, but is it just that? To me, it’s a software-driven data center with an api for container workloads. As a data center has many aspects that need to be secured, Kubernetes security has many facets like cluster security, api security, container security, software, and library vulnerabilities.
Let’s assume that an attacker is able to access an application on the Kubernetes cluster with a vulnerability that allows remote execution. With this remote execution, the attacker can find out by running a hand full of commands OS of the container, that docker and Kubernetes is running on the host system. Once this information is available the attacker can now try to access the ServiceAccount token.
So what is the ServiceAccount token? ServiceAccount provides an identity for the processes running within Kubernetes to authenticate to Kubernetes api server internally using a ServiceAccount token. A Kubernetes installation has a ServiceAccount called default that gets associated with every pod that’s scheduled, and the service account tokens are mounted into the pod as secret.
Now that attacker can read the mounted secret under /var/run/secrets/kubernetes.io/serviceaccount to make a call to the Kubernetes api server and start listing the pods, reading other secrets and config maps if the service account has more privileges than needed or the associated role to the service account has more permissions.
Thanks for reading this.
Sources: Webinar: Kubernetes Security Best Practices – Ian Lewis, Google