Like any other platform, Kubernetes environments can sometimes contain security vulnerabilities. To protect against potential cyberthreats, IT teams should periodically scan for and remediate Kubernetes vulnerabilities.
Over the years, I’ve met IT pros who were reluctant to perform vulnerability scans because of the perception that doing so means hiring a pricey consultant who specializes in penetration testing. In the case of Kubernetes, however, there are numerous open source tools available to perform a DIY vulnerability scan.
Common types of vulnerabilities in Kubernetes environments
There are two main types of security weaknesses to look out for in a Kubernetes environment: misconfigurations and vulnerabilities in containers themselves.
Misconfigurations
A security vulnerability resulting from a misconfiguration means the Kubernetes environment is configured in a way that violates established security best practices.
For example, for security reasons, IT teams should isolate the nodes within a Kubernetes cluster to shield them from direct exposure to the internet. As such, a Kubernetes deployment with internet-facing nodes would violate security best practices and pose a serious security risk.
This is an extreme instance of a Kubernetes vulnerability stemming from a configuration that violates security best practices, but there are countless others that might be less obvious. For example, security professionals often recommend allowlisting to prevent or detect unauthorized processes. A Kubernetes cluster that is not configured to use allowlisting could be vulnerable to attacks.
Vulnerable container images
Vulnerabilities can exist within container images, even if the underlying Kubernetes infrastructure is properly configured according to the latest security best practices. This problem occurs if the container image comes from an untrustworthy source or the software contained within the image is not configured securely.
For example, imagine a Kubernetes environment that hosts a series of containers acting as front-end web servers. If those web servers are using default passwords, then a serious weakness exists, even if the underlying infrastructure is secure.
Default passwords are far from the only type of image-level vulnerability. A security weakness could also stem from something as simple as an image running a process the workload doesn’t require.
Vulnerability scans for Kubernetes
There are many ways an organization can spot-check its Kubernetes security without performing a full-blown vulnerability scan. For example, an organization might run a port scan against its Kubernetes nodes to test for open ports.
Generally, however, performing a full vulnerability scan is the best option. Comprehensive Kubernetes vulnerability scanning provides a more complete assessment of a Kubernetes environment’s security compared with port scans and other one-off tests.
Kube-hunter, an open source tool from Aqua Security, is likely the most widely used vulnerability testing tool for Kubernetes. However, there are many other options to choose from to check Kubernetes environments for exploitable vulnerabilities.
Other examples of open source tools for Kubernetes vulnerability scanning include the following:
- Clair, from RedHat Quay.
- KubeClarity, from Cisco OpenClarity.
- Kube-bench, from Aqua Security.
- Kube-scan, from VMware Octarine.
- Kubeaudit, from Shopify.
Vulnerability scanning best practices
Although it’s possible to run an ad hoc vulnerability scan to look for existing Kubernetes vulnerabilities, doing so isn’t always the best option. Instead, look for ways to integrate vulnerability scanning into existing container deployment workflows.
This process will be different for every organization, but should begin during the build process. Any builds that the organization creates should be checked immediately for weaknesses. In addition, check for vulnerabilities after a build is complete — in some cases, a vulnerability might not show up until an application is combined with a base image.
If vulnerabilities are discovered, address the issue right then and there. Prompt remediation ensures problems are solved before a build moves into the production environment.
If you’ve tested your Kubernetes infrastructure, scanned your builds throughout the development and deployment processes, and addressed any detected vulnerabilities along the way, then your Kubernetes workloads should be secure. But even so, make sure to scan both your production and development environments periodically for new vulnerabilities.
Don’t assume a workload will never contain vulnerabilities just because no vulnerabilities existed at the initial deployment — cyber attacks are becoming increasingly common and sophisticated. Periodic scans are the best way to ensure you’re staying on top of new vulnerabilities that might be hiding in your Kubernetes environment.
