The Risk of Default Configuration: How Out-of-the-Box Helm Charts Can Breach Your Cluster

Authors:

Michael Katchinskiy, Security Researcher, Microsoft Defender for Cloud Research
Yossi Weizman, Principal Security Research Manager, Microsoft Defender for Cloud Research

 

Have you ever used pre-made deployment templates to quickly spin up applications in Kubernetes environments?  While these “plug-and-play” options greatly simplify the setup process, they often prioritize ease of use over security. 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.

Cloud-native applications are software systems designed to fully leverage the flexibility and scalability of the cloud. These applications are broken into small services called microservices. Usually, each service is packaged in a container with all its dependences, making it easy to deploy across different environments. Kubernetes then orchestrates these services, automatically handling their deployment, scaling, and health checks.

Out-of-the-Box Helm Charts

Open-source projects usually contain a section explaining how to deploy their apps “out of the box” on their code repository. These documents often include default manifests or pre-defined Helm charts that are intended for ease of use rather than hardened security. 

Among other issues, two significant security concerns arise: (1) exposing services externally without proper network restrictions and (2) lack of adequate built-in authentication or authorization by default.

Internet exposure in Kubernetes usually originates in a LoadBalancer service, which exposes K8s workloads via an external IP for direct access, or in Ingress objects, which manage HTTP and HTTPS traffic to internal services. If authentication is not properly configured, both can allow insecure access to the applications, leading to unauthorized access, data exposure, and potential service abuse.

Consequently, default configurations that lack proper security controls create a severe security threat. Without carefully reviewing the YAML manifests and Helm charts, organizations may unknowingly deploy services lacking any form of protection, leaving them fully exposed to attackers. This is particularly concerning when the deployed application can query sensitive APIs or allow administrative actions, which is exactly what we will shortly see.

Apache Pinot default configuration

Apache Pinot is a real-time, distributed OLAP datastore designed for high-speed querying of large-scale datasets with low latency. For Kubernetes installations, Apache Pinot’s official documentation refers users to a Helm chart stored in their official Github repository for a quick installation:

Apache Pinot deployment guide

While Apache Pinot's documentation states that the provided configuration is a reference setup that users may want to modify, they don’t mention that this configuration is severely insecure, leaving the users prone to data theft attacks: The default installation exposes Apache Pinot’s main components to the internet by Kubernetes LoadBalancer services without providing any authentication mechanism by default.

Apache Pinot's note

Specifically, the pinot-broker and pinot-controller services allow unauthenticated access to query the stored data and manage the workload. Below is a screenshot of Pinot’s dashboard, exposed by the pinot-controller service in port 9000, allowing full management of the Apache Pinot and access to the stored information. 

Recently, Microsoft Defender for Cloud identified several incidents in which attackers exploited misconfigured Apache Pinot workloads, allowing them to access the data of Apache Pinot users.

 

Apache Pinot dashboard

Not Just Apache Pinot

To determine how widespread this issue is, we conducted a thorough investigation by searching using GitHub Code Search repositories for YAML files containing strings that may indicate on misconfigured workload, such as “type: LoadBalancer”. We then sorted the results by their popularity and deployed the applications in controlled test environments to assess their default security posture. Our goal was to find out which applications are exposed to the internet by default, more critically, whether they incorporate any authentication or authorization mechanisms.

Here's what we found: The majority of applications we evaluated had at least some form of basic password protection, though the strength and reliability of these measures varied significantly. A small but critical group of applications either provided no authentication at all or used a predefined user and password for logging in, making them prime targets for attackers.

Sign me up

Several applications appeared secure at first glance, but they allowed anyone to create a new account and access the system. This clearly does not provide effective protection when exposed to the internet. This highlights how a “default by convenience” approach can invite risk when security settings are not thoroughly reviewed or properly configured.

Meshery is an engineering platform for collaborative design and operation of cloud native infrastructure.

By default, when installing Meshery on your Kuberentes cluster via the official Helm installation, the app’s interface is exposed via an external IP address. We discovered that anyone who can access the external IP address can sign up with a new user and access the interface which provides extensive visibility into cluster activities and even enable the deployment of new pods. 

Meshery registration page

These capabilities grant attackers a direct path to execute arbitrary code and gain control of underlying resources if Meshery is not secured or restricted to internal networks only.

Meshery dashboard

Selenium Grid

Selenium is a popular tool for automating web browser testing, with millions of downloads of its container image. In the last few months, we’ve observed multiple attack campaigns specifically targeting Selenium Grid instances that lack authentication. In addition several security vendors, including Wiz and Cado Security, have reported these attacks. While the official Helm chart for Selenium Grid doesn’t expose it to the internet, there are several widely referenced GitHub projects that do -  using a LoadBalancer or a NodePort.

In one Selenium deployment example from the official Kubernetes repository, Selenium is set up to use a NodePort. This configuration exposes the service on a specific port across all nodes in your cluster, meaning that the firewall rules set up in your network security group become your primary and often only line of defense. If you'd like to see additional examples, try using GitHub Code Search with this query.

Example of a risky Selenium Grid service configuration found in GitHub

Awareness of the risks associated with exposing services has grown over the years, and many developers today understand the dangers of leaving applications wide open. Even so, some applications simply weren’t built for external access and don’t provide any built-in authentication. Their own documentation often warns users not to expose these services publicly. Yet, it still happens, usually for convenience, leaving entire clusters at risk.

If you still remain unconvinced, look to the countless unsecured Redis, Elasticsearch, Prometheus, and other instances that are regularly surfaced in Shodan scans and security blog posts. Despite years of warnings, these applications are still being exposed.

Conclusion

Many in-the-wild exploitations of containerized applications originate in misconfigured workloads, often when using default settings. Relying on “default by convenience” setups pose a significant security risk. To mitigate these risks, it is crucial to:

1. Review before you deploy: Don’t rely on default configurations. Review the configuration files and modify them according to security best practices. This includes enforcing strong authentication mechanism and network isolation.
2. Regularly scan your organization to exposed services: Scan the publicly facing interfaces of your workloads. While some workloads should allow access from external endpoints, in many cases this exposure should be reconsidered.
3. Monitor your containerized applications: Monitor the running containers in your environment for malicious and suspicious activities. This includes monitoring of the running processes, network traffic, and other activities performed by the workload. Also, many container-based attacks involve deployment of backdoor containers in the cluster. Monitor the Kubernetes cluster for unknown workloads and the nodes for unknown pulled images.

Strengthening Cluster Security with Microsoft Defender for Cloud

Microsoft Defender for Cloud (MDC) helps protect your environment from misconfigurations, including risky service exposure. For example, MDC alerts on the exposure of Kubernetes services which are associated with sensitive interfaces, including Apache Pinot.

Exposed Apache Pinot alert

With Microsoft Defender CSPM, you can get an overview of the exposure of your organization’s cloud environment, including the containerized applications. Using the Cloud Security Explorer, you can get full visibility of the internet exposed workloads in your Kubernetes clusters, enabling you to mitigate potential risks and easily identify misconfiguration.

Cloud Security Explorer query for exposed services

Read more about Containers security with Microsoft Defender for containers here.