Helm has become a standard tool for deploying applications on Kubernetes. It simplifies the management of complex workloads by packaging Kubernetes resources into reusable charts, allowing teams to configure deployments across development, staging, and production without maintaining entirely separate manifests.
But that convenience comes with a security challenge. A Helm chart can define far more than an application’s deployment settings. It can configure service accounts, RBAC permissions, network policies, container security contexts, secret references, ingress rules, and access to cluster resources. A poorly designed chart can therefore introduce security weaknesses across every environment where it is installed.
The risk becomes more significant in organizations managing dozens of clusters, hundreds of services, and shared deployment pipelines. A chart copied across repositories can spread the same insecure defaults throughout the infrastructure. A values file can unintentionally disable a security control. A dependency can introduce resources that were never reviewed by the application team.
In 2026, securing Helm requires more than checking whether a chart installs successfully. DevOps and platform engineering teams need to treat charts as versioned infrastructure code, apply security policies before deployment, and verify the resulting Kubernetes resources against production requirements.
Why Helm Charts Can Become a Security Risk
Helm templates Kubernetes manifests using chart templates and configuration values. This makes it possible to reuse deployment definitions while adjusting settings for different environments.
The problem is that templates can also hide security-sensitive behavior behind configuration options.
A chart might create a service account with unnecessary permissions, enable privileged containers, expose an application through an overly permissive ingress, or omit resource limits. A deployment may appear healthy while running with more access than the application needs.
These risks often emerge through a combination of factors:
- Insecure default values inherited across environments.
- Overly permissive Kubernetes RBAC permissions.
- Containers running as root or with unnecessary Linux capabilities.
- Secrets stored directly in values files.
- Missing network policies and resource limits.
- Unpinned or unverified chart dependencies.
- Unreviewed changes to templates and deployment values.
- Production deployments that bypass policy checks.
The underlying issue is not Helm itself. Helm is a deployment and release-management tool. It does not automatically guarantee that the Kubernetes resources generated by a chart follow your organization’s security requirements.
A chart that deploys successfully is not necessarily a chart that deploys securely.
The First Problem: Insecure Defaults
Chart defaults influence how applications are deployed when teams do not explicitly override every setting. If those defaults are permissive, the resulting resources can inherit unnecessary risk.
Consider a deployment template that allows a container to run as root or leaves privilege escalation enabled. If the chart does not provide secure defaults, teams may unknowingly carry those settings into production.
A more security-conscious configuration can include settings such as:
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
seccompProfile:
type: RuntimeDefaultThese settings help restrict the container’s runtime privileges. They should be adapted to the application’s actual requirements, and the chart must correctly apply them to the generated Pod or container specification.
Teams should also understand that runAsNonRoot: true requires a compatible image and user configuration. A setting that cannot be satisfied by the image may prevent the workload from starting.
For production charts, security-sensitive settings should be explicit, documented, and validated. Teams should avoid making critical controls optional without a clear reason.
Kubernetes RBAC: The Permissions Problem
One of the most consequential Helm security mistakes is granting applications more Kubernetes permissions than they need.
A chart may create a service account and bind it to a ClusterRole with broad permissions. This can allow a compromised application to inspect resources, modify workloads, access configuration objects, or interact with other parts of the cluster beyond its intended responsibilities.
For example, an application that only needs to read selected objects in one namespace generally should not receive unrestricted access to secrets across the cluster.
A safer design uses least privilege:
- Create dedicated service accounts for workloads that need Kubernetes API access.
- Use namespace-scoped Roles and RoleBindings when cluster-wide permissions are unnecessary.
- Grant only the required API groups, resources, and verbs.
- Disable automatic service-account token mounting when the workload does not need Kubernetes API access.
- Review any ClusterRole or ClusterRoleBinding created by a chart.
A Helm values file may expose a setting such as automountServiceAccountToken: false, but that setting is only useful if the chart applies it correctly to the relevant Pod specification.
Likewise, disabling token mounting does not replace RBAC review for workloads that still need API access.
The goal is to ensure that compromising one application does not automatically give an attacker broad control over the Kubernetes environment.
Stop Putting Secrets in values.yaml
Helm values files are convenient for configuring deployments, but they are not a safe place for plaintext credentials.
A chart might require a database password, API token, signing key, or third-party service credential. Storing these values directly in a committed values.yaml file can expose them through source control, pull requests, local development environments, CI logs, and artifact repositories.
There is another important detail: Helm release information can include the rendered Kubernetes manifests and configuration values. Depending on the storage backend, access controls, and how a chart is configured, sensitive values can be retained in Helm release records. Base64 encoding a Kubernetes Secret does not provide encryption by itself.
A safer approach separates application configuration from secret delivery.
Teams can use a dedicated secrets manager, an external-secrets integration, or an approved secret-management mechanism that retrieves credentials at runtime. Where Kubernetes Secrets are used, organizations should configure appropriate access controls and encryption at rest and should restrict which service accounts can read them.
For example, a chart might reference an existing Secret rather than accepting a password directly:
database:
existingSecret: app-database-credentials
secretKey: passwordThe chart must be designed to consume these values correctly. The example does not create or secure the Secret by itself.
Production pipelines should also prevent secrets from being printed during template rendering, deployment, debugging, or failure handling.
Helm Template Logic Can Hide Dangerous Configuration
Helm templates use Go templating functions and chart values to generate Kubernetes manifests. Conditional blocks and configurable fields make charts flexible, but they can also make the final configuration difficult to review.
A chart may contain logic that conditionally enables host networking, privileged execution, broad ingress access, or elevated permissions. These options might be disabled in the default values but enabled by an environment-specific override.
This means reviewing values.yaml alone is not enough.
Security reviews should examine both the templates and the rendered output. The rendered manifests show what Helm will actually submit to Kubernetes for a particular configuration.
A practical validation step is:
helm lint ./my-chart
helm template my-app ./my-chart -f values-production.yamlhelm lint checks a chart for common structural and formatting issues. helm template renders the manifests locally so they can be inspected or passed to additional policy checks.
Neither command independently proves that a chart is secure. They are useful steps in a broader validation pipeline.
Chart Dependencies Can Expand the Attack Surface
Helm charts often depend on other charts to deploy databases, ingress controllers, monitoring components, queues, or supporting services.
Dependencies make reuse easier, but they also introduce another layer of supply-chain risk.
A dependency may change its default permissions, add new resources, introduce a vulnerable image, or modify its templates in a later release. If teams update dependencies without reviewing the changes, the resulting deployment may differ significantly from what they previously approved.
A secure dependency-management process should include:
- Pinning dependency versions.
- Reviewing changes before updating chart dependencies.
- Verifying chart sources and publisher trust.
- Scanning container images and application dependencies.
- Inspecting rendered manifests after updates.
- Tracking the origin and version of third-party charts.
Helm supports chart dependency declarations and lock files, but those mechanisms do not automatically prove that a dependency is trustworthy. Teams still need a controlled process for reviewing, sourcing, and updating charts.
The same principle applies to container images referenced by chart values. Pinning an image to an immutable digest can reduce uncertainty compared with relying on a mutable tag such as latest.
Misconfigured Network Exposure
A Helm chart can expose an application through a Kubernetes Service, an Ingress resource, or a Gateway API configuration, depending on the chart and cluster architecture.
A configuration intended for internal use can become externally reachable if exposure settings are enabled without appropriate controls. An ingress may lack required authentication, a service may use an inappropriate type, or a chart may create an endpoint that was not included in the original threat model.
Teams should review:
- Whether external exposure is required.
- Which hostnames and paths are accessible.
- How TLS is configured and certificates are managed.
- Whether authentication and authorization are enforced.
- Whether network policies restrict unnecessary communication.
- Whether internal services are exposed through public load balancers.
Network policies also require attention to cluster behavior. A policy has no effect unless the cluster’s networking implementation supports and enforces it, and an overly restrictive policy can break legitimate service communication.
Security checks should therefore consider both the generated resources and the actual cluster networking model.
Resource Limits Are Part of Security
Security discussions often focus on permissions and secrets, but resource configuration matters too.
A workload without appropriate CPU and memory limits may consume excessive cluster resources. A compromised or malfunctioning service can place pressure on neighboring workloads and destabilize shared infrastructure.
Helm charts should provide sensible resource requests and, where appropriate, limits that can be adjusted according to workload requirements. Teams should also consider replica limits, autoscaling configuration, storage requests, and Kubernetes quotas.
However, resource settings should not be copied blindly between services. A latency-sensitive API, a batch-processing job, and a memory-intensive worker may require very different configurations.
The objective is to make resource behavior explicit and prevent uncontrolled consumption while preserving application reliability.
Enforce Security Policies Before Deployment
Manual review alone is difficult to scale across hundreds of charts and repositories.
A stronger approach is to add automated checks to the CI/CD pipeline. After rendering a chart, the pipeline can inspect the generated Kubernetes manifests against organizational security policies.
Checks can flag or reject configurations such as:
- Containers running as root where non-root execution is required.
- Privileged containers or unnecessary Linux capabilities.
- Missing resource requests or limits.
- Host path mounts that violate policy.
- Overly broad RBAC permissions.
- Unapproved container registries or mutable image references.
- Ingress configurations that violate exposure requirements.
- Missing security contexts or required labels.
Tools such as KubeLinter, Checkov, and Kyverno can contribute to different parts of this workflow. Their roles differ: some focus on static configuration analysis, while policy engines such as Kyverno can also enforce policies within Kubernetes when configured for that purpose.
A representative pipeline looks like this:
Chart source → Dependency review → Helm lint → Render manifests → Security scanning → Policy validation → Approval → Deployment
The pipeline should stop when a required security policy fails. Exceptions should be documented, time-bound where practical, and reviewed rather than silently ignored.
Use Helm With GitOps Without Trusting Every Change
Many Kubernetes teams use GitOps tools such as Argo CD or Flux to manage deployments from version-controlled configuration.
GitOps can improve traceability because the desired state is stored in Git and reconciled by a controller. But GitOps does not automatically make a Helm chart secure.
If an insecure chart or values file is merged into the trusted repository, the controller may faithfully apply the insecure configuration.
A secure GitOps workflow should therefore combine protected branches, required reviews, policy validation, pinned chart versions, and controlled production promotion.
Teams should also review who can change repository credentials, deployment permissions, and the configuration used by the GitOps controller. A compromised source repository or overly privileged controller can undermine otherwise strong chart security.
The objective is to make approved configuration changes traceable and ensure that security policies are checked before those changes reach a cluster.
Avoid Treating helm install as a Security Check
The commands used to install or upgrade a chart primarily manage deployment behavior. A successful release does not establish that the chart follows every security requirement.
For example:
helm upgrade --install my-app ./my-chart \
--namespace production \
--values values-production.yamlThis command can install or upgrade a release, but it does not independently validate the complete security posture of the resulting application.
Before production deployment, teams should render the chart, inspect the generated manifests, apply automated policy checks, and validate runtime controls in the cluster.
Where supported by the deployment workflow, Kubernetes admission policies can provide another enforcement layer. This helps prevent noncompliant resources from being created even if an earlier pipeline check is missed.
Pre-deployment validation and runtime enforcement serve complementary purposes. Neither should be treated as a complete replacement for the other.
Manage Chart Versions and Release Integrity
Helm charts should be treated as versioned software artifacts.
Teams should know which chart version was deployed, which dependencies it included, which values were applied, and which source revision produced the release. Without this information, investigating a security incident or reproducing a deployment can become unnecessarily difficult.
A mature release process should use version control, reviewed dependency updates, trusted chart repositories or registries, artifact integrity checks, and deployment records.
Where appropriate, teams can use chart provenance and signature-verification capabilities supported by their Helm tooling and distribution process. They should verify the trust mechanism used by their organization rather than assuming that a version number alone proves artifact authenticity.
Release records should also avoid exposing sensitive values. Auditability should not come at the cost of storing unnecessary credentials.
Monitor the Workload After Deployment
A chart may pass static checks and still produce unexpected runtime behavior because of cluster-specific configuration, external dependencies, admission mutations, or operational conditions.
DevOps teams should monitor the deployed workload for changes in permissions, unexpected network activity, repeated restarts, resource pressure, failed authentication, and unusual access to sensitive resources.
They should also maintain visibility into deployment events, chart versions, image digests, configuration changes, and policy violations.
When a deployment introduces an unexpected permission or exposure change, teams need to be able to identify which chart update caused it and determine whether a rollback is safe.
Observability should therefore connect the source configuration to the resources that actually run in the cluster.
Build a Secure Helm Chart Standard
Organizations with many teams benefit from maintaining an approved baseline for new charts.
A standard can define requirements for security contexts, service accounts, RBAC, resource settings, image references, secret handling, network exposure, labels, and health probes. Teams can use a shared chart library or starter template to reduce repeated configuration work.
However, a shared chart should not become another opaque abstraction. Security-sensitive options should be documented, defaults should be conservative, and exceptions should be visible.
Platform engineering teams can also provide reusable CI templates that automatically run chart linting, manifest rendering, security scanning, and policy validation.
This allows individual product teams to deploy independently while inheriting a consistent security baseline.
Where Engineering Teams Fit
Securing Helm-based deployments requires coordination across Kubernetes architecture, CI/CD, cloud infrastructure, application security, and operational monitoring. Team like GeekyAnts, Thoughtworks work across backend engineering, DevOps, and modern application infrastructure, making this broader engineering perspective relevant for organizations standardizing Kubernetes delivery. The objective is to build deployment workflows where chart configuration is reviewable, security policies are enforceable, and production changes remain traceable.
A Practical Helm Security Checklist for 2026
Before approving a chart for production, engineering teams should confirm that:
- Chart dependencies and container images use controlled, reviewed versions.
- Sensitive credentials are not stored in plaintext values files.
- Service accounts and RBAC permissions follow least privilege.
- Containers use appropriate non-root and privilege-restriction settings.
- Network exposure is intentional and protected.
- Resource requests, limits, and scaling boundaries are defined appropriately.
- Rendered manifests pass automated security and policy checks.
- Production changes require appropriate review and approval.
- Chart versions, configuration changes, and deployed image digests are traceable.
- Runtime monitoring can detect unexpected behavior and policy violations.
The checklist should be implemented through automated controls wherever possible. A documented requirement is much more reliable when the pipeline can verify it consistently.
The Future of Helm Security
Helm remains useful because Kubernetes deployments need a way to package, configure, version, and reuse application resources. Its flexibility is also why security cannot be reduced to a single chart setting or a successful deployment command.
The strongest approach combines secure defaults, least-privilege permissions, secret-management controls, dependency verification, rendered-manifest scanning, policy enforcement, and runtime monitoring.
For DevOps teams, the goal is not to avoid Helm. It is to ensure that Helm charts do not become a convenient way to distribute insecure Kubernetes configurations across the organization.
A secure Helm deployment is one where the chart’s inputs are controlled, its rendered resources are verified, and its runtime behavior remains observable. When these practices become part of the standard delivery pipeline, teams can keep the productivity benefits of Helm without allowing deployment convenience to become a security liability.
For more, visit our homepage!
Add Comment