chore(helm): implement readinessProbe and startupProbe for uwsgi container

[fcecagno]

Description

This PR makes it configurable all probes on the uwsgi container, including the startupProbe, which could be useful to speed-up Django launch on Kubernetes.

[dryrunsecurity[bot]]

Hi there :wave:, @dryrunsecurity here, below is a summary of our analysis and findings.

DryRun Security	Status	Findings
Server-Side Request Forgery Analyzer	:white_check_mark:	0 findings
Configured Codepaths Analyzer	:white_check_mark:	0 findings
IDOR Analyzer	:white_check_mark:	0 findings
Sensitive Files Analyzer	:white_check_mark:	0 findings
SQL Injection Analyzer	:white_check_mark:	0 findings
Authn/Authz Analyzer	:white_check_mark:	0 findings
Secrets Analyzer	:white_check_mark:	0 findings

[!Note] :green_circle: Risk threshold not exceeded.

Change Summary (click to expand)

The following is a summary of changes in this pull request made by me, your security buddy :robot:. Note that this summary is auto-generated and not meant to be a definitive list of security issues but rather a helpful summary from a security perspective.

Summary:

The code changes in this pull request are focused on improving the reliability, security, and observability of the DefectDojo application in a Kubernetes environment. The key changes include the addition of liveness, readiness, and startup probes for the uwsgi and nginx containers, as well as the ability to configure various parameters for these probes. Additionally, the changes include support for TLS configuration, secret management, container security settings, and Prometheus monitoring.

From an application security perspective, these changes are generally positive and demonstrate a proactive approach to ensuring the health and security of the DefectDojo deployment. The configurable probe parameters, TLS support, and secret management practices help to improve the overall security posture of the application. The container security settings and Prometheus monitoring also contribute to the security and observability of the deployment.

Files Changed:

1. helm/defectdojo/templates/django-deployment.yaml:

   • Added support for configuring liveness, readiness, and startup probes for the uwsgi and nginx containers.
   • Allowed the user to configure various parameters for the probes, such as the initial delay, failure threshold, success threshold, and timeout.
   • Enabled TLS configuration for the application and used Kubernetes secrets to store sensitive information.
   • Allowed the user to configure security context settings for the containers.
   • Included support for Prometheus monitoring.

2. helm/defectdojo/values.yaml:

   • Updated the liveness, readiness, and startup probes for the uwsgi container, including changes to the initial delay, failure threshold, and other parameters.
   • The changes to the probes help improve the overall health monitoring and readiness of the DefectDojo application, which can contribute to its security and reliability.

Powered by DryRun Security

[github-actions[bot]]

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

[kiblik]

@fcecagno, can you try to rebase this PR? I suppose the issue responsible for failing the test might be gone.

[github-actions[bot]]

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

[dryrunsecurity[bot]]

DryRun Security Summary

The pull request introduces changes to the DefectDojo application's health monitoring and readiness, including the addition of liveness, readiness, and startup probes for the UWSGI container, with configurable parameters, and the ability to conditionally enable or disable these probes based on deployment requirements, enhancing the application's security and reliability.

Expand for full summary

Summary:

The code changes in this pull request are focused on improving the health monitoring and readiness of the DefectDojo application, which is a positive security enhancement. The changes primarily involve the configuration of the UWSGI (uWSGI) container, which is part of the Django component of the application.

The key changes include the addition of liveness, readiness, and startup probes for the UWSGI container, as well as the ability to configure various parameters for these probes, such as initial delay, failure threshold, and success criteria. These probes help ensure that the application is fully initialized and ready to receive traffic before accepting requests, reducing the risk of exposing the application in an unstable or vulnerable state.

Additionally, the changes allow for the conditional rendering of the probe configurations, enabling users to enable or disable the probes as needed based on their specific deployment requirements. This flexibility is an important security consideration, as it allows for fine-tuning the application's health monitoring to ensure optimal reliability and availability.

Files Changed:

1. helm/defectdojo/values.yaml:

   • Added new configuration options for the UWSGI container's liveness, readiness, and startup probes, including initial delay, failure threshold, and other parameters.
   • Enabled the liveness, readiness, and startup probes for the UWSGI container, improving the overall health monitoring and reliability of the DefectDojo application.

2. helm/defectdojo/templates/django-deployment.yaml:

   • Added the startupProbe configuration for the uwsgi container, which checks the /uwsgi_health endpoint to determine if the application is ready to receive traffic during the startup phase.
   • Modified the livenessProbe and readinessProbe configurations for the uwsgi and nginx containers, allowing for more control over the probe behavior through configurable parameters.
   • Introduced conditional rendering of the livenessProbe, readinessProbe, and startupProbe configurations based on user-defined values, enabling users to enable or disable these probes as needed.

Overall, these changes are focused on improving the health monitoring and readiness of the DefectDojo application, which is an important aspect of application security and overall system reliability.

Code Analysis

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

Riskiness

:green_circle: Risk threshold not exceeded.

View PR in the DryRun Dashboard.

[Maffooch]

It looks like there has not been any activity here for a while. In order to keep the list of pull requests in a manageable state, we are closing this one for now. If we are making a mistake here, please reopen the pull request, and leave us a note 😄

[fcecagno]

@Maffooch that's alright. Another option would be to merge it, since it looks like it's still an improvement.

[Maffooch]

Whenever you are ready, please convert the pull request from draft to open 😄

[fcecagno]

Whenever you are ready, please convert the pull request from draft to open 😄

😱 Sorry about that, didn't see it was still a draft. It's definitely ready for review.

[github-actions[bot]]

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

[github-actions[bot]]

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