Hacking Kubernetes

Chapter 10. Organizations

A Kubernetes cluster doesn’t run in a vacuum but in an environment, which could be an on-premises setup such as your own datacenter, or you could be using the offering of a cloud provider.

In contrast to previous chapters, in this chapter we look in detail at the “wetware,” a somewhat tongue-in-cheek term referring to humans rather than the software or hardware used. We will make the point that, despite all the technology available at your hands, running Kubernetes clusters and workloads securely requires you to focus on a nontech piece of the puzzle: humans and their natural (work) habitat, that is, organizations.

Turns out that humans are, oftentimes, the weakest link in the chain. For example, an attacker may target email, PKI, and administrative interfaces to get behind the walls and steal secrets from the inside out, exfiltrate data, or leak sensitive information to the public.

In general, things external to a cluster can bypass its security if they are compromised—for example, the account with a cloud provider, admin credentials, encryption keys, or really anything along the software supply chain.

The shared responsibility model used by cloud providers puts certain security processes on the shoulders of users, while the cloud provides services that are themselves secure. This means that you need to consider the build-out of the infrastructure topology, data flows, and security configuration as well as its usage.

So, let’s see what our swarthy ol’ ...