Document Traefik tuning for forward auth

[sylr]

If your are using Traefik to proxy requests to the pomerium proxy acting as forward auth component, then, it is required to configure traefik so that it allows "X-Fowarded-*" headers.

See https://docs.traefik.io/v2.0/routing/entrypoints/#forwarded-header

[branchmispredictor]

Are you sure that is the case?

I have been getting by with the following config for forward auth behind traefik 2 without any special config for forwarded headers. Using either the forwardedHeaders.insecure or forwardauth.trustForwardHeader setting should be discouraged and certainly not required from my understanding.

Edit:
Ah, I see your point. You need forwardedHeaders.insecure if you are using traefik in front of the forward-auth endpoint in Pomerium.

The problem as I understand it is that Traefik will strip the X-Forwarded-* headers by default, even the X-Forwarded-* headers it added for Forward Auth! Furthermore, you cannot set forwardedHeaders.trustedIPs=localhost because Traefik persists the external remote addr when deciding to strip forwarded headers. This means the only options right now are to enable forwardedHeaders.insecure for the whole Traefik endpoint, which seems insecure. Alternatively you could fall back on setting the uri to auth in the Forward Auth endpoint like before.

(source)

This is unfortunate and may require a change to Traefik code if I am reading things correctly. It may also be beneficial to see how other Traefik forward auth plugins work.

[branchmispredictor]

One final thing you could do is route your forward auth locally instead of externally. This seems to be what is happening for other Traefik forward auth providers. These are snippets from some local testing of this approach:

docker-compose.yaml:

    httpbin:
        image: "kennethreitz/httpbin"
        labels:
            - "traefik.http.middlewares.pomerium.forwardauth.authResponseHeaders=x-pomerium-jwt-assertion"
            - "traefik.http.middlewares.pomerium.forwardauth.address=http://fwdauth:80"
            - "traefik.http.routers.httpbin.middlewares=pomerium@docker"
            - "traefik.enable=true"
            - "traefik.http.routers.httpbin.rule=Host(`httpbin.corp`)"
            - "traefik.http.routers.httpbin.entrypoints=websecure"
            - "traefik.http.routers.httpbin.tls.certresolver=myresolver"

    pomerium:
        image: pomerium/pomerium:master
        networks:
            default:
                aliases:
                    - fwdauth
        volumes:
            - ./config/pomerium/config.yaml:/pomerium/config.yaml:ro
        labels:
            - "traefik.http.services.pomerium.loadbalancer.server.port=80"
            - "traefik.enable=true"
            - "traefik.http.routers.pomerium.rule=Host(`authenticate.corp`)"
            - "traefik.http.routers.pomerium.entrypoints=websecure"
            - "traefik.http.routers.pomerium.tls.certresolver=myresolver"

config.yaml:

address: :80
forward_auth_url: http://fwdauth:80
authenticate_service_url: https://authenticate.corp

policy:
    - from: https://httpbin.corp
      to: http://httpbin.localhost
      allowed_users:
          - myemail@gmail.com

This requires that everything is locally route-able, which I'm not sure is the case for advanced usages of docker-compose. Definitely worth more discussion from people less new to Pomerium than I.

[lukasmrtvy]

What about whitelisting whole internal cluster cidr ? For example default k3s cidr: --entryPoints.websecure.forwardedHeaders.trustedIPs=10.42.0.0/16

EDIT: can confirm that with internal forward_auth_url, you dont need to set trustedIPs

[calebdoxsey]

The docker-compose example was updated with the insecure option.