Skip to main content

Traefik - Reverse Proxy & DNS

Traefik is currently in use for the Docker Reverse Proxy, and publishing our services internally. 

Accessing Traefik Dashboard

The Traefik dashboard is available via https://traefik.pbr.org.au/ 

This has HTTP authentication, which creds exist inside of 1Password. 
Note that this interface will only be available once Traefik has been created and is running successfully. If there are issues with the service you may need to explore logs. 

Exposing a service via Traefik Reverse Proxy

Traefik can expose services via Docker Labels, or manually via config files for services not set up directly in Docker

Docker Labels are to be set on the container that is to be exposed - eg, if a service has a frontend container, backend container, and a DB container, you only need to expose the frontend container via labels

Ensure that the container to be exposed is included within the t3_proxy network. If not inside this network, Traefik does not get an interface to point to via its reverse proxy. 

If manually defining a network in your container, ensure that other required containers, such as DB's are connected via a network. This should be socket_proxy, and needs to be defined in addition to t3_proxy on your frontend container

Traefik labels require you to define the service, router config, including inbound ports and hostname, port, and optionally, any associated middlewares. 

When defining a service port, ensure that you are utilising the port INSIDE of the container, that is being referenced. This may not be a standard 80, or 443.
Container documentation typically states exposing ports in a port:port format. Use the right hand port. 

An example of Traefik labels are below

    labels:
      - "traefik.enable=true"
      # HTTP Routers
      - "traefik.http.routers.SERVICE-rtr.entrypoints=websecure-internal,websecure-external"
      - "traefik.http.routers.SERVICE-rtr.rule=Host(`SERVICE.$DOMAINNAME_1`)"
      # Middlewares
      - "traefik.http.routers.SERVICE-rtr.middlewares=chain-no-auth@file"
      # HTTP Services
      - "traefik.http.routers.SERVICE-rtr.service=SERVICE-svc"
      - "traefik.http.services.SERVICE-svc.loadbalancer.server.port=80"

The above code defines the following

  1. The service router is available to be accessed via the websecure-internal and websecure-external entry points
  2. The DNS record for this service is SERVICE.$DOMAINNAME_1 - $DOMAINNAME_1 is an environment variable located in the global .env
  3. Middlewares are chain-no-auth. 
  4. The Service router, is matched to the Service Service
  5. The Service-Service is referencing internal port 80 on this container

Setting the DNS Hostname on this label does not configure the DNS server to point traffic there. 
Best practice is to manually create a DNS CNAME entry on the required servers, referencing your service DNS name to the Docker Host

Traefik uses SNI inspection to determine the incoming URL subdomain, and then utilise the defined Router and Service to route traffic to that container

SSL Certificate Setup & CloudFlare integration

Traefik uses a wildcard *.pbr.org.au certificate globally for all SSL traffic

This certificate is signed by LetsEncrypt, and is done automagically. It is automatically re-procured once expired, via CloudFlare ACME DNS challenges

A secret exists inside of the Docker Stack (reference Server Configuration) which contains an API key for use with CloudFlare
This API key has Zone.Read access for pbr.org.au, and DNS.Edit access for pbr.org.au. 

This key allows DNS changes on our primary domain - do not share this or expose in plaintext files. 

This certificate is saved locally on the Docker Stack, and reused for every service. You should not need to manually intervene. 

If you suspect issues with Traefik relating to SSL certificates, check the Traefik log files, this will show in real time the sites attempting to be accessed, and if failing, what the error is. 

NOTE: Given that internal DNS servers are authoritative for pbr.org.au, Traefik needs to access the Public Cloudflare records published by the ACME challenge in order to succeed and issue a certificate. Traefik is manually configured to use the 1.1.1.1 DNS servers RATHER than the internal DC's.
If implementing Firewall rules restricting DNS outbound access, ensure that the Docker container is exempt.

Middlewares

Middlewares are how we can add extra security to requests made via the reverse proxy, including requiring certain TLS versions, middlemanning a SSO logon, traffic shaping, etc. 
Typically, these are grouped into a middleware chain, which is then defined on the container or manual rule

There are infinite possibilities for these, however we have only created a few to start with. 

Current Middleware chains:

  1. chain-basic-auth
    1. middlewares-rate-limit
    2. middlewares-secure-headers
    3. middlewares-basic-auth
      1. Hardcoded HTTP auth, requires user cred to be part of the users file contained in secrets/
  2. chain-no-auth
    1. middlewares-rate-limit
    2. middlewares-secure-headers
  3. traefik-forward-auth
    1. This uses the Docker container traefik-forward-auth, rather than the file middlewares listed previously
    2. You may need to define the middleware is from Docker if declaring within a File, and omit when being called from Docker Labels
    3. Uses the Traefik Forward Proxy - websecure-external application in Entra ID and adds in an OIDC intermediary auth for sites which DO NOT immediately refer for authentication. 

Traefik Logs & Troubleshooting

Traefik logs are recorded seperately and to files. These are contained within /docker/logs/traefik

Log levels are set to debug, and contained within the compose/traefik.yml file. 

traefik.log - contains actual app information and errors. where you will find access errors with DNS or issues with accessing services
access.log - general log for services being accessed

No comments to display

Back to top