Closed w4tsn closed 2 years ago
What's "DSGVO compliance" and why would it be relevant to nginx access logs?
Ah, well, I mixed that up. What I mean is GDPR (General-Data-Protection-Regulation)-compliance and to be compliant we can't store access logs without a very good reason. Access logs contain IP addresses which are personal data that we should not store to avoid complications, at least in production environments.
IP addresses should only be logged on purpose if the user is sure why they want to do that
I think that's a very strict interpretation of GDPR. If you age out your logs within a few days or weeks you can log anything you want, within reason. See https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/principles-gdpr/how-long-can-data-be-kept-and-it-necessary-update-it_en
Fair. I mean, it's not impossible to configure it anyway if you like it hard-core :D Just not that convenient ;)
Docker configuration can be modified using Jinja templates now so this should be possible now. See #332
Nice! That's great :)
The current way uWSGI is configured to output the debug log makes sense so the proxy error messages are also shown in the logs. Setting the uWSGI log level to e.g.
warn
causes the log output of nginx to be suppressed completely. The problem with this is, that a uWSGI log level ofdebug
will also output the nginx access logs to stdout of the container. Especially regarding DSGVO compliance the access log should be suppressed by default or an easy to use configuration option provided to reduce the hassle.So while a quick-fix would be to reduce the uWSGI log level to e.g.
warn
that is certainly not desired. Better would be to disable the nginx access logs by default, maybe even make it configurable via ENV although that'll require the lua module for nginx (or maybe a CLI param would work too).Editing
/app/nginx.conf
I was not able to deactivate the access log.