Kubernetes Security: how to apply the 80/20 principle

When it comes to cloud-native applications development and deployment, Kubernetes has become the de facto standard to deploy, scale and manage containerised applications.

Securing Kubernetes is important because it involves securing the entire container infrastructure and the data that flows through it. A compromised Kubernetes cluster can result in unauthorised access to sensitive data and applications, as well as potential damage to the entire infrastructure. It is important to take steps to secure Kubernetes clusters and the workloads running on them in order to protect against potential threats and vulnerabilities.

Here is the list of actions with higher impact to reduce most common and important risks:

Secure image provisioning

Aka. Where do your images came from ?

Container security must include an understanding of what the container is supposed to do, if it contains known vulnerabilities, or when there is an official new version. Some tools that can be used to perform such image scanning are Docker Bench and Clair, which could be run to investigate images.

Secure the API-Server

The kube-apiserver is a prime target for controlling or preventing functioning of the cluster. It is important to prevent unwanted traffic from even being evaluated. security and access should involve multiple layers. Hopefully, unwanted traffic is stopped at the edge of the organisation via some combination of edge and interior firewalls. Every instance should always have its own firewall as well. Do not trust that someone else understands and is properly filtering your network traffic.

Secure the Etcd database

Special care must be taken to ensure the integrity and safety of etcd. The entire persistent state of the cluster is kept in etcd. In addition, secrets (which, by nature, should be protected) and configMaps (which are used to configure much of the cluster) must not be compromised. If an attacker were to update either of them, it would be ingested into the pod, potentially bypassing local security settings. In order to encrypt secrets at rest, instead of just a symmetrical base64 encoding, the kube-apiserver must be updated to use an encryption provider configuration. Once the kube-apiserver has been updated and restarted, every secret must be re-written as encryption happens during the write.

Use an Ingress controller or a Service Mesh

Kubernetes is hard-coded not to allow services to listen on low number node ports. Newer releases only allow ports between 30000–32767. Should you want to expose a low port, you would need to use an ingress controller or a service mesh. Some service meshes, like Linkerd, are built with security as a main goal, and have submitted to outside security audits and investigations. Others may not yet be mature enough. All should have some basic features, such as providing mutual TLS (mTLS) for traffic authentication.

Use network policies

Many of the popular network plugins support the use of NetworkPolicies, which provide an inside-the-cluster firewall. The original Kubernetes architecture called for all pods to see and be seen by all nodes. In a multi-tenant environment, you may want of allow some traffic and deny other.

Enable and Monitor Audit Logs

Audit logs monitoring serves as a critical component of Kubernetes security, offering several key benefits:

1. Identifying Unauthorized Activity: Audit logs can reveal unauthorized access attempts, suspicious API calls, or attempts to modify critical system configurations.
2. Detecting Resource Exploitation: Log analysis can uncover malicious activities such as privilege escalation, excessive resource consumption, or attempts to exfiltrate sensitive data.
3. Enhancing Incident Response: By understanding the sequence of events leading to a security incident, administrators can swiftly identify the root cause and implement appropriate remediation measures.
4. Compliance Auditing: Audit logs are essential for compliance with industry regulations and internal security policies.

By default, Kubernetes audit logs are disabled, which means that Kubernetes does not record the actions that are performed on your cluster.

These actions might be even less than the 20% of the effort necessary to reach an acceptable security maturity level of your Kuberentes infrastructure, however, it will keep you away from a lot of issues down the road.

Other honourable mentions that didn’t make it into the list (mostly to keep it simple) include : hardening the operating systems on your nodes, use of both host and network intrusion detection systems (HIDS, NIDS) and of course, setting up a comprehensive issue detection and mitigation strategy WHEN bad things happen.

“When it comes to cybersecurity, it is not a matter of “if something bad happen” but, “when bad things happen”

Thank you for reading. If you like my content, follow, more interesting topics to come.