Review traefik configuration, preferably implement a completely dynamic configuration

[devraj]

Is your feature request related to a problem? Please describe.
The current traefik configuration is a relic from when the team was working on projects and deploying them via docker-compose on Linode servers.

The first issues as amongst many of the things that I took handovers on is inconsistency. For example here there are various elements configured via the dynamic route and then others via the static route.

Here's an extract from the current production docker-compose file for production:

      - "--providers.docker"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.file"
      - "--providers.file.filename=/opt/traefik/traefik-dynamic.toml"

this shows how there are a couple of different ways configurations are being read.

Further there are various security concerns in the configuration:

• HSTS headers are missing
• The configuration allows for older versions TLS that are known to have security vulnerabilities
• X-Frame-Options to be set to DENY

Describe the solution you'd like
Ideally we want to use a completely dynamic configuration based on the docker or kubernetes providers. A dynamic configuration would allow us to use variables which would make the configuration generic for all our projects.

Secondly we need to review the labels associated to the API container. These are a relic from when the team was working on in the applications in 2021.

Properly review the security requirements of modern web applications:

• HTTP Strict Transport Security (HSTS)
• Support good known versions of TLS

The ultimate aim of the template is to achieve A+ security rating on any testing platform.

Note this ticket should be updated once a proper review of security standards has been conducted.

Reverse proxy considerations
Our configure should provide reverse proxy configurations:

• For containers e.g API or front end wrapped in container (accompanying docs)
• Proxying Object stores for serving front end clients and assets (where scale is a factor)
• Considerations for sitting behind a content distribution network

HSTS configuration
Label based configuration for HSTS, as per this article (again this is subject to be reviewed after my research)

traefik.frontend.headers.STSSeconds: "31536000"
traefik.frontend.headers.STSIncludeSubdomains: "true"
traefik.frontend.headers.STSPreload: "true"

Describe alternatives you've considered
None as this is the template that should serve our other applications

Additional context
As realised with much of the work that was done in 2021, these configurations are uniformed from a security standpoints and should be abandoned and built from the ground up.

Ultimately we should put the configuration through SSLlabs and see it meets the A+ requirements of a modern web application.

[devraj]

Letsencrypt has a staging environment which allows you to negate any rate limits when prototyping or testing your configuration.

[devraj]

Everything but proxying the bucket via labels is working in the configuration. It turns out that you can't define load balancer servers using labels, this is a bug/missing feature in Traefik itself.

This was discovered following my discussion on their forums.

See issue: Allow to configure server URLs with label providers

Awaiting this fix before we can move completely to labels.

Note that I have checked this against the 3.0 beta releases as well

In the meantime, I will refactor everything else but the load balancer configuration to labels.

This is reflective of how the original configuration was without any documentation on why it was maintained that way.

A current set of labels are maintained by traefik

[devraj]

See #78 as moving to Kubernetes might invalidate this requirements. We are no longer going to use compose to deploy and I have already started moving things to Kubernetes for development.