The Best Cybersecurity Practices for Kubernetes Projects

More and more companies are mainly running their services in a cloud environment. Various cloud providers such as Amazon Web Services (AWS), Google Cloud Platform (GCP) or Microsoft Azure offer different cybersecurity models to keep your and your customers’ data safe. However, you can’t rely solely on pre-delivered cybersecurity measures – you should also implement some security measures on your own for maximum safety. 

This article will focus on maintaining security while working with Kubernetes, as it is one of the more frequently used solutions for building microservice-based apps. Read on to find out how you can secure key components in your Kubernetes-based projects. 

What is Kubernetes? 

Kubernetes, also known as K8s, defines itself as “an open-source system for automating deployment, scaling, and management of containerized applications.” Kubernetes is often used by platforms offering robust customer services, such as Google, Slack or Spotify, and comes with a range of automation tools that help developers create highly scalable and flexible solutions, regardless of their complexity. The homogenous architecture and ability to scale custom metrics and adjust used instances support cost optimization. Kubernetes also helps to consistently manage numerous containers and speed up time to market for new releases. 

Companies often use Kubernetes along with Docker, an open-source technology for building container-based applications. Docker introduces a layer of abstraction, which helps manage different platforms in a consistent, similar way, regardless of the language each platform was created in. The different languages remain compliant with the Docker images without impacting the management of the images across other platforms. The combination of Docker and Kubernetes helps you avoid vendor lock-in. It also results in similar, standardized environments without various discrepancies, which makes them easier to manage and run. 

What is the Kubernetes architecture? 

It’s worth looking at the key architecture elements that are characteristic of the Kubernetes environment. A Kubernetes operating system consists of a control plane and worker node. The control plane is the central element of a Kubernetes cluster and manages all the communication and processes, such as managing, scaling and deploying pods, while also handling information about volumes and requests. The communication and requests are then directed to worker nodes – elements where pods are launched. Deployments occur at the level of pods, which are abstract objects in Kubernetes. They represent one container or a group of several containers, along with resources shared by the containers. 

The control plane consists of the kube-apiserver, kube-controller-manager, kube-scheduler and etcd. The etcd serves as a database that stores the status of a cluster, network and other elements. Without the etcd, a cluster would stop existing. 

The kube-apiserver is another key element that ensures a cluster works properly. It handles all internal and external communication, checks and configures API object data, processes REST operations and communicates with the etcd base. The kube-controller-manager is a controlling element that cooperates with the kube-apiserver to define a cluster’s status. The kube-scheduler uses a dedicated algorithm to decide whether the number of pods needs to be increased or decreased, and also prompts worker nodes to perform different actions. 

In the worker node, the kubelet manages the pods, using API, and ensures configuration settings and changes are applied to its worker node. It also sends status information to the kube-apiserver. Additionally, if a pod requires access to disc resources, secrets or ConfigMaps, the kubelet grants or creates this access. 

The kube-proxy runs on each node of the cluster, managing its network rules and ensuring network communication between pods. The worker node also manages ingress – the incoming traffic – and egress – the outgoing traffic – so that communication is passed to the right elements.  

Best practices for keeping your Kubernetes cluster secure 

When thinking about the security of Kubernetes cluster, you have to consider not only the operating system, but also additional elements of the environment, such as other applications or components you could install to strengthen the system. Here are some recommended best practices that will help you limit cybersecurity threats for your Kubernetes cluster. 

Regularly install updates and security patches for an operating system and other Kubernetes components. A lack of regular updates can lead to a system becoming highly vulnerable to security loopholes and create an opportunity for someone to access the operating system and take control over an entire cluster. To avoid these scenarios, you need to stay up to date on known security issues e.g., by following Kubernetes’ Official Common Vulnerabilities and Exposures (CVE) Feed.  

Verify file access within an operating system. It’s important to make sure that the files in an operating system can’t be accessed by unauthorized users. Otherwise, there is a risk that a data breach will occur or someone will gain access to other areas of a cluster. Some crucial files you’ll want to pay attention to include kube-apiserver.yaml, kube-controller-manager.yaml, etcd.yaml and kube-scheduler.yaml. For more detailed information on file access configuration, you can check out some recommendations from the Center for Internet Security (CIS) Benchmarks.  

Verify sources and scan Docker images for dangerous elements. Images downloaded from untrustworthy sources might turn out to have hidden, harmful intentions. They can, for example, launch malware, perform unauthorized actions or work as a crypto mining attack where an attacker uses your system’s computing resources to mine cryptocurrencies. As with files, it’s also a good idea to closely control and limit access to creating images. 

