Let me start by: What is Kubernetes? 

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.

 

In this blog, I’d like to discuss cluster security; the attacker attacking the Kubernetes cluster and how it can be mitigated.

 

Scenario:

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.

 

Explanation:

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.

 

Exploitation:

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.

 

Remediations:

• Having ServiceAccount associated with Cluster Roles with the least privileges and restricted to a namespace can mitigate access to the api server and seeing other secrets and pods info.

• Having a separate ServiceAccount per deployment with the minimum set of privileges to work is a good practice.

• Setting up Network Policy for the pod with restrictions to not send requests to pods it doesn’t communicate is another remediation from cluster-wide exploitation.

• Setting up ip based restrictions via firewall rules to Kubernetes api server can add an additional layer of security not allowing the attacker to make api calls from his network.

Thanks for reading this.

Kindly,
Interas Labs

Sources: Webinar: Kubernetes Security Best Practices – Ian Lewis, Google