Deploying Defectdojo on AWS causes unhealthy ALB

[lme-nca]

Bug description When deploying on AWS the ALB healthcheck fails because it sets the "HTTP_HOST" header to the PODS IP address. The "HTTP_HOST" value of the ALB healthcheck can not be changed, this results in unhealthy loadbalancer status and the following error in the DJANGO logs:

`jango.core.exceptions.DisallowedHost: Invalid HTTP_HOST header: 'XX.XXX.XXX:8443'. You may need to add '10.134.200.129' to ALLOWED_HOSTS.

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/django/core/handlers/exception.py", line 165, in get_exception_response response = callback(request, exception=exception) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/dojo/views.py", line 29, in custom_bad_request_view return render(request, "400.html", {}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/shortcuts.py", line 24, in render content = loader.render_to_string(template_name, context, request, using=using) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/template/loader.py", line 62, in render_to_string return template.render(context, request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/template/backends/django.py", line 61, in render return self.template.render(context) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 173, in render Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/django/core/handlers/exception.py", line 56, in inner response = get_response(request) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/utils/deprecation.py", line 135, in call with context.bind_template(self): File "/usr/local/lib/python3.11/contextlib.py", line 137, in enter return next(self.gen) ^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/template/context.py", line 254, in bind_template response = self.process_request(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/middleware/common.py", line 48, in process_request updates.update(processor(self.request)) host = request.get_host() ^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/http/request.py", line 152, in get_host ^^^^^^^^^^^^^^^^^^^^^^^ File "/app/dojo/context_processors.py", line 38, in bind_alert_count if request.user.is_authenticated: ^^^^^^^^^^^^ raise DisallowedHost(msg)`

Steps to reproduce Steps to reproduce the behavior:

1. run Defectdojo on EKS AWS
2. Have a ALB for ingress 3.Watch the healthcheck spam your AWSGI
3. See error

Expected behavior

• The healthcheck works without producing an error

Deployment method (select with an X)

• [ ] Docker Compose
• [x] Kubernetes
• [ ] GoDojo

Environment information

• AWS (EKS) but actually caused by ALB

Logs see above

[kiblik]

I believe that this should be fixed in a better way in the future but at least for now: If ALB Pod is fixed, you know its IP. Can you add it as an alternative host

https://github.com/DefectDojo/django-DefectDojo/blob/738dca4534382049ca7587a60fb6b33715213943/helm/defectdojo/values.yaml#L52-L56

https://github.com/DefectDojo/django-DefectDojo/blob/738dca4534382049ca7587a60fb6b33715213943/helm/defectdojo/templates/_helpers.tpl#L126-L136

https://github.com/DefectDojo/django-DefectDojo/blob/597cced050421edf206a55e154216c288cf3d238/helm/defectdojo/templates/configmap.yaml#L16

https://github.com/DefectDojo/django-DefectDojo/blob/597cced050421edf206a55e154216c288cf3d238/dojo/settings/settings.dist.py#L322-L325

[lme-nca]

I disagree first of all the IP of a POD is anything but static (nor are static IPs in kubernetes really advisable/good practice) , nor easy to determine through a helm deployment dynamically, which would mean first deploying then determining the IP and then setting it in the "ALLOWED_HOSTS" field. Furthermore, I would say that even the current Health/Liveness-checks of the kubernetes deployment could use this /Health endpoint instead of calling the Forms/login page and setting the HTTP_HOST header synthetically.

Lastly if someone really wants a quick and dirty solution they could configure the NGINX to do location /health/ { access_log off; return 200; } But this is not a true healthcheck of the Django application at all (i..e the AWS loadbalancer might think you application is live but its actually only testing the NGINX pod)

Either way I have proposed a fix here: https://github.com/DefectDojo/django-DefectDojo/pull/9508

[kiblik]

Sorry for the delay. I see the context better now and I can agree with you.

[lme-nca]

Hi @kiblik thanks for reconsidering, if you want you can reopen the pull request https://github.com/DefectDojo/django-DefectDojo/pull/9508 and I would rebase it and check that is still passes the tests.

I could also remove all mentions of AWS and rewrite the existing healthchecks (for the k8 deployment) to also use this Health endpoint, this would make it more clear that its a generic HEALTH endpoint solution.

[kiblik]

Unfortunately, I have only "regular permissions" in this project, I'm not a maintainer here. We will see the reaction of others in PR.