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

Container returning status code 200 confuses nginx forward-auth #315

Open
2 tasks done
justSem opened this issue Nov 3, 2024 · 0 comments
Open
2 tasks done

Container returning status code 200 confuses nginx forward-auth #315

justSem opened this issue Nov 3, 2024 · 0 comments
Assignees
Labels
type:question Further information is requested

Comments

@justSem
Copy link

justSem commented Nov 3, 2024

Is there an existing issue for this?

  • I have searched the existing issues
  • And it has nothing to do with Traefik
  • Might be related to http status code 200 instead 404 #41 but I don't think that's the case (the wording is a bit ambiguous)

Describe the bug

So I'm not entirely sure whether this would be an implementation that should be handled by error-pages or ingress-nginx, but allow me to explain.

Let's say you're using forward-auth with nginx (for instance with Authentik's forward-auth proxy provider); and you're using error-pages as your defaultBackend. I've discovered that when your authentication backend is unreachable (i.e.: The deployment is stuck and hasn't registered it's endpoint with the Kubernetes apiserver yet), nginx will 'think' of the request as something it has to pass on to it's default backend.

However, since the container responds with HTTP 200, no matter which page you load; nginx will assume this as an 'okay' to the authentication reqeuest, allowing traffic to flow to your backend application without any authentication.

I would like to use this issue to discuss whether it's desireable for the container to return status codes matching the situation; or whether this should be handled by ingress-nginx instead.
(Or in case my config contains something absolutely stupid I'd be happy to hear that as well :) )

Steps to reproduce

  1. Deploy ingress-nginx with the configuration mentioned below; with error-pages as the defaultBackend.
  2. Deploy a simple app with the auth-url annotations set.
  3. Test to see if you face the same issue :)

Configuration files

# An example for ingess annotations

ingress:
      app:
        className: "external-nginx"
        annotations:
          cert-manager.io/cluster-issuer: "letsencrypt"
          nginx.ingress.kubernetes.io/auth-url: |-
            http://ak-outpost-default.security.svc.cluster.local:9000/outpost.goauthentik.io/auth/nginx
          nginx.ingress.kubernetes.io/auth-signin: |-
            https://your-app.org/outpost.goauthentik.io/start?rd=$escaped_request_uri
          nginx.ingress.kubernetes.io/auth-response-headers: |-
            Set-Cookie,X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid
          nginx.ingress.kubernetes.io/auth-snippet: |
            proxy_set_header X-Forwarded-Host $http_host;
---

# Additional nginx configuration (configmap):

apiVersion: v1
data:
  allow-snippet-annotations: "true"
  block-user-agents: AdsBot-Google,Amazonbot,anthropic-ai,Applebot-Extended,Bytespider,CCBot,ChatGPT-User,ClaudeBot,Claude-Web,cohere-ai,Diffbot,FacebookBot,FriendlyCrawler,Google-Extended,GoogleOther,GPTBot,img2dataset,omgili,omgilibot,peer39_crawler,peer39_crawler/1.0,PerplexityBot,YouBot,
  client-body-buffer-size: 100M
  client-body-timeout: "120"
  client-header-timeout: "120"
  custom-http-errors: 404,500,503,502,501,401,403
  enable-brotli: "true"
  enable-ocsp: "true"
  enable-real-ip: "true"
  force-ssl-redirect: "true"
  hsts-max-age: "3.14496e+07"
  keep-alive: "120"
  keep-alive-requests: "10000"
  log-format-escape-json: "true"
  log-format-upstream: |
    {"time": "$time_iso8601", "remote_addr": "$proxy_protocol_addr", "x_forwarded_for": "$proxy_add_x_forwarded_for", "request_id": "$req_id", "remote_user": "$remote_user", "bytes_sent": $bytes_sent, "request_time": $request_time, "status": $status, "vhost": "$host", "request_proto": "$server_protocol", "path": "$uri", "request_query": "$args", "request_length": $request_length, "duration": $request_time,"method": "$request_method", "http_referrer": "$http_referer", "http_user_agent": "$http_user_agent"}
  proxy-body-size: "0"
  proxy-buffer-size: 16k
  ssl-protocols: TLSv1.3 TLSv1.2
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: nginx-external
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.11.3
    helm.sh/chart: ingress-nginx-4.11.3
    helm.toolkit.fluxcd.io/name: nginx-external
  name: nginx-external-controller
---

Relevant log output

No response

Anything else?

No response

@justSem justSem added the type:bug Something isn't working label Nov 3, 2024
@tarampampam tarampampam added type:question Further information is requested and removed type:bug Something isn't working labels Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants