Security experts widely agree on a prediction for Kubernetes in 2019 and beyond: As adoption increases, so will the risks – as has been the case for many enterprise technologies, such as mobile.
“The highly dynamic nature of container environments orchestrated by Kubernetes presents of number of specific security challenges that are only going to become more prominent as enterprise adoption increases,” says Gary Duan, CTO and co-founder NeuVector.
As Kubernetes’ star rises, it becomes a more interesting target for bad guys.
“The rapid rise in adoption of Kubernetes is likely to uncover gaps that previously went unnoticed on the one hand, and on the other hand gain more attention from bad actors due to a higher profile,” says Amir Jerbi, CTO at Aqua Security.
One notable such gap came to light in late 2018: CVE-2018-1002105, a privilege escalation vulnerability.
In a blog post, Ashesh Badani, vice president and general manager, OpenShift, Red Hat, put the issue in plain terms: “This is a big deal.”
“The privilege escalation flaw makes it possible for any user to gain full administrator privileges on any compute node being run in a Kubernetes cluster,” Badani explained. “Not only can this actor steal sensitive data or inject malicious code, but they can also bring down production applications and services from within an organization’s firewall.”
OpenShift quickly released updates to address the issue, as did the underlying Kubernetes project. “This”, as Mike Bursell, Chief Security Architect at Red Hat points out, “is one of the benefits of deploying a product with both an active community and commercial support. The response to the problem was very swift, and the community is working to improve the security of the project as a whole.”
[ Want to help others understand Kubernetes? Check out our related article, How to explain Kubernetes in plain English. ]
“CVE-2018-1002105 served as a warning shot to the DevOps and IT security world that unsecured Kubernetes clusters can and will be targeted and exploited,” Duan says.
Experts point to several overlapping categories of issues that deserve focus moving forward. These include:
1. Application and environment misconfigurations
A misconfiguration can mean a vulnerable container, which then potentially enables an attacker greater access within that container’s environment, as well as other potential risks.
“Application misconfigurations or vulnerabilities can leave Kubernetes containers running in pods exposed to compromise, allowing attackers to then probe the environment for further weaknesses,” Duan says. “Attackers will then seek to establish unauthorized connections between pods to disrupt applications or gain access to sensitive data.”
Misconfigurations – which in some cases may be a matter of simply not paying attention to configurations – will be a considerable source of risk as more organizations deploy containerized applications to production environments, according to Chris Roberts, an advisor at Attivo Networks.
“How many of the installations out there are still relying upon defaults? How many have weak configurations, interconnects, and/or rely upon code bases that are not well-validated, understood, or tested/supported?” Roberts asks. “Arguably, the lack of well-configured environments that are not being monitored or protected will have a huge impact on the number of vulnerabilities in 2019.”
2. Container-level issues
Whether the result of misconfiguration or other issues – including poor security hygiene in general – one vulnerable container can lead to bigger problems, as Marc Feghali, founder and VP of product management at Attivo Networks, explains.
“If attackers compromise a container, they can attempt to escalate privileges to take control of additional containers or the entire cluster,” Feghali says. “If attackers compromise a privileged container or steal credentials with privileges to manage the Kubernetes cluster, they can cause a great deal of damage by accessing the cluster and any data traffic between containers. This can lead to data theft or resource-hijacking.”
[ Get the related Red Hat whitepaper: Ten Layers of Container Security. ]
3. The orchestrator itself as a target
“Beyond the threat of attacks that escalate within the internal traffic of container environments, the Kubernetes infrastructure itself presents an attack surface for malicious actors to exploit,” Duan says. (The CVE-2018-1002105 threat is an example of such an attempt.) “Attackers will target Kubernetes resources, including the API Server or Kubelets. Attackers can then proceed to leverage privilege escalation mechanisms that enable them to gain cluster admin privileges from a compromised container,” Duan says.
Kubernetes’ cloud-native nature made it an attractive vector for threats as cryptocurrency mining malware.
“On the threat front, while cryptocurrency mining continues to be a popular attack vector, we expect more sophisticated attacks to target sensitive data, and try to use Kubernetes apps as a doorway into other systems,” Jerbi at Aqua Security says.
But there’s a silver lining here: While bad actors will pay closer attention to Kubernetes, a growing user community will at the same time more actively ferret out vulnerabilities before they can be put to malicious use. Just be ready to patch and update, Jerbi says.
“It’s a natural outcome of having more users putting it through rigorous testing, and across different use cases,” Jerbi says.
4. Mind what production deployments expose
Some organizations and teams will learn the hard way that running Kubernetes in a test or dev environment and running it in production are not one and the same. That will bear particularly true from a security perspective, as production deployments expose misconfigurations and other vulnerabilities.
Wei Lein Dang, VP of product at StackRox, expects an increase in runtime threats that teams may not become aware of until they move to production.
“As companies move more deployments into production, that migration increases the volume of vulnerable workloads at runtime,” Dang says.
While risk exists in any system, moving to containers and orchestration requires new security practices and tools, and a willingness to navigate the learning curve in a collaborative manner among different roles and stakeholders. A healthy DevOps or DevSecOps culture can help. Just don’t make the mistake of thinking that “secure in dev” means “secure everywhere.”
“Understanding the full lifecycle of the container and all the dependencies has to be something done with the collaboration of development, testing, OT/IT, and security,” Roberts at Attivo Networks says. “The dependencies between any testing and production environment differ greatly and therefore the old adage that you can test [and] secure in dev and it’ll work in PROD are no longer valid.”
The good news: There’s plenty that IT leaders and their teams can do to proactively deal with the risks attendant to a dynamic, powerful Kubernetes platform. In an upcoming post, we’ll share our experts' top tips and advice for managing those risks.
[ Kubernetes terminology, demystified: Get our Kubernetes glossary cheat sheet for IT and business leaders. ]
