Spoofing

Spoofing is pretending to be somebody else with the aim of gaining extra privileges.

Let’s look at some of the ways Kubernetes prevents different types of spoofing.

Securing communications with the API server

Kubernetes comprises lots of small components that work together. These include the API server, controller manager, scheduler, cluster store, and others. It also includes node components such as the kubelet and container runtime. Each has its own privileges that allow it to interact with and modify the cluster. Even though Kubernetes implements a least-privilege model, spoofing the identity of any of these can cause problems.

If we read the RBAC and API security chapter, we’ll know that Kubernetes requires all components to authenticate via cryptographically signed certificates (mTLS). This is good, and Kubernetes makes it easy by automatically rotating certificates. However, we must consider the following:

1. A typical Kubernetes installation auto-generates a self-signed certificate authority (CA) that issues certificates to all cluster components. While this is better than nothing, it’s not enough for production environments on its own.

2. Mutual TLS (mTLS) is only as secure as the CA issuing the certificates. Compromising the CA can render the entire mTLS layer ineffective. With this in mind, it’s vital we keep the CA secure!

A good practice is to ensure that certificates issued by the internal Kubernetes CA are only used and trusted within the Kubernetes cluster. This requires careful approval of certificate signing requests, as well as ensuring the Kubernetes CA doesn’t get added as a trusted CA for any systems outside the cluster.

As mentioned in previous chapters, all internal and external requests to the API server are subject to authentication and authorization checks. As a result, the API server needs a way to authenticate (trust) internal and external sources. A good way to do this is to have two trusted key pairs:

• One for authenticating internal systems

• A second for authenticating external systems

In this model, we’d use the cluster’s self-signed CA to issue keys to internal systems. We’d then configure Kubernetes to trust one or more trusted 3rd-party CAs for external systems.

Securing Pod communications

As well as spoofing access to the cluster, there’s also the threat of spoofing app-to-app communications. In Kubernetes, this can be when one Pod spoofs another. Fortunately, Pods can have certificates to authenticate their identity.

Every Pod has an associated ServiceAccount that is used to provide an identity for the Pod. This is achieved by automatically mounting a service account token into every Pod as a Secret. Two points to note:

1. The service account token allows access to the API server

2. Most Pods probably don’t need to access the API server

With these two points in mind, we should set automountServiceAccountToken to false for Pods that don’t need to communicate with the API server. The following Pod manifest shows how to do this.