mirror of
https://github.com/moghtech/komodo.git
synced 2026-05-07 10:53:18 -05:00
[GH-ISSUE #165] OIDC not resolving service names and KOMODO_OIDC_REDIRECT is ignored #8250
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/komodo#8250
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mikemilligram on GitHub (Oct 30, 2024).
Original GitHub issue: https://github.com/moghtech/komodo/issues/165
Trying to connect Komodo to my Authentik instance.
Using this configuration
fails to start the container altogether, with the error message
However, resolving that name from inside the container does work, when I disable OIDC.
In any case, to work around this, I tried setting the IP address of the container directly, and that worked out at first:
But once I click the OIDC button on the login page, it redirects me to
http://10.0.1.3:9000/application/o/authorize/...instead of my public URL.
I also tried only setting the provider variable to my public URL. That way the container starts out fine, but the UI never becomes available and after a few minutes the container crashes with this error message:
And from inside the container the public URL resolves to the correct IP address, but any requests to Authentik time out.
It works from other docker containers in the same docker network without issue.
@mbecker20 commented on GitHub (Nov 1, 2024):
I anticipated this situation but it does seem the
KOMODO_OIDC_REDIRECTimplementation doesn't work to fix it. Thanks for bringing to my attention, I'm taking a look.@mbecker20 commented on GitHub (Nov 1, 2024):
See https://github.com/mbecker20/komodo/releases/tag/v1.16.7
@mikemilligram commented on GitHub (Nov 1, 2024):
Great, that works, thank you so much!
I'm still having the issue with the name not resolving, though.
Running
curl https://authentik.mydomain.com/application/o/komodo/.well-known/openid-configurationfrom inside the core container does not work and eventually times out.curl https://authentik_server:9000/application/o/komodo/.well-known/openid-configurationresolves, but returns nothing.Only when I use the container IP address, do I get a correct result back.
Any idea what could be the reason for that? It could of course be a misconfiguration on my part, but like I said so far I haven't run into this issue with any other service.
Here is the verbose output of the curl command using the docker internal name instead of the IP address:
@mbecker20 commented on GitHub (Nov 1, 2024):
You are getting 404 on /application/o/komodo/.well-known/openid-configuration, meaning this route doesn't exist on Authentik. Did you setup your Provider / Application for Komodo? the "slug" should be "komodo" (lowercase) in this case.
@mbecker20 commented on GitHub (Nov 1, 2024):
The full config on Komodo side should be:
@mikemilligram commented on GitHub (Nov 1, 2024):
It does exist, like I said, when using the public URL, I get the correct data back, just from inside the komodo core container I can't access it. The public URL (https://authentik.mydomain.com/...) gives a timeout, the docker internal name (http://authentik_server:9000/...) gives the error I sent above. Only the docker internal IP address (http://10.0.1.x:9000/...) gives me the correct result from within the container.
Using
everything works, but replacing the first line with
won't even let the container launch.
@mbecker20 commented on GitHub (Nov 1, 2024):
At this point this seems like a configuration issue.
Are Authentik and Komodo part of the same network docker network? And unless you set
container_name: authentik_serverin your Authentik compose file, if they aren't part of the same compose project, the container name will be something likeauthentik-authentik_server-1from the Komodo perspective (its another compose project). So that should behttp://authentik-authentik_server-1:9000.This all depends on your exact compose files and how you deployed both Authentik and Komodo. If you still are having trouble with this feel free to share your compose files and information about how these are deployed, and I can try to help.
@mikemilligram commented on GitHub (Nov 2, 2024):
I deployed it in swarm mode.
In swarm mode, the names of the containers are
stackname_servicename, which in my case isauthentik_server.They're all in the same docker network, the containers are able to ping each other with their respective container names without problem.
Which is why I'm confused that
KOMODO_OIDC_PROVIDER=http://10.0.1.x:9000/application/o/komodo/works, butKOMODO_OIDC_PROVIDER=http://authentik_server:9000/application/o/komodo/doesn't.compose file for komodo:
compose file for authentik:
@mbecker20 commented on GitHub (Nov 2, 2024):
Good you know the direct container IP works. I think this does narrow things down to a networking issue. I haven't tried swarm so I'm not too familiar with the networking there. But maybe you shouldn't be pointing to any
container_name:PORT, but rather to your Swarms node : PORT, just from reading here: https://docs.docker.com/engine/swarm/stack-deploy/#deploy-the-stack-to-the-swarm:You can also try
docker psto find the exact container name for authentik, not sure if you did that but the container name may not be the swarm service nameauthentik_server. Or it may still be postfixed with number you didn't notice, likeauthentik_server_1(at least compose will definitely do this)@mbecker20 commented on GitHub (Nov 2, 2024):
Btw I've tested with standard docker compose, Authentik and Komodo in seperate compose projects with a shared network, and using
http:://authentik-server-1:9000, this works.@mikemilligram commented on GitHub (Nov 2, 2024):
This only works when the port is exposed, but I want to route the traffic through the docker network, not outside of it.
In any case, this is how I do it with all of my services and it works everywhere except for Komodo. I'm not sure what the issue could be, but for now I'll be using the IP workaround. Thanks so much for your help!