Explain Helm security best practices: RBAC, pod security, and secrets management.

Helm security requires attention at multiple levels: chart content, deployment permissions, and runtime security.

RBAC for Helm v3 (no Tiller): Each Helm operation uses client credentials. Create service accounts with minimal permissions: apiVersion: v1 kind: ServiceAccount metadata: name: helm-deployer --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: helm-deployer rules: - apiGroups: [""apps""] resources: [""deployments""] verbs: [""get"", ""list"", ""create"", ""update"", ""patch"", ""delete""] - apiGroups: [""""] resources: [""services"", ""configmaps"", ""secrets""] verbs: [""get"", ""list"", ""create"", ""update"", ""delete""]

Pod Security Standards in charts: securityContext: runAsNonRoot: true runAsUser: 1001 capabilities: drop: [""ALL""] readOnlyRootFilesystem: true allowPrivilegeEscalation: false

Secrets management patterns:

• NEVER store secrets in values.yaml. Use external secrets managers: helm secrets plugin (sops), SealedSecrets, External Secrets Operator, or HashiCorp Vault via vault-helm
• Encrypted secrets with helm-secrets + sops: helm secrets upgrade myapp ./chart -f secrets.yaml
• Use Kubernetes native Secrets with RBAC restrictions

Chart security scanning: helm lint # Basic validation helm template . | kubesec scan # Kubernetes security checks checkov -d ./mychart # Infrastructure as code scanning trivy image --severity HIGH,CRITICAL myapp:latest

Additional best practices:

• Use --dry-run and --dry-run=server before actual deployment
• Implement admission control (OPA/Gatekeeper) to enforce helm policies
• Sign charts with provenance files: helm package --sign --key mykey
• Scan base images in CI/CD
• Regularly update Helm and Kubernetes versions
• Use network policies to limit pod communication