Kubernetes Deployments – Security Best Practices

Pre-requisite: Kubernetes

Applications can be more easily managed by Kubernetes, which automates operational tasks of container management and includes built-in commands for deploying applications, rolling out changes to your applications, scaling your applications up and down to fit changing needs, monitoring your applications, and more.

Due to its complexity, Kubernetes requires substantial maintenance and configuration. You must address critical architectural flaws and platform dependencies by following security best practices if you want to make Kubernetes workloads secure, especially in a production environment. We have a decent foundation of fundamental software security principles provided by Kubernetes, but we still need to comprehend and use them. A distributed deployment like a Kubernetes cluster increases the number of attack vectors, thus it’s crucial to be aware of the best practices for minimizing those attack surfaces.

We end users still have some responsibility for security even when using a managed Kubernetes service. Customers are normally in charge of managing and protecting the data plane while the cloud vendor manages and secures the control plane (API Server, scheduler, etcd, controllers) of the Kubernetes cluster (node pools, ingress, networking, service mesh, etc.)

Kubernetes Deployments Security Methods

For API Server, use Third-Party Authentication

Integration with a third-party authentication service for Kubernetes is advised (e.g. GitHub). In addition to adding multi-factor authentication, this guarantees that the kube-apiserver does not alter when users are added or withdrawn. Make sure users are not managed at the API server level, if at all possible. OAuth 2.0 connections like Dex are also an option.

Open Role-Based Access Control in Kubernetes (RBAC)

You can specify who has permissions to use the Kubernetes API using RBAC. RBAC is often turned on by default in Kubernetes versions 1.6 and higher (later on some hosted Kubernetes providers). When you enable RBAC, you must also disable the old Attribute Based Access Control because Kubernetes mixes authorization controllers (ABAC).

When employing RBAC, cluster-wide permissions should be avoided in favour of namespace-specific rights. Never give cluster administrators access, not even when debugging. Providing access only when absolutely necessary for your particular circumstance is safer.

Track Network Activity to Control Communications

Cluster networks are typically extensively used by containerized applications. Learn how your application interacts with other applications by watching active network traffic and comparing it to the traffic permitted by Kubernetes network policy. Doing so will help you spot odd communications.

In addition, you can spot network policies that aren’t being used by cluster workloads by comparing active traffic to allowed traffic. By eliminating unnecessary connections to lessen the attack surface, this information can be leveraged to improve the approved network policy even further.

Set Kubernetes nodes apart

Nodes for Kubernetes should not be directly accessible from public networks and must be on a separate network. Even direct links to the main business network should be avoided if at all possible.

Only if Kubernetes control and data traffic are isolated will this be achievable. Without open access to the data plane, both pass down the same pipe, and open access to the control plane follows naturally. The best configuration for nodes is to have an ingress controller configured to only permit connections from the master node on the designated port via the network access control list (ACL).

Implement Process Whitelisting

A useful technique for locating unexpectedly running processes is process whitelisting. To start, keep track of all processes that are active when the programme behaves normally over a period of time. Utilize this list as your whitelist moving forward for application behaviour. At the process level, runtime analysis is challenging. It is possible to investigate and spot irregularities in processes that are running across clusters using a variety of commercial security solutions.

Activate audit logging

Ensure that audit logging is enabled, and that you are keeping an eye out for any strange or undesirable API requests, particularly failed authentications. A “Forbidden” status message appears next to certain log entries. Failure to authorise could indicate that a hacker is attempting to utilise credentials that have been stolen.

The -audit-policy-file switch can be used to enable audit logging and specify exactly which events should be documented when files are passed to kube-apiserver. There are four different logging levels you may choose from: None, Metadata only, Request (which logs both requests and responses but not metadata), and RequestResponse (which logs all three). See the documentation for an example of an audit policy file.

Managed Kubernetes providers can set up notifications for authorization failures and give access to this data via their UI.

Update the Kubernetes version

The most recent version of Kubernetes should always be used. For a list of known Kubernetes security holes and their respective severity ratings, click. Always prepare to upgrade your Kubernetes installation to the most recent version. Check to see if your supplier handles automatic upgrades if you use a hosted Kubernetes provider as upgrading Kubernetes can be a complicated procedure.

Secure Kubelet

Each node has a kubelet running as an agent that communicates with the container runtime to launch pods and report metrics for nodes and pods. You can utilise the APIs exposed by each kubelet in the cluster to start and stop pods as well as carry out other activities. An unauthorised user can jeopardise the entire cluster if they are able to access this API (on any node) and run code on it.