Make sure your role-based access control (RBAC) policies are set up correctly. When designing the architecture of a solution, you should clearly define access authorization for each user group (e.g., developers, administrators) for various elements of a cluster. Pay particular attention to who can access pod operations (such as viewing and scaling), secrets (sensitive data e.g., passwords) and other key areas. This way you can reduce the risk of unauthorized users compromising sensitive data or running unauthorized pod operations. To verify your RBAC policies and see your access configuration, you can use KubiScan. 

Store sensitive data safely. In Kubernetes, you can save your application configuration, such as password configurations, in ConfigMaps. To conceal that information, you can store it in secrets, which are special Kubernetes components for data that shouldn’t be easily accessible. Secrets can be then used in an application, with data safely kept inside it. It’s recommended to enable at-rest secret data encryption, using EncryptionConfiguration, by setting up an Advanced Encryption Standard (AES), such as AES-GCM. To further boost security, you can also try implementing credential rotation e.g., with tools such as CyberArk secret providers, to regularly change or reset passwords in your system. 

Create a dedicated namespace. Worker nodes have a default namespace (a virtual space). If you don’t configure deployment parameters, that’s where pods will be launched. It’s not the best solution because the default namespace can be accessed by many potential user groups. It’s recommended to create a dedicated namespace where you can run applications, define access policies and manage resources for specific applications. Otherwise, more extreme cases of incorrect configuration can even lead to sensitive data exposure, with users seeing applications or data they’re not supposed to view e.g., applications that should be running in a different dedicated namespace. 

Configure your network policy to limit communication between other network segments. By controlling communication access between different network elements, you minimize the risk that unauthorized users will obtain or leak information. When planning your solution, define the ports users can use to communicate and user groups they can communicate with. You should also block communication between namespaces so that attackers can’t successfully launch server-side request forgery (SSRF) attacks to access data or applications from other namespaces. 

Secure the API. Use encryption mechanisms such as Transport Layer Security (TLS) communication to avoid scenarios where unauthorized people can access information e.g., information sent from a control plane to a worker node. Make sure to turn off anonymous requests to the system’s API or components, so that attackers can’t obtain data from a cluster because they identified a potential access route. 

Monitor ingress and egress. Remember to use standard security measures like web application firewall (WAF) to filter HTTP protocol requests and protect your applications from a range of security attacks on ingress, including distributed denial-of-service (DDoS). At the same time, don’t forget to monitor and filter the egress traffic. Since the traffic there is open, egress can be exploited e.g., to set up a reverse proxy undetected. One way to secure egress is to whitelist resources and define WAF policies for the outgoing traffic. The traffic should also be logged, ideally in a dedicated Security Information and Event Management (SIEM) system where logs can’t be modified in an attack. 

Keep a record of actions performed in a cluster. Implement a mechanism that will gather logs from both an operating system and cluster. It’s a good idea to have an external system (e.g., Prometheus, Grafana, the ELK Stack) where the logs will be stored so that in case of an attack, you’ll have a copy of the logs that an attacker couldn’t have tampered with. This system will also enable you to aggregate the logs, analyze past security incidents or spot current issues. 

Regularly back up the etcd. The etcd is the main base of a cluster, which is why it’s vital to keep it secure. Apart from limiting access to it, you should also regularly back up the etcd data. If it gets damaged or overwritten, the cluster will stop working and you’ll have to build it again. 

Cybersecurity is a process, not a one-off task 

These best practices mostly cover what you need to do to keep your Kubernetes cluster secure.  However, they should be a part of a wider approach in which you pay attention to system security consistently and thoroughly. Cybersecurity should be treated as a process where you prepare and implement policies and security measures, then regularly validate and improve them. The best practices shared in this article, for example, should also be a part of standard procedures for onboarding new applications to ensure that all new clusters and apps follow the same security measures. Additionally, you should also consider involving Security Operation Center (SOC) experts. 

If you want to learn more about security approaches in software development, stay tuned for the next cybersecurity blog about service mesh architecture for microservices. 

Cybersecurity can’t be an afterthought when you develop your solutions. That’s why companies partner up with software experts, like Software Mind, who combine high-quality product engineering with a thoughtful approach to software security. Get in touch via the contact form below to see how our team can accelerate your software delivery while driving data safety.

Read also: Rancher vs Kubernetes