Spoofing
Learn how to prevent spoofing.
We'll cover the following
Spoofing is pretending to be something or somebody, you are not. In the context of information security, it’s pretending to be a different user or entity, with the aim of gaining extra privileges on a system.
Let’s look at how Kubernetes authenticates users to prevent spoofing.
Securing communications with the API server
Kubernetes is composed of many small components that work together. These include control plane components, such as the API server, controller manager, scheduler, and cluster store. It also includes node components, such as the kubelet and container runtime. Each of these has its own set of privileges that allow it to interact with, and even modify, the cluster. Even though Kubernetes implements a least-privilege model, spoofing the identity of any of these components can have unforeseen and potentially disastrous consequences.
Fortunately, Kubernetes implements a security model that requires components to authenticate via mutual TLS (mTLS). This requires both parties (the sender and the receiver) to authenticate each other via cryptographically signed certificates. This is good, and Kubernetes makes things easy by auto-rotating certificates, etc. However, it’s vital that you consider the following:
- A typical Kubernetes installation will auto-generate a self-signed certificate authority (CA) during the bootstrap process. This is the CA that will issue certificates to all cluster components. It’s better than nothing, but, on its own, it probably isn’t enough for your production environment.
- Mutual TLS is only as secure as the CA that issued the certificates. Compromising the CA can render the entire mTLS layer ineffective. So, 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 making sure the Kubernetes CA is not added as a trusted CA for any components outside of Kubernetes.
As mentioned in previous chapters, all interaction with Kubernetes is via the API server and subject to authentication and authorization checks. This is true for internal and external components. 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 components and the other for authenticating external components.
To accomplish this, Kubernetes leverages an internal self-signed CA to issue keys to internal components as well as one or more trusted third-party CAs to issue keys to external components (Kubernetes obviously needs configuring to trust the third-party CAs). This configuration ensures the API server trusts internal components possessing a certificate issued by the cluster’s self-signed CA as well as external components possessing a certificate signed by the third-party CA.
Get hands-on with 1200+ tech skills courses.