feat(helm): Allow to keep initializer if requested

[kiblik]

If the user needed to keep the initializer in the stack, there was no way (only set an unreasonable large number).

Now, any value that is not a positive integer will keep the initializer there.

Tested with:

• --set 'initializer.keepSeconds=[]' - stayed
• --set 'initializer.keepSeconds=null' - stayed
• --set 'initializer.keepSeconds=x' - stayed
• --set 'initializer.keepSeconds=-1' - stayed
• --set 'initializer.keepSeconds=0' - stayed
• --set 'initializer.keepSeconds=1' - removed after 1s

Context: https://owasp.slack.com/archives/C2P5BA8MN/p1731520213600479?thread_ts=1724681809.122489&cid=C2P5BA8MN

[dryrunsecurity]

DryRun Security Summary

The pull request updates the Helm chart for the DefectDojo vulnerability management tool, focusing on changes to the initialization job, which include security enhancements such as setting a time-to-live for finished jobs, allowing the specification of additional volumes for custom configuration or sensitive data, and securely connecting to the database using the Cloud SQL Proxy.

Expand for full summary

Summary:

The code changes in this pull request are focused on updates to the Helm chart used to deploy the DefectDojo application, a popular open-source vulnerability management tool. The changes primarily involve modifications to the initialization job, which is responsible for performing initial setup or configuration tasks for the application.

From an application security perspective, the changes do not directly introduce any obvious security vulnerabilities. However, it's important to ensure that the initialization job and its associated resources are properly secured and configured to mitigate potential security risks. This includes verifying the security context of the job and pod, reviewing the initialization scripts for any security issues, and monitoring the job's execution and logs for suspicious activities.

Additionally, the changes introduce features that can improve the overall security of the deployment, such as setting a time-to-live (TTL) for finished jobs, allowing the specification of additional volumes for custom configuration or sensitive data, and securely connecting to the database using the Cloud SQL Proxy. These are all positive security enhancements that should be reviewed and validated to ensure they are properly implemented and configured.

Files Changed:

1. helm/defectdojo/values.yaml:

   • The changes update the keepSeconds value in the initializer section, which controls the duration for which the initializer job and pod will be kept deployed after they have completed their tasks. This is a deployment-related setting that does not have a direct impact on the application's security posture, but it's important to ensure that the job and pod are properly secured.

2. helm/defectdojo/templates/initializer-job.yaml:

   • The changes introduce a conditional check to set the ttlSecondsAfterFinished field for the initialization job, which can help to automatically clean up finished jobs, a good security practice.
   • The code allows for the specification of additional volumes that can be mounted into the initialization job's containers, which can be useful for providing custom configuration files or sensitive data, but it's important to ensure that these volumes are properly secured.
   • The initialization job includes a container that waits for the database to be available before running the initialization script, and if the application is configured to use Google Cloud SQL, it includes a container that runs the Cloud SQL Proxy to securely connect to the database.
   • The initialization job uses environment variables to configure the application, including the database connection details, which should be properly secured to prevent sensitive information exposure.

Code Analysis

We ran 9 analyzers against 2 files and 0 analyzers had findings. 9 analyzers had no findings.

Riskiness

🟢 Risk threshold not exceeded.

View PR in the DryRun Dashboard.

[mtesauro]

Approved

[Maffooch]

@kiblik I am not very familiar with helm, but what would be the use case of keeping the init container around longer?

[kiblik]

@kiblik I am not very familiar with helm, but what would be the use case of keeping the init container around longer?

It is not connected to HELM itself. Quite often I see cases when migration was not executed during the upgrade or it fails for some reason. Keeping a container (hopefully with logs) should help with debugging - in case logs are needed as evidence. Yes, log collection to some other place is highly recommended in best practice but I suppose this is easier for users who miss this kind of solution. As far as I know, finished jobs do not consume additional resources (CPU, memory).

Plus, right now user is forced to accept the setting (that the job will be removed). Yes, values can be adjusted to much higher but it is not possible to avoid removal (unless you set it to unreasonable value).

This PR does not change the previous default behavior.

[Maffooch]

Ahh that makes perfect sense