fails to start the container altogether, with the error message
thread 'tokio-runtime-worker' panicked at bin/core/src/auth/oidc/client.rs:66:4:
called `Result::unwrap()` on an `Err` value: Failed to init default OIDC client
Caused by:
0: Failed to get OIDC /.well-known/openid-configuration
1: Server returned invalid response: HTTP status code 404 Not Found at http://authentik_server:9000/application/o/komodo/.well-known/openid-configuration
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:
thread 'tokio-runtime-worker' panicked at bin/core/src/auth/oidc/client.rs:66:4:
called `Result::unwrap()` on an `Err` value: Failed to init default OIDC client
Caused by:
0: Failed to get OIDC /.well-known/openid-configuration
1: Request failed
2: request failed
3: error sending request for url (https://authentik.mydomain.com/application/o/komodo/.well-known/openid-configuration): error trying to connect: tcp connect error: Connection timed out (os error 110)
4: error trying to connect: tcp connect error: Connection timed out (os error 110)
5: tcp connect error: Connection timed out (os error 110)
6: Connection timed out (os error 110)
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.
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
```
KOMODO_OIDC_PROVIDER=http://authentik_server:9000/application/o/komodo/
KOMODO_OIDC_REDIRECT=https://authentik.mydomain.com/application/o/komodo/
```
fails to start the container altogether, with the error message
```
thread 'tokio-runtime-worker' panicked at bin/core/src/auth/oidc/client.rs:66:4:
called `Result::unwrap()` on an `Err` value: Failed to init default OIDC client
Caused by:
0: Failed to get OIDC /.well-known/openid-configuration
1: Server returned invalid response: HTTP status code 404 Not Found at http://authentik_server:9000/application/o/komodo/.well-known/openid-configuration
```
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:
```
KOMODO_OIDC_PROVIDER=http://10.0.1.3:9000/application/o/komodo/
KOMODO_OIDC_REDIRECT=https://authentik.mydomain.com/application/o/komodo/
```
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:
```
thread 'tokio-runtime-worker' panicked at bin/core/src/auth/oidc/client.rs:66:4:
called `Result::unwrap()` on an `Err` value: Failed to init default OIDC client
Caused by:
0: Failed to get OIDC /.well-known/openid-configuration
1: Request failed
2: request failed
3: error sending request for url (https://authentik.mydomain.com/application/o/komodo/.well-known/openid-configuration): error trying to connect: tcp connect error: Connection timed out (os error 110)
4: error trying to connect: tcp connect error: Connection timed out (os error 110)
5: tcp connect error: Connection timed out (os error 110)
6: Connection timed out (os error 110)
```
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.
I anticipated this situation but it does seem the KOMODO_OIDC_REDIRECT implementation doesn't work to fix it. Thanks for bringing to my attention, I'm taking a look.
<!-- gh-comment-id:2451198025 -->
@mbecker20 commented on GitHub (Nov 1, 2024):
I anticipated this situation but it does seem the `KOMODO_OIDC_REDIRECT` implementation doesn't work to fix it. Thanks for bringing to my attention, I'm taking a look.
I'm still having the issue with the name not resolving, though.
Running curl https://authentik.mydomain.com/application/o/komodo/.well-known/openid-configuration from inside the core container does not work and eventually times out. curl https://authentik_server:9000/application/o/komodo/.well-known/openid-configuration resolves, 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:
curl http://authentik_server:9000/application/o/komodo/.well-known/openid-configuration -vvv
* Trying 10.0.1.102:9000...
* Connected to authentik_server (10.0.1.102) port 9000 (#0)
> GET /application/o/komodo/.well-known/openid-configuration HTTP/1.1
> Host: authentik_server:9000
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=utf-8
< Date: Fri, 01 Nov 2024 14:37:14 GMT
< Vary: Accept-Encoding
< X-Powered-By: authentik
< Transfer-Encoding: chunked
<
* Connection #0 to host authentik_server left intact
<!-- gh-comment-id:2452001883 -->
@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-configuration` from inside the core container does not work and eventually times out.
`curl https://authentik_server:9000/application/o/komodo/.well-known/openid-configuration` resolves, 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:
```
curl http://authentik_server:9000/application/o/komodo/.well-known/openid-configuration -vvv
* Trying 10.0.1.102:9000...
* Connected to authentik_server (10.0.1.102) port 9000 (#0)
> GET /application/o/komodo/.well-known/openid-configuration HTTP/1.1
> Host: authentik_server:9000
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=utf-8
< Date: Fri, 01 Nov 2024 14:37:14 GMT
< Vary: Accept-Encoding
< X-Powered-By: authentik
< Transfer-Encoding: chunked
<
* Connection #0 to host authentik_server left intact
```
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.
<!-- gh-comment-id:2452459461 -->
@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.
<!-- gh-comment-id:2452462323 -->
@mbecker20 commented on GitHub (Nov 1, 2024):
The full config on Komodo side should be:
```
KOMODO_OIDC_PROVIDER=http://authentik_server:9000/application/o/komodo/
KOMODO_OIDC_REDIRECT_HOST=https://authentik.mydomain.com
KOMODO_OIDC_CLIENT_ID=...
KOMODO_OIDC_CLIENT_SECRET=...
```
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.
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.
<!-- gh-comment-id:2452494169 -->
@mikemilligram 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.
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.
> The full config on Komodo side should be:
>
> ```
> KOMODO_OIDC_PROVIDER=http://authentik_server:9000/application/o/komodo/
> KOMODO_OIDC_REDIRECT_HOST=https://authentik.mydomain.com
> KOMODO_OIDC_CLIENT_ID=...
> KOMODO_OIDC_CLIENT_SECRET=...
> ```
Using
```
KOMODO_OIDC_PROVIDER=http://10.0.1.x/application/o/komodo/
KOMODO_OIDC_REDIRECT_HOST=https://authentik.mydomain.com
KOMODO_OIDC_CLIENT_ID=...
KOMODO_OIDC_CLIENT_SECRET=...
```
everything works, but replacing the first line with
```
KOMODO_OIDC_PROVIDER=http://authentik_server:9000/application/o/komodo/
```
won't even let the container launch.
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_server in your Authentik compose file, if they aren't part of the same compose project, the container name will be something like authentik-authentik_server-1 from the Komodo perspective (its another compose project). So that should be http://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.
<!-- gh-comment-id:2452718010 -->
@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_server` in your Authentik compose file, if they aren't part of the same compose project, the container name will be something like `authentik-authentik_server-1` from the Komodo perspective (its another compose project). So that should be `http://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.
I deployed it in swarm mode.
In swarm mode, the names of the containers are stackname_servicename, which in my case is authentik_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, but KOMODO_OIDC_PROVIDER=http://authentik_server:9000/application/o/komodo/ doesn't.
<!-- gh-comment-id:2453025370 -->
@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 is `authentik_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, but `KOMODO_OIDC_PROVIDER=http://authentik_server:9000/application/o/komodo/` doesn't.
compose file for komodo:
```
services:
periphery:
networks:
- komodo
...
ferretdb:
networks:
- komodo
...
postgres:
networks:
- komodo
...
core:
image: ghcr.io/mbecker20/komodo:latest
deploy:
replicas: 1
labels:
- komodo.skip
logging:
driver: ${COMPOSE_LOGGING_DRIVER:-local}
env_file: .env
environment:
...
volumes:
...
networks:
- proxy
- komodo
networks:
komodo:
name: komodo_net
proxy:
external: true
```
compose file for authentik:
```
services:
postgresql:
networks:
- authentik
...
redis:
networks:
- authentik
...
worker:
networks:
- authentik
...
server:
image: ghcr.io/goauthentik/server:${AUTHENTIK_TAG}
deploy:
replicas: 1
environment:
...
volumes:
...
env_file:
- .env
networks:
- authentik
- proxy
...
networks:
authentik:
name: authentik_net
proxy:
external: true
```
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:
With Docker's built-in routing mesh, you can access any node in the swarm on port 8000 and get routed to the app
You can also try docker ps to find the exact container name for authentik, not sure if you did that but the container name may not be the swarm service name authentik_server. Or it may still be postfixed with number you didn't notice, like authentik_server_1 (at least compose will definitely do this)
<!-- gh-comment-id:2453062654 -->
@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:
```
With Docker's built-in routing mesh, you can access any node in the swarm on port 8000 and get routed to the app
```
You can also try `docker ps` to find the exact container name for authentik, not sure if you did that but the container name may not be the swarm service name `authentik_server`. Or it may still be postfixed with number you didn't notice, like `authentik_server_1` (at least compose will definitely do this)
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.
<!-- gh-comment-id:2453063764 -->
@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.
With Docker's built-in routing mesh, you can access any node in the swarm on port 8000 and get routed to the app
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!
<!-- gh-comment-id:2453119578 -->
@mikemilligram commented on GitHub (Nov 2, 2024):
> ```
> With Docker's built-in routing mesh, you can access any node in the swarm on port 8000 and get routed to the app
> ```
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!
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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!