Helm Misconfiguration Detection

March 26, 2025 - 6 mins read

Securing Your Kubernetes Deployments: Understanding Helm Misconfigurations and the Power of Scanning

Helm has become the de-facto package manager for Kubernetes, simplifying the way we define, install, and upgrade even the most complex applications. With its templating engine and chart repositories like Artifact Hub, deploying applications is easier than ever. However, this convenience can sometimes lead to security oversights in the form of misconfigurations.

Recent research, such as the paper “Analyzing and Mitigating (with LLMs) the Security Misconfigurations of Helm Charts from Artifact Hub,” highlights the prevalence of these issues and explores innovative ways to address them. Let’s dive into what these misconfigurations are, how scanning tools can help, and the emerging role of Large Language Models (LLMs) in securing our Helm charts.

What Are Helm Chart Misconfigurations?

Helm charts are collections of files that describe a related set of Kubernetes resources. Misconfigurations in these charts are settings or parameters that deviate from security best practices, potentially exposing your applications and clusters to risks. These can range from overly permissive access rights to a lack of resource constraints, leading to vulnerabilities, instability, or inefficient resource usage.

The aforementioned study found that even popular charts on Artifact Hub can contain various misconfigurations. Common examples include:

Overly Permissive Security Contexts: Allowing containers to run with root privileges or enabling privilege escalation (allowPrivilegeEscalation: true).
Missing Resource Limits and Requests: Failing to define CPU or memory limits for containers can lead to resource starvation and denial-of-service scenarios.
Default or Wide Network Policies: Not restricting network traffic to and from pods, allowing unnecessary communication.
Use of Default Namespaces: Deploying applications into the default namespace can make it harder to manage RBAC and network policies effectively.
Hardcoded Secrets (though less common in templates, more in values files): Embedding sensitive information directly in charts.

Here’s an example of a common misconfiguration – a container allowed to escalate privileges:

# Part of a Deployment template (e.g., deployment.yaml)
# ...
spec:
  template:
    spec:
      containers:
      - name: my-app-container
        image: myapp:latest
        securityContext:
          allowPrivilegeEscalation: true # <-- Misconfiguration!
          readOnlyRootFilesystem: false
# ...

This seemingly small setting can have significant security implications if a process within the container is compromised.

The Crucial Role of Scanning Tools Manually auditing every line of your Helm charts and the resulting Kubernetes manifests is impractical and slow. So I looked for tools that are publicly available.

Tools like Checkov, KICS, Datree, Kubescape and Terrascan are designed to statically analyze your Infrastructure as Code (IaC) files, including Helm charts and Kubernetes YAML. They use predefined (and often customizable) policies based on security benchmarks (like CIS Benchmarks) and best practices to detect misconfigurations.

How Scanning Works (Simplified):

Input: You provide the Helm chart (or rendered Kubernetes YAML) to the scanning tool.

Parsing: The tool parses the files to understand the resources and their configurations.

Policy Check: It evaluates these configurations against its policy set.

Output: The tool reports any violations, often detailing the misconfigured resource, the violated policy, and sometimes suggesting remediation.

Example: Scanning a Misconfigured Chart Let’s take a snippet from a Helm template that omits CPU and memory limits for a container:

Code Sample (Misconfigured deployment.yaml snippet):

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-app
spec:
  replicas: {{ .Values.replicaCount | default 1 }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}-app
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}-app
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          # Missing resources requests and limits!

Simulated Output (from a tool like Checkov or KICS):

Scan Results:

FAILED for resource: Deployment/{{ .Release.Name }}-app
Rule: Ensure CPU limits are set for containers (CKV_K8S_11)
File: /templates/deployment.yaml:21
Description: CPU limits should be set to prevent resource exhaustion.
   20 |          ports:
   21 |            - name: http
   22 |              containerPort: 80
   23 |              protocol: TCP
   24 |          # Missing resources requests and limits!


FAILED for resource: Deployment/{{ .Release.Name }}-app
Rule: Ensure memory limits are set for containers (CKV_K8S_12)
File: /templates/deployment.yaml:21
Description: Memory limits should be set to prevent resource exhaustion and OOM kills.
   20 |          ports:
   21 |            - name: http
   22 |              containerPort: 80
   23 |              protocol: TCP
   24 |          # Missing resources requests and limits!

Summary:
Passed checks: 5
Failed checks: 2
Skipped checks: 0

This output clearly indicates the missing resource limits, helping developers pinpoint and fix the issue.

Leveraging LLMs for Mitigation: A New Frontier The research paper “Analyzing and Mitigating (with LLMs) the Security Misconfigurations of Helm Charts from Artifact Hub” explores an interesting approach: using Large Language Models (LLMs) like ChatGPT or Google Gemini to not just identify but also help fix these misconfigurations.

The proposed pipeline is:

Scan: Analyze the Helm chart using existing tools (e.g., Checkov) to identify misconfigurations.

LLM Query: For each misconfiguration, query an LLM with the context (the K8s resource YAML and the violated policy).

Refactor: The LLM suggests a refactored YAML snippet to address the misconfiguration.

Validate: The refactored chart is then re-scanned by the tools to see if the issue is resolved. A manual review is also crucial due to the potential for LLM “hallucinations” or incorrect fixes.

Example: LLM-Assisted Refactoring Let’s use our previous example of missing resource limits.

Code Sample (Misconfigured deployment.yaml snippet - as before):

# templates/deployment.yaml
# ... (spec.template.spec.containers)
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          # Missing resources requests and limits!

LLM Query (Conceptual): “Refactor the following Kubernetes Deployment container definition to include CPU and memory requests and limits, ensuring it addresses the policy ‘Ensure CPU limits are set for containers’ and ‘Ensure memory limits are set for containers’. Output only the refactored YAML for the container section. [YAML snippet above]”

Code Sample (LLM-Refactored deployment.yaml snippet):

# templates/deployment.yaml (LLM suggested change)
# ... (spec.template.spec.containers)
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          resources:
            limits:
              cpu: "500m"
              memory: "512Mi"
            requests:
              cpu: "250m"
              memory: "256Mi"

Simulated Output (after applying LLM fix and re-scanning):

Scan Results:

Summary:
Passed checks: 7
Failed checks: 0
Skipped checks: 0

All checks passed!

While promising, the study also notes the importance of validating LLM outputs, as they can sometimes produce incorrect or incomplete fixes. However, as LLMs evolve, their utility in automating security remediation could be significant.

Best Practices for Secure Helm Chart Management

Beyond scanning and potential LLM assistance, here are some fundamental best practices:

Regular Scanning: Integrate automated scanning into your CI/CD pipelines.
Least Privilege: Configure RBAC and security contexts with the minimum necessary permissions.
Resource Management: Always define resource requests and limits.
Network Policies: Implement restrictive network policies to control traffic flow.
Keep Dependencies Updated: Regularly update Helm chart dependencies and base images.
Use Trusted Sources: Prefer charts from well-maintained and trusted repositories.
Values File Hygiene: Be cautious with parameters exposed in values.yaml and ensure secure defaults.
Manual Review for Critical Charts: For highly sensitive applications, supplement automated scanning with manual reviews.

Conclusion

Too many tools, not enough unification under the hood. But Kubescape is slowly demonstrating the ability to bring scans and policies under one roof.

In my next post, I will try to write some python with some LLM assistance in improving misconfigured helm charts that deploys basic applications.

Other tools not talked about:

https://validkube.com/