13. Runtime and Network Security in Kubernetes

Overview

In this chapter, we will look at various resources that we can use to secure workloads running in our cluster. We will also understand a rough threat model and apply it to architect a secure cluster so that we can defend our cluster and application against various types of threats. By the end of this chapter, you will be able to create Role and ClusterRole, as well as RoleBinding and ClusterRoleBinding to control the access of any process or user to the Kubernetes API server and objects. Then, you will learn how to create a NetworkPolicy to restrict communication between your application and the database. You will also learn how to create a PodSecurityPolicy to ensure that the running components of your application are conforming to the defined limits.

Introduction

In the last couple of chapters, we had our DevOps hat on and learned how to set up a cluster, as well as how to roll out new application versions safely and without downtime in Kubernetes.

Now, it's time to switch gears a bit, take our DevOps hat off, and put on our security analyst hat. First, we will look at where someone might attack our Kubernetes cluster and how an unauthorized user could potentially wreak havoc in our cluster. After that, we're going to introduce a few of the security primitives of Kubernetes and how we can combat the most common forms of attack. Finally, we'll further modify our application and demonstrate how some of these security primitives work.

But before we get to any of it, let's begin by taking a brief look at the various areas of concern for security in a modern web application, as well as a basic paradigm for implementing effective security for our cluster. We'll start by examining what we call the "...

Threat Modeling

It is far beyond the scope of this chapter to adequately teach many of the necessary disciplines of security so that you have a rigorous understanding of how modern workload security should be implemented and orchestrated. However, we will briefly gain an idea of how we should be thinking about it. Threat modeling is a discipline where we examine the various areas where our applications could be subject to an attack or unauthorized usage.

For example, consider an HTTP web server. It will typically have ports 80 and 443 exposed for serving web traffic, but it also acts as an entry point for any potential attackers. It may have a web management console exposed at a certain port. It may have certain other management ports open and API access to allow other software to manage it for automation purposes. The application runtime may need to regularly handle sensitive data. The entire end-to-end pipeline meant to create and deliver the application could expose various points...

Cluster Security

One way to think about Kubernetes is as a gigantic self-orchestrating pool of compute, networking, and storage. As such, in many respects, Kubernetes is exactly like a cloud platform. It is important to understand this equivalence because this mental abstraction allows us to reason differently as a cluster operator versus a cluster developer. A cluster operator would want to ensure that all the components of the cluster were secure and hardened against any workload. A cluster developer would concern themselves with ensuring that the workload they are defining for Kubernetes is running securely inside the cluster.

Here is where your work becomes a bit easy – most cloud provider offerings from Kubernetes will ensure the security of the Kubernetes control plane for you. If, for whatever reason, you're not able to leverage a cloud provider offering, you'll want to read more in the documentation about securing your cluster at this link: https://kubernetes...

Kubernetes RBAC

Before we dive into RBAC, recall from Chapter 4, How to Communicate with Kubernetes (API Server), how Kubernetes authorizes requests to the API. We learned that there are three stages – Authentication, Authorization, and AdmissionControl. We will learn more about Admission Controllers in Chapter 16, Kubernetes Admission Controllers.

Kubernetes supports multiple different methods of authenticating with the cluster, and you'll want to reference your cloud provider's documentation to get more details on their specific implementation.

Authorization logic is handled through something called RBAC. It stands for role-based access control and it's the foundation of how we constrain certain users and groups to the minimum necessary permissions to perform their job. This is based on a concept in software security called "the principle of least privilege." For example, if you are a software engineer for a credit card processing company, Payment...

NetworkPolicies

NetworkPolicy objects in Kubernetes are essentially Network Access Control Lists but at the Pod and namespace level. They work by using label selection (such as Services) or by indicating a CIDR IP address range to allow on a particular port/protocol.

This is immensely helpful for ensuring security, especially when you have multiple microservices running on a cluster. Now, imagine you have a cluster that hosts many applications for your company. It hosts a marketing website that runs an open-source library, a database server with sensitive data, and an application server that controls access to that data. If the marketing website doesn't need to access the database, then there should be no reason for it to be allowed access to the database. By using a NetworkPolicy, we can prevent an exploit or a bug in the marketing website from allowing an attacker to expand that attack so that they can access your business data by preventing the marketing website Pod from...

PodSecurityPolicy

So far, we have learned about and tested Kubernetes RBAC to prevent unauthorized API server access, and also applied a NetworkPolicy to prevent unnecessary network communication. The next most important area of security outside the network is the application runtime. Attackers need access to the network to get in and out, but they also need a vulnerable runtime to do anything more serious. This is where Kubernetes PodSecurityPolicy objects help prevent that from happening.

PodSecurityPolicy objects overlap with a specific type of AdmissionController and allow a cluster operator to dynamically define the minimum runtime requirements of a Pod that's been admitted for scheduling on the cluster.

To understand exactly how PodSecurityPolicies can be useful, let's consider the following scenario. You are a Kubernetes cluster admin at a large financial institution. Your company uses ticket-based change management software in an ITIL-compliant fashion (ITIL...

Summary

In our journey of building a production-ready Kubernetes environment, security is a critical aspect. With that in mind, in this chapter, we examined how threat modeling allows us to think in an adversarial way about our application infrastructure and how it informs us of how we can defend it from attack. Then, we looked at the 4Cs of Cloud Native Security to understand where our attack surfaces are, followed by how Kubernetes can help us run workloads securely in the cluster.

Kubernetes has several security features that we can leverage to secure our cluster. We learned about three security measures that are important to leverage: RBAC, NetworkPolicies, and PodSecurityPolicies. We also learned about their various applications when it comes to securing access to your cluster, securing your container network, and securing your container runtimes.

In the next chapter, we're going to examine how to manage storage objects in Kubernetes and deal with apps that are stateful...