Securing Kubernetes is very different from traditional security. How ??

No More Perimeter

you don’t have perimeters anymore. A pod can go from a Datacenter to the Cloud managed Kubernetes service. In the below diagram pod is moved from an on-prem network to a cloud network (VNET). So, policies defined with on-prem network or policies (security groups policies) is not enough for securing the Kubernetes resources.

East-West Traffic

Communication between PODs within the same host doesn’t even go through the host network. So, securing only a host network is not enough.

Monitoring

Traditional data collection of five tuples (Source port, Source IP, Destination port, Destination IP, protocol) is not sufficient, because pods are ephemeral resouce. So, you would need to collect data in the context of the Kubernetes (Namespace, labels).

Now, Let’s see how we can secure Kubernetes. Kubernetes need to be secured in every stage or other words needs to be secured in defence

Build

This involves securing the code (Application and Infrastructure) from the moment is it built. Scanning for the vulnerability (see my previous blog). we call it shift-left security. The host operating system should also be hardened. Hardening depends on the OS, I would recommend verifying respective vendors documentation.

Deploy

Hardening of the Kubernetes cluster is very important. Kube-apiserver, Kubelet, etcd are some of the important components. Anyone having access to any of these components can easily take control of the entire cluster. I would strongly recommend the book Kubernetes security written by Liz rice and Michael hausenblas (you can get a free ebook from aquasec). Using CIS benchmark for Kubernetes, Hardening Kubernetes using NIST are some ways to harden the Kubernetes cluster. It is required to define architecture on who can have access (Authentication) and permission (Authorisation).

Pod Security Policy (Depreciated from 1.21), GateKeeper, OPA helps you in defining policies for pods to adhere to during the deployment (Actually can be used during runtime as well). An example of using OPA, you can trust images only from specific registries. So, any untrusted image (from an undefined registry) would not be deployed.

Runtime

Most important in runtime is to deploy containers as an immutable resource. you don’t want to patch a running container both in terms of configuration or code. Rather redeploy the entire container. Why it is important? you don’t want process, network connection, filesystem activity that are not defined in the container design to run or be executed. There are various tools (Prisma Cloud) in the market to baseline the container activity and trigger an incident if there is a violation.

Use Network policy to limit the communication between the pods, It helps in blocking the attacker from the lateral movement. It is very important to define what happens if there is a breach. This leads to the next topic.

Threat Detection in Kubernetes

Microsoft came up with Kubernetes Threat metrics going through all the phases of the kill chain

  • Reconnaissance
  • Weaponization
  • Delivery
  • Exploitation
  • Installation
  • Command and Control
  • Actions on Objective

It is crucial to understand the expected behaviour and also the unexpected behaviour. If there is an unexpected behaviour analyse the incident have necessary control and remediation

To sum it up, you need a holistic approach that requires the various teams to work together to have a secure Kubernetes environment. Next week, let’s get our hands dirty on Kubernetes security.

Leave a comment

I’m Ara

Welcome to Cloud Security Blog, my corner of the internet dedicated to Cloud and AI Security .

Let’s connect