Microsoft Warns Default Helm Charts Could Leave Kubernetes Apps Exposed to Data Leaks


Microsoft has warned that using pre-made templates, such as out-of-the-box Helm charts, during Kubernetes deployments could open the door to misconfigurations and leak valuable data.

“While these ‘plug-and-play’ options greatly simplify the setup process, they often prioritize ease of use over security,” Michael Katchinskiy and Yossi Weizman from the Microsoft Defender for Cloud Research team said.

“As a result, a large number of applications end up being deployed in a misconfigured state by default, exposing sensitive data, cloud resources, or even the entire environment to attackers.”

Helm is a package manager for Kubernetes that allows developers to package, configure, and deploy applications and services onto Kubernetes clusters. It’s part of the Cloud Native Computing Foundation (CNCF).


Kubernetes application packages are structured in the Helm packaging format called charts, which are YAML manifests and templates used to describe the Kubernetes resources and configurations necessary to deploy the app.

Microsoft pointed out that open-source projects often include default manifests or pre-defined Helm charts that prioritize ease of use over security, particularly leading to two major concerns –

* Exposing services externally without proper network restrictions
* Lack of adequate built-in authentication or authorization by default

As a result, organizations using these projects without reviewing YAML manifests and Helm charts can end up inadvertently exposing their applications to attackers. This can have serious consequences when the deployed application facilitates querying sensitive APIs or permitting administrative actions.

Some of the identified projects that could put Kubernetes environments at risk of attacks are as follows –

* Apache Pinot, which exposes the OLAP datastore’s main components, pinot-controller and pinot-broker, to the internet via Kubernetes LoadBalancer services without any authentication by default
* Meshery, which exposes the app’s interface via an external IP address, thereby allowing anyone with access to the IP address to sign up with a new user, gain access to the interface, and deploy new pods, ultimately resulting in arbitrary code execution
* Selenium Grid, which exposes a NodePort service on a specific port across all nodes in a Kubernetes cluster, making external firewall rules the only line of defense


To mitigate the risks associated with such misconfigurations, it’s advised to review and modify them according to security best practices, periodically scan publicly facing interfaces, and monitor running containers for malicious and suspicious activities.

“Many in-the-wild exploitations of containerized applications originate in misconfigured workloads, often when using default settings,” the researchers said. “Relying on ‘default by convenience’ setups pose a significant security risk.”

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.