Chart's rendered output shows containers without security context defaults (root, no seccomp, SA tokens mounted)

[jkondrat]

Running a scan against this chart's test and golden output (which reflects the templates' actual rendered defaults) turns up a consistent pattern across the 8.5 through 8.10 chart versions:

Issue	Example	Why it matters
Default namespace assumed	charts/camunda-platform-8.5/test/unit/console/golden/deployment.golden.yaml:3	No namespace isolation for anyone installing with defaults
Images not pinned by digest	same	Tag mutability risk
Service account tokens auto-mounted	same	Unnecessary API access surface for components that don't need it
High-entropy strings in the Vault external-secrets integration test	charts/camunda-platform-8.10/test/integration/external-secrets/external-secret-integration-test-credentials-vault.yaml:17	Worth checking these are test placeholders and not something that should be templated or redacted

Since these are the chart's own rendered defaults and not just test-only content, anyone installing with helm install and no overrides inherits the same gaps.

Found this with InfraScan (https://github.com/SolDevelo/InfraScan), an open-source cost/security scanner covering Terraform, Kubernetes, Helm, CloudFormation, Ansible, and containers (Apache-2.0). If it's useful, it's a few lines to add as a GitHub Action (https://github.com/marketplace/actions/infrascan-iac-cost-security-scanner). Happy to open a PR wiring it up if you want.

[distro-ci]

🧭 Triage Assessment

Field	Value
Work type	BUG
Kind	bug
Severity	🔴 High
Likelihood	🔥 High
Confidence	0.86

📝 Rationale

Within scope: Camunda triage guidance assigns Helm charts and Self-Managed Helm configuration issues to the Distribution team. This is a BUG because it reports incorrect security-related behavior in the chart's rendered defaults, not maintenance work or a new capability. The impact is high because default installations may run workloads without non-root enforcement or RuntimeDefault seccomp, while automatically mounting service-account tokens increases unnecessary API-access exposure. Likelihood is high because the reported behavior is deterministic on the default rendering path and spans chart versions 8.5 through 8.10. The image-digest and namespace findings are defense-in-depth concerns and should be validated separately rather than treated as equivalent to the security-context findings. The closest overlap is #5150, which specifically requested pod-level automountServiceAccountToken support and documented the precedence issue between pod and ServiceAccount settings. #6848 is a related but distinct security-context regression involving partial overrides, and it was also triaged as a high-severity bug with mid likelihood. No exact duplicate was identified; #5150 covers token-mount configurability, while this issue additionally reports missing security-context defaults, mutable image references, namespace assumptions, and suspicious test credentials.

🔍 Similar Issues

#5150, #6848

---

🤖 This issue was automatically triaged by an AI-based system.
✋ If you believe this assessment is incorrect, update the labels or add the triage:manual label for human review.