Kubernetes From an Attacker’s Perspective — OWASP Bay Area Meetup

Last week, we did an hour long webinar for OWASP Bay Area Meetup group where I spoke about Kubernetes from an Attacker’s Perspective. As part of of the webinar, I demonstrated attack scenarios on a Kubernetes 1.15+ cluster provisioned on Google Kubernetes Engine (GKE). The slides and video recording from the webinar, along with Questions & Answers are presented in this blog post.

Slides

https://speakerdeck.com/abhisek/kubernetes-from-an-attackers-perspective

Video

https://youtu.be/sXiGDDl7skk

Related Articles from Appsecco

Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1

Abusing insecure hostPath volume mount in Kubernetes for full K8S cluster compromise

Prevent hostPath based Kubernetes attacks with Pod Security Policies

Mitigation for insecure hostPath volume mounts using pod security policies

Questions & Answers

Is there any standard guide for Kubernetes security testing similar to Web Application Security Testing Guide or MSTG?

Not that I am aware of. I think there is a lot of scope for creating a Kubernetes security assessment methodology.

But these host mounts are disabled by PSP right?

Yes. PodSecurityPolicy can be used to used to deny hostPath volume mounts.

I understand the idea of pivoting from a container to elevate your privileges but what methods can be used to get terminal access into a container in the first place?

Get Abhisek Datta’s stories in your inbox

Join Medium for free to get updates from this writer.

We have to look at externally exposed attack surfaces for initial access (foothold). I will look for

1. Applications exposed outside the cluster through Ingress or LoadBalancer services
2. Scan nodePort range of ports — 30000–32767 for exposed and potentially vulnerable services
3. Known vulnerabilities in Kubernetes API Server REST interface
4. RBAC weaknesses in Kubernetes API Server, especially what all privileges allowed for system:unauthenticated group
5. Cloud related attack surfaces like weak IAM, service accounts or breached credentials

Can you please comment on the security implications of IPV6 only clusters?

Apart from making scanning and discovery to be harder, I think other attack surfaces will remain the same.

Can you share your Kubernetes configurations (ubuntu.yml) and commands used for future reference?

Appreciate the time you took for this presentation! Very well executed. I want to follow along with you with a cluster — would it be possible to get a recording or list of steps?

Yep. Its embedded in this blog post.

Wonderful talk, Abhisek! Regarding the hostPath mount escape — would a proper pod security policy have helped there?

Yes. As answered earlier, an appropriate PodSecurityPolicy can be used to restrict hostPath volume mount. Refer to our blogpost on this mitigation presented earlier in this blog post.

Are there any specific recommendations you have for the configuration of the Kubernetes Dashboard security-wise?

Remove or restrict access unless absolutely required. Do not mount a privileged service account to the Pod and allow users to authenticate using their own credentials.

At Appsecco we provide advice, testing and training around software, infra, web and mobile apps, especially that are cloud hosted. We specialise in auditing Kubernetes clusters as per the CIS Benchmark to create a picture of the current state of security. If you are confident about the security of your cluster get assurance for withstanding real world attackers by getting us to do a black box pentest.