fix: add missing resources, securityContext and env entries

[fernandezcuesta]

Description

This is a complement of #12691 which addressed some Helm chart refactoring, but failed to allow securityContext as well as mounted volumes and resources for all containers and initContainers.

For example, when PSS policies are enforced, we may need to specify readOnlyRootFilesystem: false and mount tmpfs volues in all (init)containers. This PR closes the gaps left from #12691.

Test results

Tested in a production instance from a fork.

Documentation
n/a

[dryrunsecurity]

This pull request introduces an insecure Helm chart change that writes untrusted .Values.localsettingspy directly into a ConfigMap mounted as /app/dojo/settings/local_settings.py for django, celery-beat, and celery-worker containers, allowing an attacker with Helm value injection permissions to execute arbitrary Python code on startup (RCE). The finding recommends removing direct injection of raw Python into a mounted settings file or otherwise validating/escaping values and using safer configuration patterns.

Arbitrary Content Injection (RCE) in helm/defectdojo/templates/configmap-local-settings-py.yaml

Vulnerability

Arbitrary Content Injection (RCE)

Description

The Helm chart allows arbitrary content from .Values.localsettingspy to be directly injected into a ConfigMap named {{ $fullName }}-localsettingspy. This ConfigMap is then mounted as /app/dojo/settings/local_settings.py in the celery-beat, celery-worker, and django application containers. In Django applications, local_settings.py is typically imported and executed as Python code during application startup. An attacker with permissions to set Helm values can inject malicious Python code into .Values.localsettingspy, which will be executed by the application, leading to Remote Code Execution (RCE).

django-DefectDojo/helm/defectdojo/templates/configmap-local-settings-py.yaml

Line 24 in 73aa3c4

{{ toYaml .Values.localsettingspy | indent 4 }}

---

All finding details can be found in the DryRun Security Dashboard.

[fernandezcuesta]

@kiblik I came across some missing gaps from my last chart PR, should be quite straightforward and I hope I didn't miss anything this time

[kiblik]

Couple of comments

[kiblik]

Now I'm thinking, there are Pod SecurityContext and Container SecurityContext. Some parts overlap (e.g., runAsNonRoot), but some are exclusive (e.g,. allowPrivilegeEscalation or fsGroup)

$ curl https://raw.githubusercontent.com/yannh/kubernetes-json-schema/refs/heads/master/master/securitycontext.json | jq '.properties | keys '
 [
  "allowPrivilegeEscalation",
  "appArmorProfile",
  "capabilities",
  "privileged",
  "procMount",
  "readOnlyRootFilesystem",
  "runAsGroup",
  "runAsNonRoot",
  "runAsUser",
  "seLinuxOptions",
  "seccompProfile",
  "windowsOptions"
]
$ curl https://raw.githubusercontent.com/yannh/kubernetes-json-schema/refs/heads/master/master/podsecuritycontext.json | jq '.properties | keys '
[
  "appArmorProfile",
  "fsGroup",
  "fsGroupChangePolicy",
  "runAsGroup",
  "runAsNonRoot",
  "runAsUser",
  "seLinuxChangePolicy",
  "seLinuxOptions",
  "seccompProfile",
  "supplementalGroups",
  "supplementalGroupsPolicy",
  "sysctls",
  "windowsOptions"
]

It would be good idea to separate them. I'm not sure how it is usually done in other projects.

[fernandezcuesta]

okay, did some (not small) changes to split pod <> container security Contexts and some other changes (annotations -> extraAnnotations to align with labels, add them everywhere).

I'll need more time to see where I added a regression in the tests

Also, release notes are pending but that will come later 🙏

[kiblik]

@fernandezcuesta, can you please rebase from dev branch? Tests should stop failing.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[kiblik]

Just one change ({} vs. nil).

[mtesauro]

Approved