What are Helm Charts?
A Helm Chart is a package format for Kubernetes that bundles all the resource definitions an application needs into a single, versioned unit. Think of it as a blueprint: instead of writing and maintaining separate YAML manifests for deployments, services, config maps, and secrets, you define them once in a chart and deploy them together.
Every chart follows a standard structure. The Chart.yaml file holds metadata like the chart name, version, and description. The values.yaml file defines configurable parameters that users can override at install time. The templates/ directory contains the actual Kubernetes manifest templates, which Helm renders using the values you provide.
This structure makes Helm the most widely adopted package manager for Kubernetes. Teams use it to standardize deployments, share reusable application packages through repositories like Artifact Hub, and roll back to previous versions when something breaks.
While Helm Charts simplify deployments, they also introduce security considerations that many teams overlook. A single misconfigured chart can propagate vulnerabilities, exposed secrets, and overly permissive access controls across an entire cluster.
Kubernetes Security Cheat Sheet
Keep your Helm deployments and broader container environment locked down with actionable security guidance.
Why use Helm Charts?
Organizations adopt Helm Charts to solve specific Kubernetes deployment challenges:
Simplifying complex applications: Helm Charts package all essential Kubernetes components into a single bundle, replacing the need to manage multiple YAML files individually.
Use a templates directory: Enforcing a consistent chart structure across your team gives you greater control over the environment and makes it easier to audit configurations for security issues.
Streamlining version control and rollbacks: Charts enable you to track modifications and revert to earlier versions when necessary, which is crucial for maintaining stability in your Kubernetes environment.
Sharing and reusing applications: Chart repositories let teams share and reuse Kubernetes applications. When everyone works from the same repositories, collaboration and standardization follow naturally.
Integrating with CI/CD pipelines: Helm integrates seamlessly with CI/CD workflows, automating application deployment and ensuring consistent updates across environments.
Improving collaboration across teams: Helm Charts give development and operations teams a shared framework for deploying and managing applications, reducing handoff friction and deployment errors.
Saving time with pre-built charts: The Helm community offers a vast array of pre-built charts for well-known Kubernetes applications. Use these chart packages to save time and effort in application deployment.
Security risks of Helm Charts
The risks below are not theoretical. They compound across the chart lifecycle, from the values file to the registry to runtime.
1. Insecure configurations
Charts that contain misconfigurations might expose applications to vulnerabilities. Incorrect resource allocations, insecure network policies, or weak security settings can be exploited by attackers to gain unauthorized access or disrupt services. These are among the most common Kubernetes security issues organizations face today. The blast radius can extend across the entire Kubernetes cluster, potentially allowing attackers to move laterally and exploit other services.
2. Default values exposing sensitive information
Default values in charts can inadvertently expose sensitive information such as passwords and API keys. Audit and lock down default values in values.yaml before every deployment. Encrypting sensitive fields prevents unintentional exposure.
3. Dependency vulnerabilities
Charts often include dependencies that may have their own vulnerabilities. These can range from other charts to container images and external libraries. Keeping chart dependencies current reduces your attack surface and gives your team a clear, auditable baseline for what runs in each cluster.
4. Insufficient access controls
Improperly configured access controls can lead to unauthorized access and potential privilege escalation within the Kubernetes cluster. Over-permissive roles and permissions provide unnecessary access to sensitive resources. Improper access controls can even result in privilege escalation, compromising the security of the entire Kubernetes cluster.
5. Risk of altered or malicious charts
Deploying charts from untrusted sources can introduce malicious code into your Kubernetes environment. Malicious charts can compromise application integrity, steal data, or create backdoors for future attacks. According to the Wiz Kubernetes Security Report, malicious probing begins as soon as 18 minutes after a new cluster is staged. The blast radius can include the entire application and potentially other applications running in the same environment. Always verify the source project and maintain trusted chart repositories.
6. Lack of automated scanning
Without automated scanning, vulnerabilities in charts might go unnoticed and then get exploited, leading to significant security breaches. The same research found that exposed pods with critical vulnerabilities dropped 50% year-over-year in organizations that adopted automated scanning, showing the impact of proactive detection. Implementing automated Kubernetes security tools helps you identify and address security issues promptly.
Watch 12-min demo
See how Wiz secures containers and Kubernetes across the full deployment lifecycle.
Best practices for secure Helm usage
Securing Helm deployments requires controls at multiple layers: where you source your charts, how you configure them, who can deploy them, and what you monitor after deployment. These align with broader Kubernetes security best practices that apply across your entire cluster.
Use trusted sources
Chart provenance is your first line of defense. Verify where a chart comes from before deploying it to any cluster.
Verify chart provenance: Check signatures and source repositories before deploying to any cluster.
Patch regularly: Update charts to address known vulnerabilities as new versions are released.
Use signed charts: Signatures verify that a chart has not been tampered with since publication.
Here is some sample code that can help you put these best practices into action:
# Adding a trusted Helm repository
helm repo add stable https://charts.helm.sh/stable
# Verifying a signed chart
helm verify stable/my-chart
# Installing the verified chart
helm install my-release stable/my-chart
Harden Helm Chart values
Default chart values are a common source of credential leaks. Hardening those defaults closes one of the easiest attack vectors.
Lock down defaults: Review values.yaml for hardcoded credentials, overly permissive settings, or exposed API keys.
Use environment-specific configs: Separate staging and production values to prevent accidental exposure.
Encrypt secrets: Use tools like Sealed Secrets to keep sensitive values out of plain text.
The following code example demonstrates a values.yaml file with encrypted sensitive data, and the second part demonstrates using Sealed Secrets to store and manage sensitive information securely:
# values.yaml with secure configurations
database:
username: myUser
password:
- encrypted: AgA0I5eA==
host: mydb.example.com
port: 5432
# Using Sealed Secrets
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
name: mysecret
spec:
encryptedData:
password: AgA0I5eA==
Implement RBAC policies
Strong RBAC policies determine who can deploy, upgrade, and delete Helm releases in your clusters. They are your primary defense against privilege escalation.
Scope Helm permissions: Define roles and permissions specifically for Helm operations.
Restrict API access: Limit which users and service accounts can reach the Kubernetes API.
Isolate with namespaces: Use Kubernetes namespaces to limit the blast radius of potential security incidents.
The first YAML code sample defines an RBAC role with specific permissions for Helm operations, and the second code snippet binds this role to a user in the specified namespace:
# Example RBAC policy for Helm
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: helm-namespace
name: helm-role
rules:
- apiGroups: [""]
resources: ["pods", services, "deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
# Binding the role to a user
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: helm-rolebinding
namespace: helm-namespace
subjects:
- kind: User
name: helm-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: helm-role
apiGroup: rbac.authorization.k8s.io
Monitor and log Helm activity
Visibility into Helm operations lets you catch unauthorized deployments and respond before a misconfiguration becomes an incident.
Enable audit logging: Track every Helm command to maintain a clear record of changes and access.
Centralize your logs: Route Helm audit logs to your SIEM or logging platform so you can connect deployment events with runtime anomalies.
Set up alerts: Trigger notifications for suspicious activities like unexpected chart installs or privilege changes.
The first YAML code sample sets up an audit policy to log metadata for specific Kubernetes resources, while the second code snippet configures Fluentd to collect system logs from the specified path:
# Enabling audit logging in Kubernetes
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
resources:
- group: ""
resources: ["pods", "services", "deployments"]
users: ["helm-user"]
# Setting up centralized logging with Fluentd
apiVersion: v1
kind: ConfigMap
metadata:
name: fluentd-config
namespace: logging
data:
fluent.conf: |
<source>
@type systemd
@id input_systemd
tag host.*.syslog
path /var/log/journal
</source>
How Wiz secures Helm Chart deployments
Helm does not include built-in security controls. Teams that rely on charts need external tooling to scan for vulnerabilities, enforce deployment policies, and monitor runtime behavior across their clusters.
Wiz addresses each of these gaps across the full Helm deployment lifecycle. Kubernetes Security Posture Management (KSPM) continuously monitors cluster configurations deployed via Helm against CIS benchmarks, flagging misconfigurations and RBAC sprawl before they become exploitable. For example, 81% of EKS clusters still use the outdated CONFIG_MAP authentication mode, a risk that KSPM surfaces automatically. The Wiz Admission Controller acts as a policy gate at deployment time, blocking charts that attempt to pull from untrusted registries, run pods with root privileges, or deploy without resource limits.
For workloads already running in your clusters, agentless scanning identifies vulnerabilities, exposed secrets, and malware across Helm-deployed container images without requiring any in-cluster agents. The Wiz Runtime Sensor adds a layer of real-time detection on top of that agentless foundation. Built on lightweight eBPF technology, it monitors process execution and network behavior inside containers, while Vulnerability Runtime Validation (VIR) shows which vulnerable packages are actually loaded in memory. Teams using VIR typically reduce their vulnerability backlog by up to 90%, focusing remediation on risks that are actively executing rather than theoretically present.
Wiz also connects Helm deployment risks to the broader cloud and AI security picture. The Security Graph correlates container vulnerabilities and Kubernetes misconfigurations with cloud identity exposure, network paths, and AI workloads running in the same environment. If a Helm-deployed container is running an AI framework like LangGraph or PydanticAI, Wiz flags it and monitors for Rogue Agent behavior, where autonomous agents attempt unauthorized actions like credential harvesting or lateral movement.
This end-to-end approach means teams see the actual blast radius of a risky Helm deployment, not just isolated CVEs or policy violations. Get a demo to see how Wiz connects the dots across your Kubernetes environment.
Get a demo
Ready to secure your Helm Chart deployments from code to cloud?
