Node Security with GateKeeper

Most of the security discussed so far has focused on protecting Kubernetes APIs. Authentication has meant the authentication of API calls. Authorization has meant authorizing access to certain APIs. Even the discussion on the dashboard centered mostly around how to securely authenticate to the API server by way of the dashboard.

This chapter will be different as we will now shift our focus to securing our nodes. We will learn how to use the GateKeeper project to protect the nodes of a Kubernetes cluster. Our focus will be on how containers run on the nodes of your cluster and how to keep those containers from having more access than they should. We'll get into the details of impacts in this chapter by looking at how exploits can be used to gain access to a cluster when the nodes aren't protected. We'll also explore how these scenarios can be exploited even in code that doesn't need node access.

In this chapter, we will cover...

Technical requirements

To follow the examples in this chapter, make sure you have a KinD cluster running with the configuration from Chapter 8, Extending Security Using Open Policy Agent.

You can access the code for this chapter at the following GitHub repository: https://github.com/PacktPublishing/Kubernetes---An-Enterprise-Guide-2E/tree/main/chapter9.

What is node security?

Each Pod that is launched in your cluster runs on a node. That node could be a VM, a "bare metal" server, or even another kind of compute service that is itself a container. Every process started by a Pod runs on that node, and depending on how it is launched, can have a surprising set of capabilities on that node such as talking to the filesystem, breaking out of the container to get a shell on the node, or even accessing the secrets used by the node to communicate with the API server. It's important to make sure that processes that are going to request special privileges are done so only when authorized and even then, for specific purposes.

Many people have experience with physical and virtual servers, and most know how to secure workloads running on them. Containers need to be considered differently when you talk about securing each workload. To understand why Kubernetes security tools such as the Open Policy Agent (OPA) exist, you need...

Enforcing node security with GateKeeper

So far, we've seen what can happen when containers are allowed to run on a node without any security policies in place. We've also examined what goes into building a secure container, which will make enforcing node security much easier. The next step is to examine how to design and build policies using GateKeeper to lock down your containers.

What about Pod security policies?

Doesn't Kubernetes have a built-in mechanism for enforcing node security? It does, but it's going away. In 2018, the Kubernetes project decided that the PSP API would never leave beta. The configuration was too confusing, being a hybrid of Linux-focused configuration options and RBAC assignments. It was determined that the fix would likely mean an incompatible final release from the current release. Instead of marking a complex and difficult-to-manage API as generally available, the project made a difficult decision to deprecate the API.

...

Summary

In this chapter, we began by exploring the importance of protecting nodes, the differences between containers and VMs from a security standpoint, and how easy it is to exploit a cluster when nodes aren't protected. We also looked at secure container design, and finally, we implemented and debugged node security policies using GateKeeper.

Locking down the nodes of your cluster provides one less vector for attackers. Encapsulating the policy makes it easier to explain to your developers how to design their containers and makes it easier to build secure solutions.

So far, all of our security has been built to prevent workloads from being malicious. What happens when those measures fail? How do you know what's going on inside of your Pods? In the next chapter, we'll find out using Falco!

Questions

1. True or false – containers are "lightweight VMs."
   1. True
   2. False
2. Can a container access resources from its host?
   1. No, it's isolated.
   2. If marked as privileged, yes.
   3. Only if explicitly granted by a policy.
   4. Sometimes.
3. How could an attacker gain access to a cluster through a container?
   1. A bug in the container's application can lead to a remote code execution, which can be used in a breakout of a vulnerable container, and is then used to get the kubelet's credentials.
   2. Compromised credentials with the ability to create a container in one namespace can be used to create a container that mounts the node's filesystem to get the kubelet's credentials.
   3. Both of the above.
4. How does the PodSecurityPolicy admission controller determine which policy to apply to a Pod?
   1. By reading an...