This blog was written by an independent guest author.
Organizations are increasingly incorporating containers and Kubernetes into their IT infrastructure. As reported by ZDNet, Flexera’s “2020 State of the Cloud Report” found that about two-thirds (65%) of organizations were using Docker and that another 14% intended to begin using it at some point. Slightly fewer organizations (58%) were using Kubernetes at the time of the survey, by comparison, with 22% of participants saying they planned to adopt it.
Even so, misconfigurations with both containers and Kubernetes are posing a problem. StackRox’s “State of Kubernetes and Container Security Winter 2020” report found that nearly all (94%) of respondents had experienced a security incident in their container environments over the past 12 months, per Security magazine’s coverage. The majority (69%) of those security events amounted to a misconfiguration incident, followed by runtime issues and vulnerabilities at 27% and 24%, respectively. In keeping with those experiences, 61% of survey participants cited misconfigurations as their most worrisome security risk for their container and Kubernetes environments followed by vulnerabilities (27%) and runtime attacks (12%).
These findings beg the question: why are misconfigurations such an issue for organizations’ Kubernetes and container environments?
This blog post will answer this question by first defining containers and Kubernetes and explaining the benefits of each technology. It will then explore how misconfigurations open the door for attacks from malicious actors. Finally, it will briefly provide a few recommendations on how organizations can reduce the probability of suffering a misconfiguration incident.
Why use containers and Kubernetes?
According to CIO, a container contains everything that’s needed to run a software program. It includes an application along with its dependencies, libraries and other components. Bundling these components together enables a container to run regardless of the system’s OS distribution or the underlying infrastructure.
Those aren’t the only benefits of containers, either. Containers might be only tens of megabytes in size, for instance. A server can therefore host more containers than virtual machines, notes CIO, as a virtual machine consists of an entire OS that might be several gigabytes in size. Consequently, virtual machines usually take several minutes to boot up and begin running, while containers can run almost instantly. This quality makes containers more dynamic in that organizations can spin them up and wind them down at a moment’s notice. Finally, organizations can take advantage of containers’ smaller size and dynamism to split an application into several modules that extend across several containers. Under this approach, developers can make changes to a module and deploy them without needing to redesign the whole app.
As the number of containers grows, organizations need some way of managing them all in an organized fashion. That’s where Kubernetes comes in as an orchestration platform. Per its website, Kubernetes enables organizations to manage their containerized workloads and services. It allows organizations to load balance and distribute network traffic in order to stabilize a deployment. It also enables organizations to restart containers that fail and kill those that don’t pass a health check specified by their container administrators.
The problem of misconfigurations
Notwithstanding their benefits, containers and Kubernetes environments can suffer from misconfigurations that undermine an organization’s digital security posture. InformationWeek explained that not all of a container’s possible security controls might arrive in an activated state by default. For example, IT teams and developers might fail to enable the measures that limit access to containerized applications, and they might not apply identity and access management policies to their containers.
These oversights are an issue because they could enable a malicious actor to access a container. Depending on that resource’s privileges, they could potentially move laterally throughout the container environment to access other containers for the purpose of stealing sensitive information. They could also infect those containers with malware whose code could become inadvertently bundled with the binaries and other components that make up an image. Without proper security controls, that malware could become a native part of that image and infect anyone who downloads it from a repository.
As for Kubernetes, StackRox notes that the orchestration platform does come with network policies that behave like firewall rules in regulating pod communication. Organizations could theoretically apply these policies to restrict which pods can talk to one another, thereby limiting the scope for the types of attacks described above. The only issue is that Kubernetes does not apply a network policy to a pod by default. In a standard Kubernetes deployment, a malicious actor could therefore communicate with all other pods once they’ve compromised just a single pod and then exploit those channels to compromise the organization’s data.
How to defend against a misconfiguration
Reflecting on the challenges discussed above, it’s not always possible to detect a misconfiguration via manual means. That explains why security experts highlighted the need for automation to Dark Reading. This automated configuration management process should start with organizations using policies informed by security frameworks, industry best practices and Center for Internet Security (CIS) benchmarks to identify configuration violations. It should also involve the use of Role-Based Access Control provide context on detected misconfigurations and to limit access based on job function.
For more information on how to address misconfigurations in your organization’s containers and Kubernetes environment, check out this webinar recording.