-
-
Notifications
You must be signed in to change notification settings - Fork 962
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
path /outpost.goauthentik.io not found #8956
Comments
I had the same exact issue... turned out to be, for me 2 things:
I confirm I am on 2024.2.2 |
Unfortunately, I have no embedded-outpost. |
I don't think it's a middleware-related problem, both forward auth and mypublic.dns/outpost.goauthentik.io/ page respond 404. |
I had exactly that same page as well, that was caused by some missconfig I had, when I was looking at the logs in traefik I was getting error saying my certificates where missing and indeed they where. I would suggest checking if traefik can resolve all the services and has no errors in its logs. That is how I eventually sorted it out. At least in my case. As for my configs are all on github just check my |
Have the same issue on the docker version, did 2 fresh install tests, one with 2024.2.2, another with 2023.10.7, I was able to access /outpost.goauthentik.io on the 10.7 version, but on the 2.2 I received the same not found page. This was on a fresh docker install with no other containers, just the docker-compose stack from the installation page. |
Hey 👋 |
Also had this issue after upgrading, and managed to resolve it by changing the redirect location on the provider. The provider was always configured with "Forward auth (single application)" mode. This was the old configuration in nginx for the app.
And when I browsed The fix was as simple as changing the redirect to
I know it says in the example configuration, this should be used for domain level providers, and not single application.
Not sure if that was changed recently, but I have always had the redirect configued as above, and it was working fine prior to upgrading, maybe as @anleg suggested, related to the PR #7539. |
Have the same issue, just downloaded the docker compose example, ran it, tried to do I also set up This makes the builtin proxy totally broken. |
Update: my issue was the same as @fREAST, just by changing my command a bit (note the part setting the $ curl -kvso /dev/null -H 'Host: example.com' -H 'X-Original-URL: https://example.com/' 'https://sso.shiro.lan/outpost.goauthentik.io/start?rd=https%3A%2F%2Fexample.com'
* Host sso.shiro.lan:443 was resolved.
* IPv6: (none)
* IPv4: 192.168.2.247
* Trying 192.168.2.247:443...
* Connected to sso.shiro.lan (192.168.2.247) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [1016 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [79 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
* subject: CN=sso.shiro.lan
* start date: Apr 3 19:09:44 2024 GMT
* expire date: Apr 4 19:10:44 2024 GMT
* issuer: O=StepCA.Lan; CN=StepCA.Lan Intermediate CA
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA256
* Certificate level 1: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA256
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [57 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [57 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://sso.shiro.lan/outpost.goauthentik.io/start?rd=https%3A%2F%2Fexample.com
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: example.com]
* [HTTP/2] [1] [:path: /outpost.goauthentik.io/start?rd=https%3A%2F%2Fexample.com]
* [HTTP/2] [1] [user-agent: curl/8.6.0]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [x-original-url: https://example.com/]
} [5 bytes data]
> GET /outpost.goauthentik.io/start?rd=https%3A%2F%2Fexample.com HTTP/2
> Host: example.com
> User-Agent: curl/8.6.0
> Accept: */*
> X-Original-URL: https://example.com/
>
{ [5 bytes data]
< HTTP/2 302
< server: nginx
< date: Wed, 03 Apr 2024 21:59:03 GMT
< content-type: text/html; charset=utf-8
< content-length: 350
< location: https://sso.shiro.lan/application/o/authorize/?client_id=...&redirect_uri=...&response_type=code&scope=email+ak_proxy+profile+openid&state=...
< set-cookie: authentik_proxy_6MQSP9KS=...; Path=/; Expires=Thu, 04 Apr 2024 21:59:04 GMT; Max-Age=86401; HttpOnly; Secure; SameSite=Lax
< vary: Accept-Encoding
<
{ [350 bytes data]
* Connection #0 to host sso.shiro.lan left intact |
I have the same issue. I'm running k8s with an nginx ingress. The documentation needs to be updated to support the host header requirement if its possible. After about an hour of googling and using chatgpt, I'm unable to get this working with an nginx ingress even though I know that setting the host header should resolve it. this is especially frustrating because the nginx ingress documentation specially mentions using the |
Same issue here if I try to ping on version 2024.2.3
|
@P4R4DiSi4C the $ curl -vso /dev/null 'https://app.company/outpost.goauthentik.io/start?rd=/' |
This very much looks like the embedded outpost isn't start for some reason, please post the server container's logs @GGG-KILLER the /ping endpoint does exist, however if the embedded outpost is not running it won't return anything |
@BeryJu If it does exist, it doesn't seem to be working on my instance at all. The following return 404: $ curl -vso /dev/null -H 'Host: mega.shiro.lan' 'https://sso.shiro.lan/outpost.goauthentik.io/ping'
< HTTP/2 404
< server: nginx
< date: Tue, 23 Apr 2024 16:44:10 GMT
< content-type: text/plain; charset=utf-8
< content-length: 19
< vary: Accept-Encoding
< x-content-type-options: nosniff
<
{ [19 bytes data]
$ curl -vso /dev/null 'https://sso.shiro.lan/outpost.goauthentik.io/ping'
< HTTP/2 404
< server: nginx
< date: Tue, 23 Apr 2024 16:45:10 GMT
< content-type: text/html; charset=utf-8
< content-length: 3568
< vary: Accept-Encoding
< referrer-policy: same-origin
< vary: Accept-Encoding
< vary: Cookie
< x-authentik-id: 05ebd09f661a426b9aa9dcb187918109
< x-content-type-options: nosniff
< x-frame-options: DENY
< x-powered-by: authentik
< However the $ curl -vso /dev/null -H 'Host: mega.shiro.lan' 'https://sso.shiro.lan/outpost.goauthentik.io/start?rd=/'
< HTTP/2 302
< server: nginx
< date: Tue, 23 Apr 2024 16:45:44 GMT
< content-type: text/html; charset=utf-8
< content-length: 354
< location: https://sso.shiro.lan/application/o/authorize/?client_id=...&redirect_uri=...&response_type=code&scope=openid+profile+ak_proxy+email&state=...
< set-cookie: authentik_proxy_4i6JRZsF=...; Path=/; Expires=Wed, 24 Apr 2024 16:45:45 GMT; Max-Age=86401; HttpOnly; Secure; SameSite=Lax
< vary: Accept-Encoding
< |
The |
I am also experiencing the same issue. This worked on 2023 on the same k3s cluster, and after upgrade to 2024 it stopped working. Installation was done using helm. Kubernetes version: |
I am also having the same problem with my existing docker compose installation. On 2023.10.7, the embedded outpost will respond correctly to the healthchecks. Here is curl run from inside the authentik-server container:
And same test after upgrading to 2024.4.1:
Everything else works normally. The embedded outpost is up and serving authentication requests. I also tested with curl to http://localhost:9300/outpost.goauthentik.io/ping but this returned HTTP 404 on both versions. |
Have the same issue. If I try to access /outpost.goauthentik.io, I also get the error page not found 404. Embedded outpost is online and seems to be working properly. Same if I try to access it through port 9300. Authentik version 2024.4.2 Edit: Changes somewhere between 2024.2.0-rc1 and 2023.10.7 seems to be the issue |
Today I spotted that I have the same issue. Version: 2024.4.2, run inside docker. |
Same issue here, clean fresh docker compose install with no settings changed. The embedded outpost is not working on 2024.4.2 and also not working on the newest version 2024.6.0-rc2. In my server logs im getting these errors: warning | error=authentik starting event=failed to proxy to backend logger=authentik.router timestamp=2024-06-22T11:26:49Z INF | event=Starting gunicorn 22.0.0 logger=gunicorn.error timestamp=1719055628.460975 INF | event=Listening at: unix:/dev/shm/authentik-core.sock (17) logger=gunicorn.error timestamp=1719055628.461775 INF | event=Using worker: lifecycle.worker.DjangoUvicornWorker logger=gunicorn.error timestamp=1719055628.4618392 INF | event=Booting worker with pid: 54 logger=gunicorn.error timestamp=1719055628.4681582 INF | event=Booting worker with pid: 55 logger=gunicorn.error timestamp=1719055628.5095584 ERR | error=403 Forbidden event=Failed to fetch outpost configuration, retrying in 3 seconds logger=authentik.outpost.ak-api-controller timestamp=2024-06-22T11:27:08Z |
Is there any movement on this? Or some workaround to get this working? |
The one odd thing I saw on my Authentik dashboard was under Logs from {"event":"/outpost.goauthentik.io/auth/nginx","host":"app.enterprise.com","level":"info","logger":"authentik.outpost.proxyv2.application","method":"GET","name":"app","remote":"10.42.0.19","runtime":"4.71
6","scheme":"http","size":21,"status":401,"timestamp":"2024-07-18T07:25:47Z","user_agent":"Mozilla/5.0 (Windows NT 10.0; rv:128.0) Gecko/20100101 Firefox/128.0"}
{"auth_via": "unauthenticated", "domain_url": "auth.enterprise.com", "event": "/outpost.goauthentik.io/start?rd=https://app.enterprise.com/", "host": "auth.enterprise.com", "level": "info", "logger": "
authentik.asgi", "method": "GET", "pid": 46, "remote": "10.42.2.28", "request_id": "d1d62aa5e6e248b9a3fe6b723bd25285", "runtime": 4, "schema_name": "public", "scheme": "https", "status": 404, "timestamp": "2024-07-
18T07:25:47.510619", "user": "", "user_agent": "Mozilla/5.0 (Windows NT 10.0; rv:128.0) Gecko/20100101 Firefox/128.0"} Logs from the {"event":"/outpost.goauthentik.io/auth/nginx","host":"app.enterprise.com","level":"info","logger":"authentik.outpost.proxyv2.application","method":"GET","name":"app","remote":"10.42.0.19","runtime":"4.71
6","scheme":"http","size":21,"status":401,"timestamp":"2024-07-18T07:25:47Z","user_agent":"Mozilla/5.0 (Windows NT 10.0; rv:128.0) Gecko/20100101 Firefox/128.0"}
{"auth_via": "unauthenticated", "domain_url": "app.enterprise.com", "event": "/outpost.goauthentik.io/start?rd=https://app.enterprise.com/", "host": "app.enterprise.com", "level": "info", "logger": "
authentik.asgi", "method": "GET", "pid": 46, "remote": "10.42.2.28", "request_id": "d1d62aa5e6e248b9a3fe6b723bd25285", "runtime": 4, "schema_name": "public", "scheme": "https", "status": 404, "timestamp": "2024-07-
18T07:25:47.510619", "user": "", "user_agent": "Mozilla/5.0 (Windows NT 10.0; rv:128.0) Gecko/20100101 Firefox/128.0"} Here's what my apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app
namespace: database
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/auth-url: http://ak-outpost-authentik-embedded-outpost.authentik.svc.cluster.local:9000/outpost.goauthentik.io/auth/nginx
nginx.ingress.kubernetes.io/auth-signin: https://auth.enterprise.com/outpost.goauthentik.io/start?rd=$scheme://$http_host$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;
proxy_set_header X-Real-IP $remote_addr; # Forward real client IP
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Forward client IPs
proxy_set_header X-Forwarded-Proto $scheme; # Forward protocol (HTTP/HTTPS)
spec:
rules:
- host: app.enterprise.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app
port:
number: 80
Results in Please let me know if I can provide anymore data at all. Thanks. |
Same for me after upgrade to 2024.6.1 |
Please react with emojis or subscribe to the issue. Bumping the thread just spams subscribed people. |
For me (with Authentik 2024.6.3) this is still a problem. Reading through this thread the only workaround seems to be to downgrade to 2023.10.7, but I am afraid that there is no upgrade path after that. Does anyone know if work is being done to resolve this issue? |
For me it works, check my comment from March. |
@camrossi thanks for you response! Unfortunately I don't have a Kubernetes environment running so I cannot test with the Kubernetes deployment steps. I am using:
For both versions I've tried the same URL: When starting a clean environment with 2023.10.7 I can confirm the forward proxy works and the When starting a clean environment with 2024.6.3 and visiting the above URL, no redirect is executed and a 404 Not Found is returned instead. |
@camrossi would it be possible to link the comment/issue? Cursory search with your username did not return a good deal about this. I'm experiencing very similar issues to @rlenferink, old envs are fine, new envs run into 404. Thanks. |
@plsnotracking sure here: #8956 (comment) Also @rlenferink I run this on my "home" K8s clusters and have never tested on anything else than this one environment but I recall the struggle was quite long with this one :( |
This issue is still present with latest I'm using Podman Quadlets with rootless containers
Not using Docker integration so there isn't any. Outpost shows as working And documentation at https://version-2024-6.goauthentik.io/docs/troubleshooting/forward_auth/general#ensure-outpostgoauthentikio-is-accessible
Should return HTTP 204 but instead we get 404. Workaround is deploying separate Proxy Outpost instance. https://version-2024-6.goauthentik.io/docs/outposts/manual-deploy-docker-compose |
any update on this? |
It seems like the developers don't care about this problem |
So looking at the configuration that Authentik Generates for me:
So looking at some of the urls.
This is what I have for ingress. And running
This is what I see in the app, that authentik responds with a 404 and nginx gives me an error 500.
And the service for the embedded output is
And the outpost ingress
Looking at the ingress for authentik
And looking at the
@BeryJu where does this need to route? To the server pods? or to the What should |
@ilijamt This needs to point to your authentik server. If you're running in Docker-Compose for example, this could be the service name of the server like If you're using the embedded outpost not the manual outpost, then:
|
That’s what I have it point to. But it does not work. The service I’m using
is uptime Kuma is external and not inside the k8s cluster.
So before the upgrade to 2024 this worked without an issue. The proxy pass
pointed to https://authentik.example.com. But since 2024 version it doesn’t
work. I use k8s with nginx and not traefik. So something has changed
between the last version of 2023 and 2024.
Is there a way to troubleshoot the flow to find outs why the embedded
outpost does not work? As you can see in the text it goes to the server
deployment but it returns a 404.
…On Mon, 19 Aug 2024 at 00:47, Ryan Schachte ***@***.***> wrote:
What should http://outpost.company:9000 point to?
@ilijamt <https://github.com/ilijamt> This needs to point to your
authentik server. If you're running in Docker-Compose for example, this
could be the service name of the server like authentik or server. K8s
would be similar.
If you're using the *embedded* outpost *not* the manual outpost, then:
location /outpost.goauthentik.io {
proxy_pass http://server:9000/outpost.goauthentik.io;
—
Reply to this email directly, view it on GitHub
<#8956 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIWFY5Y3CAGPL4L5WQEBJDZSEQBVAVCNFSM6AAAAABE4M72OKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJVGQZDEMRYGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I'm not using Kubernetes, so it's hard for me to suggest specifically, but a good start would be the logs for Authentik. I would also add more granular debug logs on NGINX side to see what request headers are flowing through the system. For example, Why would you curl this mate? This is not a real URL. |
Added notes for getting this working with docker-compose and NGINX. |
If you look at the comment I made you can see the output of the curl
command as well as the corresponding nginx log.
…On Mon, 19 Aug 2024 at 01:01, Ryan Schachte ***@***.***> wrote:
I'm not using Kubernetes, so it's hard for me to suggest specifically, but
a good start would be the logs for Authentik.
I would also add more granular debug logs on NGINX side to see what
request headers are flowing through the system.
For example, ❯ curl https://authentik.example.com/outpost.goauthentik.io
-I
Why would you curl this mate? This is not a real URL.
authentik.example.com won't resolve to anything from a DNS perspective
since this is just an example domain.
—
Reply to this email directly, view it on GitHub
<#8956 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIWFYZM3QMHTPLP5C5NDF3ZSERTTAVCNFSM6AAAAABE4M72OKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJVGQZDKNJXGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Ah I see, you configured this dummy host. Are you trying to use embedded outpost or no? Your NGINX conf shows external outpost when it should point to authentik core itself. I would think you would want
|
same problem here for me even setup route throws 404 when accessing after clean install via reverse-proxy and tld: route/setup is working when accessing container directly: so this has to be a misconfigured nginx |
Same issue here. 404 when accessing |
I am not using kubernetes but docker stacks with Traefik but I am running into the same problem. Is there any solution to this? |
I am having the same problem behind an nginx proxy, is there any known workaround to fix this? |
I fixed this problem with two things:
|
Still encountering this issue on 2024.10.1 using the embedded outpost. Some context on the setup:
I am trying to enable the Home Assistant integration (using Bery's own HACS repo: hass-auth-header) so that I can login to the HA instance through authentik but to no avail. Looking at logs, seems the outpost succesfully responds to
However, when hitting
Seems like somewhere the outpost is not handling the endpoints correctly. Above behavior is the same for other outpost URIs (eg. Any help/ideas on a fix would be appreciated, kinda stuck not using the outpost at all currently, but not all programs I use support OAuth2/OIDC unfortunately. EDIT: Found my problem when looking at this issue. The traefik instance in front of authentik itself was only routing the FQDN of authentik. As the |
Describe the bug
After updating to the version 2024.2.2 the path /outpost.goauthentik.io is "not found"(404)
Before opening this issue, I performed the following test:
I did two fresh installations(even without the first login) on my k3s the first one with version 2023.10.7 the second one with version 2024.2.2.
I verified that I did not have custom ingress/ingressRoute
In version 2023 navigating to the url authentik.domain.com/outpost.goauthentik.io the page is correct.
In version 2024 I get an error message "Not Found"
Authentik is installed via helm and the only change in the configuration file is as follows:
2023:
2024:
To Reproduce
Perform a clean installation of the 2 versions
Expected behavior
the path /outpost.goauthentik.io the path returns an error message: Not Found
Screenshots
2023:
2024:
Logs
2024.2.2
Version and Deployment (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: