Understanding the 3 Classes of Kubernetes Risk

Editor's note: For more tools and techniques for securing Kubernetes, read our companion article in the DR Tech section.

A few short years ago, not many people had heard of the word "Kubernetes." Today, the open source container tool is becoming increasingly ubiquitous, with a rapidly growing number of businesses using Kubernetes to facilitate a more streamlined and scalable application development process. But as its convenience and scalability lead to greater adoption, protecting Kubernetes environments has become a challenge. Security and IT leaders who want to keep their Kubernetes environments secure must be aware of the three primary classes of risk they face — and how to mitigate them.

Class 1: Accidental Misconfigurations

Thus far, accidental misconfigurations have been the most common form of Kubernetes risk — the one most security experts are likely to be familiar with. Misconfigurations can occur anytime a user does something that unintentionally introduces risk into the environment. That might mean adding a workload that grants unnecessary permissions or accidentally creating an opening for someone from the anonymous Internet to access the system. Kubernetes is still relatively new to many, which means it can be easy to make mistakes.

Fortunately, there are several ways to mitigate misconfigurations. Just about everything that happens in Kubernetes automatically produces an audit log, and security teams can monitor those logs for anomalous signs. Many businesses do this by sending the logs to a security information and event management (SIEM) platform, which can identify predetermined signs of misconfiguration. Additionally, tools (both paid and open source) are available that can be used to scan your Kubernetes environment for best practice violations. Once the problem is identified, an alert can be sent to the appropriate party and the problem triaged.

Class 2: Software Supply Chain

The most common way software ends up running in Kubernetes is via deployed container images. Those images are deployed to Kubernetes for distribution across the environment, which makes them an ideal target for attackers. In today's world, businesses rely heavily on third-party software with code they didn't write — and anytime a business introduces outside code into its environment, risks are involved. If a compromised image is introduced, that image may proliferate throughout the environment, distributing malicious code wherever it goes.

Thankfully, controls can help. It's always better to identify compromised code before it enters the system rather than remediate it afterward, and consumers can seek out developer security platforms and other solutions capable of scanning code and images to look for signs of malicious code and prevent it from being deployed. That said, it's impossible to prevent everything, which means continuous monitoring at runtime is also important. Keeping an eye out for suspicious behavior or code that comes from an unknown source can help identify potential security threats before they have a chance to escalate.

Class 3: Active Attacker Compromise

This type of threat gets the most attention because it's the "flashiest," but, in reality, it's the least common. Yes,  the threat of an attacker specifically working to compromise a business' Kubernetes environment always exists. For now, these instances are rare, but that is likely to change as businesses continue to adopt Kubernetes. There are a number of ways attackers have found success targeting Kubernetes environments. Cross-site request forgery (CSRF) attacks involve convincing an application to make a request on the attacker's behalf, while remote code execution (RCE) attacks convince an application to run a command of the attacker's choice. In both cases, the target is commonly credential data, which the attacker can then use to grant themselves additional access to the environment.

Avoiding this class of risk often boils down to ensuring your software and infrastructure follow security best practices and monitoring to catch potential vulnerabilities. Developer security awareness and education are useful tools, but it's also important to reduce the opportunity for error with security controls — your environment should never be one mistake away from a serious vulnerability. Fortunately, controls are improving. Cloud security posture management (CSPM) tools and static analysis tools can help flag and prevent vulnerabilities before they are deployed. It's also crucial to have visibility and monitoring at runtime to detect issues that slip through the cracks. This can be accomplished by monitoring audit logs and installing container security solutions to detect when something goes wrong at runtime.

Understand — and Mitigate — Kubernetes Risks

Kubernetes is still relatively new, but its usefulness has driven rapid adoption. This is great for the developers who use it, but it poses an undeniable challenge for security and IT teams scrambling to keep up. The first step toward securing Kubernetes environments is understanding the risks they pose and identifying the ways in which those risks can be mitigated. With security lagging behind adoption, attackers are beginning to view Kubernetes as an attractive target — and businesses using Kubernetes need to avoid making themselves easy prey.