Hacking Kubernetes

Chapter 8. Policy

Once a system is constructed on solid foundations, it must be used correctly to maintain its integrity. Building a sea-fort to defend an island from pirates is half the battle, followed by posting guards to the watchtower and being prepared for defense at any time.

Like the orders to the fort’s guards, the policies applied to a cluster define the range of behaviors allowed. For example, what security configuration options a pod must use, storage and network options, container images, and any other feature of the workloads.

Policies must be synchronized across clusters and cloud (admission controllers, IAM policy, security sidecars, service mesh, seccomp and AppArmor profiles) and enforced. And policies must target workloads, which raises a question of identity. Can we prove the identity of a workload before giving it privileges?

In this chapter we look at what happens when policies are not enforced, how identity for workloads and operators should be managed, and how the Captain would try to engage with potential holes in our defensive walls.

We will first review different types of policies and discuss the out-of-the-box (OOTB) features of Kubernetes in this area. Then we move on to threat models and common expectations concerning policies such as auditing. The bulk of the chapter we spend with the access control topic, specifically around role-based access control (RBAC) and further on we investigate the generic handling of policies for Kubernetes, based on projects ...