“What would happen if an attacker understood Kubernetes better than your operations team?” That was the core question that Ian Coldwater and I posed to each other, and it became clear that the research in this area is underexplored. Last week at RSA Conference 2020 we had the honor of presenting our thoughts on what attackers would do, how they might do it, and how they might try to avoid detection. We look forward to presenting an even more advanced version of this talk at KubeCon EU 2020.
In our RSA 2020 talk, “Advanced Persistence Threats: The Future of Kubernetes Attacks”, we used the “assume breach” threat model to begin the conversation. In this case, an attacker or malicious administrator has obtained “cluster admin” access to the API server. After discussing some of the factors of complexity and growth that are challenges to Kubernetes security in general, the talk discusses:
The goal of the presentation was to demonstrate the kinds of things that are possible, what those actions look like in the logs if they occur, and what you can do now to prepare for them. Aside from following the traditional hardening advice and being aware of common, in-cluster attacks, we recommend that key changes made in the API server such as changes to RBAC cluster admins, changes to validating and mutating webhooks, and changes to dynamic kubelet and audit sink configurations be monitored in the Kubernetes audit logs and alerted on.
The full recording and PDF of the slides are now available.