Kubernetes Data at Risk Microsoft Flags Default Helm Chart Security Gaps

Microsoft is raising a red flag about using readily available templates, especially default Helm charts, when deploying applications on Kubernetes. These seemingly convenient shortcuts might be leaving your systems vulnerable to misconfigurations and data leaks.

The Microsoft Defender for Cloud Research team, Michael Katchinskiy and Yossi Weizman, warn that while these "plug-and-play" options simplify setup, they often sacrifice security for the sake of ease.

"A large number of applications end up being deployed in a misconfigured state by default," they explain, "exposing sensitive data, cloud resources, or even the entire environment to attackers."

What's the Deal with Helm?

Helm is essentially a package manager for Kubernetes. Think of it like apt or yum, but for deploying applications and services onto Kubernetes clusters. It's a project under the Cloud Native Computing Foundation (CNCF).

Helm uses something called charts to package Kubernetes applications. These charts are basically YAML files and templates that describe the resources and configurations needed to deploy the app.

The Problem: Convenience vs. Security

Microsoft highlights that open-source projects often provide default manifests or pre-defined Helm charts. The catch? These often prioritize user-friendliness over robust security, leading to common issues:

• Exposing services externally without proper network restrictions.
• Lacking adequate built-in authentication or authorization.

So, if you're using these projects without carefully checking those YAML manifests and Helm charts, you could unintentionally expose your applications to attackers. And that's a big problem if the application handles sensitive APIs or administrative actions.

Examples of Risky Projects

Microsoft pointed to a few projects where default configurations could leave your Kubernetes environment vulnerable:

• Apache Pinot: Its main components, pinot-controller and pinot-broker, are exposed to the internet without authentication by default.
• Meshery: Its interface is exposed via an external IP address, allowing anyone to create an account and deploy new pods, potentially leading to arbitrary code execution.
• Selenium Grid: Exposes a NodePort service, relying solely on external firewall rules for defense.

What You Can Do

To minimize the risks, Microsoft recommends:

• Carefully reviewing and modifying default configurations based on security best practices.
• Regularly scanning publicly accessible interfaces.
• Monitoring running containers for suspicious activity.

"Many in-the-wild exploitations of containerized applications originate in misconfigured workloads, often when using default settings," the researchers emphasized. "Relying on 'default by convenience' setups pose a significant security risk."