ARMO Tool Determines Security Posture of Kubernetes Clusters
ARMO has made available a Kubescape tool for testing whether Kubernetes clusters have been deployed securely. The Kubescape tool uses guidance for hardening the platform provided by the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA).
Based on a 52-page report the two U.S. security agencies collaboratively created, the ARMO tool is based on open source software the company created to secure Kubernetes environments using the Open Policy Agent (OPA) framework being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).
The core Kubescape platform retrieves the Kubernetes objects from the API server and then scans them using snippets developed by ARMO using the Rego query language created for OPA.
Jonathan Kaftzan, vice president of marketing and business development for ARMO, says the company is now adding a tool that employs that capability to determine the overall security posture of the Kubernetes environment. It identifies:
- Non-root containers
- Immutable container filesystem
- Secure container images
- Privileged containers
- hostPID, hostIPC privileges
- hostNetwork access
- allowedHostPaths field
- Protecting pod service account tokens
- Pods in kube-system and kube-public
- Resource policies
- Control plane hardening
- Encrypted secrets
- Anonymous requests
As more Kubernetes clusters are deployed in production environments, IT teams are discovering that the platform, by default, is not especially secure. IT teams are expected to navigate a wide range of potential settings that can be easily misconfigured. The ARMO tool is intended to make it easier for IT teams to discover misconfigurations that might be exploited by cybercriminals. The greater the number of Kubernetes clusters that are deployed in production environments, the greater the probability that cybercriminals will scan for known potential vulnerabilities. That can be especially problematic when developers with minimal appreciation for cybersecurity best practices have provisioned a Kubernetes cluster themselves.
Theoretically, at least, organizations that embrace DevSecOps are implementing best practices that prevent developers from making configuration mistakes. Unfortunately, it takes time for developers to learn cybersecurity best practices, which means the chances a Kubernetes cluster will be misconfigured are fairly high. It’s then up to cybersecurity professionals to identify which Kubernetes clusters might be prone to specific types of cyberattacks. More challenging still, Kubernetes cluster configurations are likely to change frequently as applications are added and updated.
With Kubernetes, much like every other platform that has come down the proverbial IT pike, security issues were an afterthought. The emphasis has been on providing IT teams with a highly flexible, open source platform that can scale resources up and down as required. The challenge is that all that flexibility creates opportunities for mistakes to be made.
It’s not clear the degree to which cybersecurity concerns might be slowing the overall adoption of Kubernetes. However, in the wake of a series of high-profile software supply chain breaches, there’s a lot more focus on the underlying infrastructure being used to build and deploy applications. It’s now only a matter of time before the cybersecurity teams tasked with securing those software supply chains start asking a lot more pointed questions about how Kubernetes clusters are actually configured.
