# Securing Helm Chart Deployments > Use when secure Helm chart deployments by validating chart integrity, scanning templates for misconfigurations, and enforcing security contexts in Kubernetes releases. Use when working with securing helm chart deployments. - Skill: `oyi77/securing-helm-chart-deployments` (Agent Skill) - Install (CLI): `npx skillmds add oyi77/securing-helm-chart-deployments` - Raw SKILL.md: https://api.skillmd.com/api/skills/oyi77/securing-helm-chart-deployments/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - License: Apache-2.0 - Author: oyi77 (https://skillmd.com/u/oyi77) - Updated: 2026-09-08 - Page: https://skillmd.com/skills/oyi77/securing-helm-chart-deployments --- # Securing Helm Chart Deployments ## Overview Helm is the Kubernetes package manager. Securing Helm deployments requires validating chart provenance, scanning templates for security misconfigurations, enforcing pod security contexts, managing secrets securely, and controlling RBAC for Helm operations. ## When to Use **Trigger phrases:** - "securing helm chart deployments" - "Secure Helm chart deployments by validating chart integrity, scanning templates " - When deploying or configuring securing helm chart deployments capabilities in your environment - When establishing security controls aligned to compliance requirements - When building or improving security architecture for this domain - When conducting security assessments that require this implementation ## Prerequisites - Helm 3.12+ installed - kubectl with cluster access - GnuPG for chart signing/verification - kubesec or checkov for template scanning ## Chart Provenance and Integrity This section covers chart provenance and integrity for securing helm chart deployments. - Ensure all prerequisites are met before proceeding - Follow the documented workflow steps in sequence - Record results and any anomalies encountered during this phase ### Sign a Helm Chart ```bash # Generate GPG key for signing gpg --full-generate-key # Package and sign chart helm package ./mychart --sign --key "helm-signing@example.com" --keyring ~/.gnupg/pubring.gpg # Verify chart signature helm verify mychart-0.1.0.tgz --keyring ~/.gnupg/pubring.gpg ``` ### Verify Chart Before Install ```bash # Verify chart from repository helm pull myrepo/mychart --verify --keyring /path/to/keyring.gpg # Check chart provenance file cat mychart-0.1.0.tgz.prov ``` ## Template Security Scanning This section covers template security scanning for securing helm chart deployments. - Ensure all prerequisites are met before proceeding - Follow the documented workflow steps in sequence - Record results and any anomalies encountered during this phase ### Render and Scan Templates ```bash # Render templates without deploying helm template myrelease ./mychart --values values-prod.yaml > rendered.yaml # Scan with kubesec kubesec scan rendered.yaml # Scan with checkov checkov -f rendered.yaml --framework kubernetes # Scan with trivy trivy config rendered.yaml # Scan with kube-linter kube-linter lint rendered.yaml ``` ### Helm Lint for Misconfigurations ```bash # Lint chart helm lint ./mychart --values values-prod.yaml --strict # Lint with debug output helm lint ./mychart --debug ``` ## Security Context Enforcement in values.yaml ```yaml # values.yaml - Security hardened defaults securityContext: runAsNonRoot: true runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 readOnlyRootFilesystem: true allowPrivilegeEscalation: false capabilities: drop: - ALL podSecurityContext: seccompProfile: type: RuntimeDefault resources: limits: cpu: 500m memory: 512Mi requests: cpu: 100m memory: 128Mi networkPolicy: enabled: true serviceAccount: create: true automountServiceAccountToken: false image: pullPolicy: Always # Use digest instead of tag for immutability # tag: "1.0.0" # digest: "sha256:abc123..." ``` ### Template with Security Contexts ```yaml # templates/deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: {{ include "mychart.fullname" . }} spec: template: spec: automountServiceAccountToken: {{ .Values.serviceAccount.automountServiceAccountToken }} securityContext: {{- toYaml .Values.podSecurityContext | nindent 8 }} containers: - name: {{ .Chart.Name }} securityContext: {{- toYaml .Values.securityContext | nindent 12 }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" resources: {{- toYaml .Values.resources | nindent 12 }} ``` ## Secrets Management This section covers secrets management for securing helm chart deployments. - Ensure all prerequisites are met before proceeding - Follow the documented workflow steps in sequence - Record results and any anomalies encountered during this phase ### Use External Secrets (Not Helm Values) ```yaml # templates/external-secret.yaml apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: {{ include "mychart.fullname" . }}-secrets spec: refreshInterval: 1h secretStoreRef: name: aws-secretsmanager kind: ClusterSecretStore target: name: {{ include "mychart.fullname" . }}-secrets data: - secretKey: db-password remoteRef: key: production/database property: password ``` ### helm-secrets Plugin ```bash # Install helm-secrets plugin helm plugin install https://github.com/jkroepke/helm-secrets # Encrypt values file helm secrets encrypt values-secrets.yaml # Deploy with encrypted secrets helm secrets install myrelease ./mychart -f values.yaml -f values-secrets.yaml # Decrypt for editing helm secrets edit values-secrets.yaml ``` ## RBAC for Helm Operations ```yaml # helm-deployer-role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: helm-deployer namespace: production rules: - apiGroups: ["", "apps", "batch", "networking.k8s.io"] resources: ["deployments", "services", "configmaps", "secrets", "ingresses", "jobs"] verbs: ["get", "list", "create", "update", "patch", "delete"] - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: helm-deployer-binding namespace: production subjects: - kind: ServiceAccount name: helm-deployer namespace: production roleRef: kind: Role name: helm-deployer apiGroup: rbac.authorization.k8s.io ``` ## CI/CD Helm Security Pipeline ```yaml # .github/workflows/helm-security.yaml name: Helm Chart Security on: pull_request: paths: ['charts/**'] jobs: lint-and-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Helm lint run: helm lint ./charts/mychart --strict - name: Render templates run: helm template test ./charts/mychart -f charts/mychart/values.yaml > rendered.yaml - name: Scan with kube-linter uses: stackrox/kube-linter-action@v1 with: directory: rendered.yaml - name: Scan with trivy uses: aquasecurity/trivy-action@master with: scan-type: config scan-ref: rendered.yaml - name: Scan with checkov uses: bridgecrewio/checkov-action@master with: file: rendered.yaml framework: kubernetes ``` ## Best Practices 1. **Sign charts** with GPG and verify before installation 2. **Render and scan** templates before deploying to catch misconfigurations 3. **Enforce security contexts** in values.yaml defaults 4. **Never store secrets** in Helm values - use external secrets or helm-secrets plugin 5. **Use image digests** instead of tags for immutable references 6. **Restrict Helm RBAC** to least privilege per namespace 7. **Pin chart versions** in requirements - never use `latest` 8. **Lint strictly** in CI with `--strict` flag 9. **Review third-party charts** before deploying to production 10. **Use Helm test hooks** to validate deployments post-install ## When NOT to Use - You need to test security controls (use performing-* skills) - Task is about detecting bypasses (use detecting-* skills) - You need to analyze security events (use analyzing-* skills) - Task is about building security tools (use building-* skills) - You don't have admin access to the system - Task requires compliance certification (use auditing-* skills) ## Red Flags - Performing actions without explicit written authorization from the asset owner - Testing against production systems without a defined scope and rules of engagement - Sharing sensitive findings or credentials in unencrypted communications - Failing to properly scope and contain the assessment before starting ## Verification - All steps executed successfully against a test environment before production use - Output documented with screenshots or logs demonstrating expected behavior - Results validated against known-good baselines or reference implementations - Documentation complete enough for another analyst to reproduce findings ## Process 1. Analyze the task requirements 2. Apply domain expertise 3. Verify output quality ## Anti-Rationalization Table | Rationalization | Reality | |---|---| | "We are too small to be targeted" | Automated attacks target everyone. Size does not matter. | | "Security slows us down" | A breach slows you down 100x more. Build security in from the start. | | "We will fix it after launch" | Vulnerabilities in production are exploited within hours. Fix before deploy. |