Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Enable Traefik forward authentication and dynamic file configuration #427

Closed
wants to merge 1 commit into from

Conversation

allthestairs
Copy link
Contributor

What this PR does / why we need it:

Adds forward authentication to Traefik to enable OAuth authentication for any ansible-nas integrated application proxied by traefik.

Which issue (if any) this PR fixes:

#425

Any other useful info:

Right now this only adds functional authentication middleware to traefik, it doesn't enable authentication for any applications. Right now the best way I can think of to add authentication is the addition of a label and one boolean variable to every ansible task. You can protect an entire traefik entrypoint without touching the individual tasks but there are good reasons not to OAuth every ansible-nas application.

Note: the client id, client secret, and cookie secret in this are examples and do not correspond to any real Google OAuth setup.

This also includes an unnecessary change to enable file providers in traefik in case anyone wants to manually add some non-ansible application to their traefik setup by dropping some yaml/toml files into a host folder.

@davestephens
Copy link
Owner

davestephens commented Feb 22, 2021

I like the idea of this as an option, but how would someone optionally enable this per container without hacking up the individual docker_container tasks within the roles?

I think as a POC this is great, but it needs some thought about how to integrate it without breaking all of the already established patterns in Ansible-NAS.

@allthestairs
Copy link
Contributor Author

I like the idea of this as an option, but how would someone optionally enable this per container without hacking up the individual docker_container tasks within the roles?

I think as a POC this is great, but it needs some thought about how to integrate it without breaking all of the already established patterns in Ansible-NAS.

I put more info about this in the connected Issue. The easiest way to attach the middleware is to add a label to the container, but you can only attach labels at build time. To match what I see as the current patterns as I see them we would need to modify the existing roles to some degree by adding one label line and one boolean configurable to enable. That way no one needs to touch the roles directly, and could just set app_authentication = "true" in their config and it would enable it.

That is definitely the "simplest" way to integrate this though it does require modifying every role and having it in whatever template someone might use to add more roles in the future the same way the existing Traefik config is. I don't know of any ways to attach a label to a container in ansible without making any change to the docker_container directive at all but maybe it is possible, I don't know too much advanced ansible.

You can also use a file-based "dynamic configuration" for Traefik. Doing it this way is feasible, but this would require a mapping of config variable names to containers which I haven't seen but I haven't dug through all of anisble-nas. Hypothetically, we could use ansible to generate a file based on searching for specific config variables, somehow discovering which container router needs to be given the middleware, and adding it to the yaml/toml file. The more work you put on the user in the config the easier this is. Making app_authentication = "true" is hard unless all of the variables always match our Traefik router names. Making app_authentication = "true", app_auth_router = "traefik.http.routers.app" work would be easy but then users would have to look up what the traefik router name is to enable it in the config or (again) we would need to add that variable to every role.

@dtee
Copy link

dtee commented Sep 3, 2023

I am bit late to the party, but I ended up doing something similar to secure apps that do not auth by default like dashy and code-server. Here's how I ended enabling per app .

Modified main.yml and added the middle ware for apps I want protected.

          traefik.http.routers.code_server.middlewares: "traefik-forward-auth"

I am bit too lazy to add a proper task in ansible-nas, but here's what the config looks like in docker-compose:

  traefik-forward-auth:
    image: thomseddon/traefik-forward-auth:2.1.0
    deploy:
      restart_policy:
        condition: unless-stopped
    ports:
      - "4181:4181"
    environment:
      - PROVIDERS_GOOGLE_CLIENT_ID=
      - PROVIDERS_GOOGLE_CLIENT_SECRET=
      - SECRET=something-random
      # INSECURE_COOKIE is required if not using a https entrypoint
      - LOG_LEVEL=debug
      # comment out AUTH_HOST if you'd rather use individual redirect_uris (slightly less complicated but more work)
      - AUTH_HOST=
      - COOKIE_DOMAIN=
      - WHITELIST=
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.auth.rule=Host(``)"
      - "traefik.http.routers.auth.tls.certresolver=letsencrypt"
      - "traefik.http.routers.auth.entrypoints=websecure"
      - "traefik.http.routers.auth.tls=true"
      - "traefik.http.routers.auth.tls.domains[0].main="
      - "traefik.http.routers.auth.tls.domains[0].sans="     
      - "traefik.http.services.auth.loadbalancer.server.port=80"
      
      - "traefik.http.routers.auth.service=auth@docker"
      - "traefik.http.routers.auth.middlewares=traefik-forward-auth"
      - "traefik.http.middlewares.traefik-forward-auth.forwardauth.address"
      - "traefik.http.middlewares.traefik-forward-auth.forwardauth.trustForwardHeader=true"
      - "traefik.http.middlewares.traefik-forward-auth.forwardauth.authResponseHeaders=X-Forwarded-User"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants