Reducing the risk of misconfigured components in Kubernetes

Kubernetes misconfiguration incidents are a common occurrence. Here’s how to avoid them

Organisations’ adoption of Kubernetes is on the rise. As reported by Container Journal, VMware’s “State of Kubernetes 2020 Report” found 48% of respondents were using Kubernetes in 2020. That was up from 27% two years earlier.

Not all is rosy with the enterprise’s embrace of Kubernetes, however. Indeed, misconfiguration incidents are a common occurrence. A report from StackRox found that 69% of respondents’ organisations had detected a misconfiguration in their Kubernetes environment, as reported by The Enterprisers Project. Misconfigurations were therefore the most common type of security issue that firms experienced within their containers and Kubernetes environments, surpassing runtime security incidents and vulnerabilities at 27% and 24%, respectively.

Incidents involving misconfigurations in Kubernetes and other cloud-based platforms are no laughing matter. In its “2020 Cloud Misconfigurations Report,” for instance, DivvyCloud found that 196 separate data breaches had resulted from cloud misconfigurations between January 1, 2018 and December 31, 2019. Those security incidents helped to expose over 33 billion records and produce upwards of $5 trillion in losses over that two-year period, reported TechRepublic.

These findings beg the question: how can organisations reduce the risk of misconfigured components in their Kubernetes environments?

What is Kubernetes?

According to its website, Kubernetes is an open-source platform that enables companies to manage their containers. It facilitates declarative configuration and automation to preserve the availability of an organisation’s containers. Organisations use containers to bundle and run their applications, after all, and they need to make sure that those applications experience no downtime. In the event that a container does experience an outage, the firm needs to make sure that there’s another container waiting in the wings to assume its functions.

That’s where Kubernetes comes in. The orchestration platform is capable of load balancing and distributing traffic across the container network to ensure that the application suffers no downtime. Kubernetes has other benefits, as well. Indeed, organisations can use the platform to change the state of their deployed containers at a controlled rate to a desired configuration.

This capability makes it possible for container admins to automatically add containers to their deployment, remove containers from their environment and integrate resources into a new container. Not only that, but Kubernetes also enables organisations to restart containers if they fail, to replace containers and/or to kill containers if they fail to meet a health check.

How misconfigurations affect Kubernetes

Notwithstanding its benefits, Kubernetes can undermine organisations’ digital security if container admins don’t configure it correctly. Here are just a few Kubernetes misconfigurations that warrant particular consideration:

• Authentication: Kubernetes comes with options for role-based, attribute-based and node-based authentication. If admins don’t implement the proper means of authentication, however, they could leave their organisation’s containers open to public access. Trend Micro found this out when it conducted a scan on Shodan and found that etcd, a key value server, was publicly accessible on nearly 3,000 hosts.
• Default Configurations: Admins have the option of using network policies to configure their Kubernetes deployments. As an example, organisations can use a network policy to control how pods communicate with one another by only allowing communication between those pods defined in that policy. The only problem is that Kubernetes does not apply a network policy to any pods by default, which means that all pods can communicate with one another without restrictions. This default configuration makes it possible for malicious actors to compromise a single pod and capitalise on that access to move laterally throughout the container environment.

Misconfigurations such as those described above give attackers the ability to prey upon organisations. In June 2020, for instance, Microsoft’s Azure Security Center (ASC) came across a suspicious image that originated from a public repository on multiple clusters running Kubeflow. Malicious actors used an exposed Kubeflow dashboard to gain initial access to one of those clusters. They then used a container within that cluster to achieve persistence and execute malicious code. This step helped the attackers to move laterally, to deploy another container using a mounted service account and to run a cryptocurrency miner within the cluster.

Addressing the challenge of misconfigurations in Kubernetes

Organizations can address the challenge of misconfigurations in Kubernetes in several ways. First, they can use the command kubectl auth can-I to investigate the permissions on their Kubernetes users and service accounts. If they find permissions that are unnecessary, they can disallow them. Second, they can follow StackRox’s advice by evaluating their image configurations against industry benchmarks such as the Center for Internet Security’s Critical Security Controls. Third, they can use network policies to limit communication between their pods and to implement other security controls within their Kubernetes environment.