Kubernetes security: Shift-left strategies and simplifying management

Kubernetes (K8s) is undoubtedly on the rise. According to the State of Cloud Development report by SlashData, this open-source container orchestration platform is already being used by 31 percent or around 5.6 million backend developers worldwide. Also, a survey by the Cloud Native Computing Foundation reveals that 69 percent of enterprises are already using Kubernetes in production.

This rising popularity only means that organizations should already be paying attention to the cybersecurity implications of having K8s integrated into their operations. As threat actors train their sights on K8s, though, it is not enough to know the basics. It is also time to go a level higher.

Kubernetes security

Kubernetes security is essentially a collection of techniques, strategies, and technologies created to protect the Kubernetes platform and the containers it handles. It means securing container workloads. It is different from conventional security solutions because it entails the use of a new set of methods and technologies specifically designed to address the specific threats that target containers or isolated resource procedures designed for working with programs and their dependencies.

Kubernetes security addresses three main concerns: the K8s API, best practices for pod container security, and the 4 C’s of cloud-native security, namely container, cluster, code, and the cloud itself.

Ensuring that the K8s application programming interface is secure is crucial in making sure that the Kubernetes platform is safe. This allows organizations to make the most of the extensibility and scalability advantages of Kubernetes by ascertaining that the broadening of attack surfaces does not result in the weakening of the organization’s overall security posture.

On the other hand, it is important to adopt best practices for pod containers. These include the use of role-based access control (RBAC), isolation of K8s nodes, monitoring of network traffic to detect and remove malicious access, the use of process whitelisting, audit logging, and the setting up of firewall and TLS to protect etcd clusters.

Although K8s security is mostly about cluster layer protection, it also seeks to attain end-to-end security. It is similarly important to pay attention to defending the containers, code, and cloud. Likewise, there is a need to reduce opportunities for human error and ensure programmatically scaled secure configurations.

Kubernetes and shift-left testing

It would take more than knowing and applying the bare minimum or basics of Kubernetes security to be truly secure. By now, persistent threat actors are already learning more about K8s weaknesses and finding new ways to succeed with their attacks.

As such, there are security pundits who push for a shift-left strategy. Software engineer and tech entrepreneur Sylvain Kalache, for example, says that “because of its declarative nature, Kubernetes is a great tool where a shift-left strategy can be implemented.” Kubernetes security can be improved by moving the testing process earlier, towards the development stage.

This shift-left approach means that each developer essentially becomes a testing unit, as the security testing would have to be undertaken at their level. They get to be more involved in detecting and addressing misconfigurations as opposed to letting a different team handle the responsibility.

In contrast, the shift-right approach, which has been the convention in the software industry, defers security testing to the in-production or pre-deployment stage of the software lifecycle. Security evaluations and corrections are only conducted once the software is ready for deployment, which sounds logical. After all, performance problems, user experience issues, and other concerns can be tested better when the software is actually ready for end users, not in a staging environment.

However, there are arguments that support the shift to the left. For one, doing this has the immediate effect of widening the testing coverage and catching problems before they aggravate. It would mean more work for the development team, but it results in better security. At the same time, it enhances application delivery speed and allows developers to do something to avoid the potential frustration of seeing their code in pre-production without being able to address possible security problems.

“Both shift-right and shift-left strategies have pros and cons, but the shift-left one is emerging, which is generally where companies need to improve,” Kalache explains.

Shifting left is easier said than done, though. One of the biggest stumbling blocks is the commitment of organizations to do the testing earlier during the development stage. This would be a major decision that also has material cost and operational efficiency implications.

Additionally, the proficiency of the development team to actually do competent testing is also a challenge. Not everyone is equipped with the right and updated knowledge for it. It would be necessary to have the right tools to do the testing.

“Organizing brainstorming sessions to come up with a test baseline that everybody is aware of and agrees with is a must. Providing developers-friendly tools for spotting misconfiguration will also increase the chance of having the team onboard,” Kalache asserts.

Simplifying toward better K8s security

A recent report says that nearly a million Kubernetes console instances have been exposed on the internet. The main reason for this is misconfiguration, which happens almost inevitably because of the complexities of K8s management. Many would agree that dealing with Kubernetes is not easy. A quick search on Google would show the many articles and videos that discuss this reality.

The antithesis to complexity is simplicity, and this is what organizations need to fare better. Simplifying Kubernetes may not be as simple as it sounds, but it is doable. The following pointers should help.

• Veering away from multiple clusters – Having multiple clusters under a common control plane complicates K8s management, especially when it comes to storage, networking, and security. It is advisable to keep the number of clusters as low as possible.
• Using managed K8s services – One of the reasons why Kubernetes is challenging to manage is the reality of dealing with a sprawling set of servers. This can be easily addressed with the utilization of managed K8s services like EKS and AWS, which automatically handles infrastructure management and provides a managed control plane for the K8s software to make cluster setup easier.
• Taking advantage of K8s autoscaling – Optional node autoscaling is usually part of most managed Kubernetes services. It takes away the need to manually and tediously add or remove nodes from clusters, as it can automatically do these tasks based on demand changes.
• Using Helm – Helm is an open-source package management system specifically designed for Kubernetes. It enables the installation, updating, and removal of apps in Kubernetes without the need to write deployment files from scratch. It gets the job done with a few commands just like how dnf or apt works on Linux.
• Defining multiple namespaces – K8s supports the definition of multiple namespaces, which are virtual environments that set workloads apart from each other. Having multiple namespaces allows developers to run and manage a set of containers separately from other sets. This simplifies the management of workloads because it enables the configuration of different access control policies and other rules anchored on specific separate namespaces.

Left and simple

Shifting left has been a common buzzword in the cybersecurity field recently. It is not exactly the sole focus in making Kubernetes more secure, but applying it to K8s security has real benefits. In conjunction with efforts to simplify Kubernetes management, organizations can make the most of K8s without the unwanted security vulnerabilities or weaknesses.