helm: helm chart enhancements

[mikesindieiev]

Description

1. Helm chart follows the same variable name style across the values.yaml file
2. Setting UWSGI enableDebug to true will automatically set DD_DEBUG environment variable to 'True'
3. Standard mysql configuration is added. Bitnami uses old collation settings by default.

Existing DefectDojo database will continue to use old collation

[dryrunsecurity]

DryRun Security Summary

The provided code changes focus on improving the deployment and configuration of the DefectDojo application, an open-source application security platform, by addressing various aspects of the Kubernetes deployment, including the Helm chart, Celery worker settings, Django application settings, debug mode, and network policies, to enhance the security and reliability of the deployment.

Expand for full summary

Summary:

The provided code changes are focused on improving the deployment and configuration of the DefectDojo application, which is an open-source application security platform. The changes cover various aspects of the Kubernetes deployment, including the Helm chart, Celery worker settings, Django application settings, debug mode, and network policies.

From an application security perspective, the changes appear to be generally positive, as they aim to enhance the security and reliability of the deployment. Key security-related updates include:

1. Debug Mode: The changes ensure that the debug mode is properly managed, with the ability to enable or disable it in the configuration. Disabling debug mode in production environments is a recommended security practice.
2. Secrets Management: The use of Kubernetes Secrets to store sensitive information, such as database and Redis passwords, is a good security practice.
3. Secure Cookies: The changes include setting the DD_SESSION_COOKIE_SECURE and DD_CSRF_COOKIE_SECURE environment variables, which help prevent session hijacking and CSRF attacks by ensuring that session and CSRF cookies are only transmitted over HTTPS.
4. Network Policies: The inclusion of an option to enable network policies can help restrict the network traffic to and from the application, improving the overall security posture.
5. Monitoring Configuration: The ability to enable or disable monitoring of Django and Nginx metrics can be useful for identifying and addressing potential security issues or performance bottlenecks.

Overall, the code changes in this pull request appear to be focused on improving the security, reliability, and maintainability of the DefectDojo application's Kubernetes deployment. As an application security engineer, I would recommend thoroughly reviewing and testing these changes to ensure they align with the specific security requirements and constraints of the deployment environment.

Files Changed:

1. docs/content/en/getting_started/upgrading/2.38.md: The changes update the HELM deployment configuration to follow official HELM best practices for key naming conventions, which improves the consistency and maintainability of the deployment.
2. helm/defectdojo/templates/_helpers.tpl: The changes update the configuration for enabling debug mode in the Django application, which is an important security consideration.
3. helm/defectdojo/templates/django-deployment.yaml: The changes include updates to the Kubernetes deployment configuration, such as the use of Kubernetes Secrets, secure cookie settings, and security context, which are all positive security practices.
4. helm/defectdojo/templates/configmap.yaml: The changes update the configuration parameters for the DefectDojo application, including Celery worker settings, database configuration, and uWSGI settings, which can impact the overall security and reliability of the application.
5. helm/defectdojo/values.yaml: The changes provide various configuration options for the Celery workers, Django application, debug mode, and network policies, which can have a direct impact on the application's security and performance.
6. readme-docs/KUBERNETES.md: The changes update the Kubernetes deployment documentation, including information about supported versions, Helm chart updates, and production considerations, which can help users deploy the application securely.

Code Analysis

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

Riskiness

🟢 Risk threshold not exceeded.

View PR in the DryRun Dashboard.

[kiblik]

Hi @mikesindieiev,

couple of questions?

1. Helm chart follows the same variable name style across the values.yaml file

• Is using camelCase instead of snake_case part of the official best practice? If so, can you link the source, please?
• If somebody is already using site_url or app_settings, this change will produce a breaking change. Can you describe it in related docs:

  django-DefectDojo/docs/content/en/getting_started/upgrading/2.37.md

  Lines 1 to 7 in 3afee7a

  	---
  	title: 'Upgrading to DefectDojo Version 2.37.x'
  	toc_hide: true
  	weight: -20240701
  	description: No special instructions.
  	---
  	There are no special instructions for upgrading to 2.37.x. Check the [Release Notes](https://github.com/DefectDojo/django-DefectDojo/releases/tag/2.37.0) for the contents of the release.

3. Standard mysql configuration is added. Bitnami uses old collation settings by default.

MySQL setup will be discontinued soon (see #9690). Not sure that this kind of change makes sense.

[mikesindieiev]

Hello @kiblik,

camelCase is the naming best practice for the helm values.yaml file - https://helm.sh/docs/chart_best_practices/values/#naming-conventions

Thank you for the link to the breaking change docs, I am going to add a note about the changes there

I would keep changes for mysql in case of fresh dd-mysql installations and since the mysql is there and is still supported

[mtesauro]

@mikesindieiev

I would keep changes for mysql in case of fresh dd-mysql installations and since the mysql is there and is still supported

Actually, MySQL support was deprecated in 2.36.0 and will be fully removed in 2.37.0 (August). We needed time to update the GH Actions/tests that used MySQL. Any changes you make to my SQL will just be deleted. If you want to make changes for MySQL, I'd be fine with you removing MySQL but there's really no reason to improve something that's already deprecated and about to be removed.

Details on the deprecation of MySQL (and others) are at #9690

[mikesindieiev]

Ah, I see. Agree. I removed mysql config from the values.yaml file

[cneill]

Not sure why the tests failed, will re-run. Also noticed one more naming update

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[mtesauro]

Approved

[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.

[mtesauro]

@mikesindieiev Looks like you're going to have to rebase this PR - the GH Action failure is a problem with debugpy which was fixed in a PR more recent than the one this one is based on.

Other than the failing tests, you have the needed approvals for this to be merged so congrats on that.

[mtesauro]

@mikesindieiev Thanks for the commits - merging this now 👍