Kubernetes has firmly established itself as the leading platform for orchestrating containerised applications. Complementing it, Helm serves as the go-to package manager for managing deployments within Kubernetes clusters.
Helm charts are YAML-based blueprints used to define and install Kubernetes resources tailored to various use cases. Users can either craft their own charts or use publicly available ones, which simplifies the deployment of container workloads significantly.
However, many of these public charts include settings that expose services externally, via mechanisms such as LoadBalancer or NodePort, without incorporating best security practices. As with all application-specific security considerations, there’s no “one size fits all”. These charts are often designed to work out-of-the-box, prioritising functionality over security, and therefore require careful customisation to meet specific security needs.
This lack of consideration around security best practices can lead to applications being misconfigured, exposing them to potential threats. Just last week, Microsoft security researchers identified significant security vulnerabilities in default Kubernetes Helm charts, warning that these pre-configured setups can expose sensitive data and cloud resources due to inadequate authentication and network restrictions.
This oversight can lead to misconfigurations that expose workloads to threats. Those same Microsoft security researchers revealed critical vulnerabilities in several widely used Helm charts, pointing out that these charts often lack proper network restrictions and authentication. Their research highlights how some developers frequently deploy these templates with minimal or no modification, inadvertently opening up attack vectors.
Real-world examples of exposed charts
To highlight the extent of this issue, Microsoft analysed Helm charts for several popular open-source applications:
- Apache Pinot: A real-time OLAP datastore, where core components such as pinot-controller and pinot-broker were exposed through LoadBalancer services (without requiring authentication).
- Meshery: A cloud-native infrastructure management tool that allowed public sign-up via an exposed endpoint, potentially enabling unauthorised users to manipulate cluster resources.
- Selenium Grid: Frequently targeted in attack campaigns, these charts often lacked authentication, allowing threat actors to gain access to browser automation instances.
Many workloads were exposed directly to the internet without protections like access control or segmentation - especially dangerous when the workloads can access sensitive data or carry out privileged actions.
Best practices for securing Helm charts
The best recommendation is to take these public Helm chart examples and modify them for your specific use-case and security requirements. If you are modifying or writing your own Helm charts from scratch, here are a few practical strategies to secure your Helm-based deployments:
- Version control and storage:
Keep charts in Git repositories for better traceability, rollback capability, and collaboration. Store and serve them via HTTPS from trusted Helm repositories. - Repository hygiene:
Use upstream proxies and cache trusted charts.
Avoid relying on unknown or unverified sources. - Chart validation:
Use tools like helm lint to catch syntax and structural issues early.If it encounters issues that break with convention or recommendation, for example missing a ‘version’ field, it will emit an ERROR message.
- Consistent versioning:
Stick to Semantic Versioning (SemVer) for both chart and application versions.This is a best practice that ensures predictability, repeatability, and traceability across deployments. Avoid ambiguous tags like latest to ensure repeatability and timely patching.
- Testing
Develop test scenarios using helm test to validate chart functionality. Even a basic test pod querying your application can add confidence.
Here’s a complete and reusable test scenario that you can include in your Helm chart to test a basic HTTP service.
Here’s the directory structure. The test is scoped to the test-connection.yaml file:
Running helm test my-app-release will deploy a test pod that runs cURL against your my-app service endpoint on port 8080. It fails if the endpoint is unreachable or unhealthy. If the pod exits with a non-zero code, Helm will report the test as failed.
- Signing and verification
Sign charts with helm package --sign and verify them with the helm install --verify command to ensure integrity and trustworthiness.
Data Provenance is a record of where your data came from and how it reached its current form. It describes the origin of a data file, any transformations that have been made to that file, and any persons or organizations associated with that file.
And this is what the provenance file looks like when you run ‘cat’ on the my-app-0.0.1.tgz.prov file
If you run helm verify on the my-app-0.0.1.tgz file, you get an error from Helm complaining that the signature doesn’t match:Error: openpgp: invalid signature: hash tag doesn't match
Alternatively, running the helm install –verify command will automatically check the provenance file.
- CI/CD integration:
Automate chart testing, signing, and releases using GitHub Actions or similar pipelines. For example, helm/charts-repo-actions-demo could provide some inspiration on how to create a GitHub actions workflow to test and release a chart
Secure-by-design chart development
When building Helm charts, remember that Helm itself does not enforce security. Here are further measures you can take:
- Apply RBAC (Role-Based Access Control):
Restrict the privileges of Kubernetes objects created by your chart.
Avoid assigning broad roles like cluster-admin. - Use Secure Defaults:
Don’t use default credentials. We could write at length about secrets management.
Either enforce randomised or user-provided secrets and always be mindful of upgrade scenarios. - Minimise Exposure:
Limit the number of components and only expose services as needed.
Avoid monolithic charts that include unnecessary features, or Super Charts that promise to deploy everything and anything in a single chart template. - Audit Rendered Resources:
Before deploying, use the helm template command to preview the actual Kubernetes objects being created. This allows you to catch unintended exposures or misconfigurations. - Clean Up Unused Releases:
Remove unused Helm releases to reduce your attack surface.
There are a few creative solutions to the deletion of stale releases. - Stay Up to Date:
Regularly update Helm itself, along with all charts and dependencies it manages.
The Helm upgrade command upgrades your release to a new version of a chart. - Encrypt Kubernetes Secrets:
Use proper encryption tools for storing secrets.
Kubernetes’ base64 encoding does not offer real security.
Addressing dependency risks and automating security
Cloudsmith recommends organisations thoroughly review and customise Helm chart configurations before deploying to production environments. As the number of Helm charts being used in your company increases, so too does the need for:
- Scanning for vulnerabilities: Without automated scanning, vulnerabilities in Helm charts will likely go unnoticed. By integrating vulnerability identification tools like Trivy with automated quarantined policies using Open Policy Agent (OPA), DevOps teams can work with security to detect and mitigate security issues in real time.
- Managing dependencies carefully: Many charts include other charts or container images that might have their own vulnerabilities. Keeping them updated is critical to maintaining a secure posture. Similarly, mapping the relationships between these underlying dependencies allows teams to actually mitigate the associated risks.
Centralising your software supply chain by managing all Helm charts and container images from a single trusted source gives you visibility, traceability, and control. This approach helps detect tampering, prevent misconfigurations, and enforce compliance controls from development through deployment.
By using trusted repositories like Cloudsmith and incorporating automated scanning, signing, and versioning workflows, your team can confidently secure Kubernetes deployments and protect your applications from emerging threats.
Want more? Watch my webinar Identifying vulnerabilities in public Kubernetes Helm charts.
This article was sponsored by Cloudsmith for PlatformCon 2025.
