What Threatens Kubernetes Security and What Can You Do About It?

Kubernetes adoption has rocketed into ubiquity.  At this point, 96 percent of organizations are either using Kubernetes for container orchestration or evaluating its use, according to the latest Cloud Native Computing Foundation annual survey. But this doesn’t mean that Kubernetes isn’t without security risks. The flexibility of container applications and their capability to carry discrete components that interact over the network present security challenges. In particular, these include:

• Compromise of container images or containers as a whole with vulnerabilities, configuration defects, and embedded malware
• Misuse of a container to attack other containers, the host operating system, or other hosts
• Registry risks, such as insecure connections to registries, stale images in registries, inadequate authentication, and authorization restrictions
• Orchestrator risks arising from unbounded or unauthorized access, poorly separated inter-container network traffic, mixing of workload sensitivity levels, and orchestrator node trust
• Vulnerabilities within the runtime software, insecure container runtime configurations, application vulnerabilities, and rogue containers
• Host operating system risks, such as a large attack surface, shared kernel, operating system component vulnerabilities, improper access, and host OS file system damage

How do malicious actors attack Kubernetes?

Organizations that deploy Kubernetes might leave open ports exposed to the outside world. Knowing that, threat actors use tools (such as Metasploit) and simple how-to guides to scan all open ports for vulnerabilities, and then gain access.

Based on the different configurations of a deployed Kubernetes cluster, malicious actors can leverage misconfigurations in the wild or specific vulnerabilities. They can find a Kubernetes cluster that is exposed in the wild and leverage the misconfiguration of the cluster to execute an attack. From that point on, they can access the configuration of the actual cluster.

As shown below, there are various ways that an attacker could attempt to compromise your Kubernetes cluster and the applications running on it.

Related: A Comprehensive Comparison of Docker vs. Kubernetes

Securing Kubernetes environments

There are three general areas of focus to start with: 

• Align cluster configurations with security best practices, such as the U.S. Center for Internet Security (CIS) or National Security Agency (NSA) guidelines and standards.  To do this, start by assessing the security posture of the deployment file for your cluster (infrastructure as code file). 
• Ensure that the applications running on your cluster contain no known vulnerabilities and enforce runtime security policies, making it harder for an attacker to abuse those containers. It’s important to gain control and visibility over the security posture of applications that are running in your environment and assess the risk which hides in both image contents and configuration
• Enforce credentials protection.

We have found that the defense-in-depth approach is the best way to introduce the necessary security barriers. This security technique for securing cloud native systems is called “The 4C Security Model” because it is divided into four different layers: cloud, cluster, container, code. Addressing all these layers ensures comprehensive security coverage from development to deployment.

It’s also imperative to address the overly permissive defaults associated with Kubernetes objects (roles and subjects, such as service accounts). You need to gain visibility into your role-based access control posture within Kubernetes clusters and gain a clear view of their Kubernetes environment, highlighting the most pressing issues that require immediate attention.

Finally, don’t forget automation. Open source software tools such as Kubescape help DevOps teams automate risk management and compliance with policy-driven automation that replaces onerous manual processes and prioritizes remediation in your environment.