Closed adamzvolanek closed 2 years ago
Is the worker container running as root? This is currently required to make the docker integration via socket work, since the permission UIDs on the socket are not static so they can vary system by system
How do you verify if the worker is running as root?
After a few worker and server authentik for let restarts and reverting some environment variables I added from the docs to the Unraid template provided. It connects now.
I still wonder if outposts would work correctly without the local docker outpost integration or not.
How do you verify if the worker is running as root?
In Unraid it will show as a privileged toggle.
Going to re-open this. Both authentik-worker and authentik are running 'privileged' or as root, and it still shows that outpost integrations are unhealthy. Configuration from above has not changed, only had to stop my dockers for another item.
running as privileged is not the same as running with the root user
privileged gives the container abilities (to run docker in docker or use devices), while the worker needs to run with the root user to be able to adjust the authentik user's group membership to access the docker socket
running as privileged is not the same as running with the root user
My docker run command is issued as root unless Unraid is some additional user changes behind the scenes im not familiar with: ‘ root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='authentik' --net='<>' -e TZ="America/Chicago" -e HOST_OS="Unraid" -e 'AUTHENTIK_REDISHOST'='<>' -e 'AUTHENTIK_POSTGRESQL__HOST'='<>' -e 'AUTHENTIK_POSTGRESQLUSER'='<>' -e 'AUTHENTIK_POSTGRESQLNAME'='<>' -e 'AUTHENTIK_POSTGRESQLPASSWORD'<>' -e 'AUTHENTIK_ERROR_REPORTINGENABLED'='true' -e 'GEOIPUPDATE_ACCOUNT_ID'='' -e 'GEOIPUPDATE_LICENSE_KEY'='' -e 'AUTHENTIK_AUTHENTIKGEOIP'='/geoip/GeoLite2-City.mmdb' -e 'AUTHENTIK_SECRET_KEY'='<>' -e 'AUTHENTIK_REDIS__PASSWORD'='<>' -p '9000:9000/tcp' -p '9443:9443/tcp' -v '/mnt/user/appdata/authentik/geoip':'/geoip':'rw' -v '/mnt/user/appdata/authentik/templates/':'/templates':'rw' -v '/var/run/docker.sock':'/var/run/docker.sock':'ro' -v '/mnt/user/appdata/authentik/media/':'/media':'rw' 'beryju/authentik:latest' ‘
That is also not the same, the missing flag in that command is -u root
(and that is also only supposed to be set for the worker container)
Added the -u root
flag to the worker as an extra parameter and seems to work again. I shut down my docker service and restarted, it seems to have stuck.
I had the same problem. The outpost ldap container of authentik was blocking on starting state and then ending on unhealthy without working. I managed to solve the problem by putting a new Let's Encrypt certificate. I have no idea if there is a link but everything works since this manipulation.
Hi there.
sorry for reopening the issue. But I am fighting with the same problem, but on docker-compose enviroment running on Debian. The status is reported as unhealthy, but I checked and the worker has the user root selected in docker-compose - I use the provided docker-compose file with just minor changes (like network).
Here is my docker compose:
---
version: "3.4"
services:
postgresql:
image: docker.io/library/postgres:12-alpine
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"]
start_period: 20s
interval: 30s
retries: 5
timeout: 5s
volumes:
- database:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: ${PG_PASS:?database password required}
POSTGRES_USER: ${PG_USER:-authentik}
POSTGRES_DB: ${PG_DB:-authentik}
env_file:
- .env
networks:
authentik:
redis:
image: docker.io/library/redis:alpine
command: --save 60 1 --loglevel warning
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
start_period: 20s
interval: 30s
retries: 5
timeout: 3s
volumes:
- redis:/data
networks:
authentik:
server:
image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2023.5.4}
restart: unless-stopped
command: server
environment:
AUTHENTIK_REDIS__HOST: redis
AUTHENTIK_POSTGRESQL__HOST: postgresql
AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
volumes:
- ./media:/media
- ./custom-templates:/templates
env_file:
- .env
ports:
networks:
authentik:
external:
worker:
image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2023.5.4}
restart: unless-stopped
command: worker
environment:
AUTHENTIK_REDIS__HOST: redis
AUTHENTIK_POSTGRESQL__HOST: postgresql
AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
user: root
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- ./media:/media
- ./certs:/certs
- ./custom-templates:/templates
env_file:
- .env
networks:
authentik:
volumes:
database:
driver: local
redis:
driver: local
networks:
authentik:
driver: bridge
ipam:
config:
- subnet: 174.24.0.0/24
gateway: 174.24.0.1
external:
name: proxy-link
And here is how it looks in Authentik:
PS: I am running portatiner on the host and that has sucessfully connectec to the docker.sock. I tried to disable Portainer just be sure that those two are not blocking each other, but even stopping its containers completely and restarting Authentik ones did not solve the issue.
PPS: I know new version was released today, I just prepared the post yesterday with old version in dc compose :)
Thank you!
I unchecked the local switch and all is well
Having the same issues as everyone above. Have an Ubuntu Linux running Docker and Portainer. My worker is running both in privileged mode and as root but still can't get the docker integration to work.
I also had to UNCHECK (or toggle OFF) the "Local" switch for this to work properly. Even though Authentik is installed on the local machine with most of the other integrations being used by Authentik, /var/run/docker.sock is in my compose file, and the Authentik worker is running as root (user: root). Maybe there's some misunderstanding of the "Local" switch...
Also, the first time I installed Authentik I thought this Docker integration was there by default. I had to start over at one point and after the next install the Docker integration was absent and had to be added manually. It's possible that I installed an older version initially and a new version the second time, which may have contributed to the behavior, and my confusion.
Describe the bug My Outpost Integration shows unhealthy with the docker service-connection setup.
To Reproduce Steps to reproduce the behavior:
Expected behavior I hoped to have a healthy state of outpost integrations to mitigate? my redirect issue. (https://github.com/goauthentik/authentik/issues/3415)
Screenshots
Logs
"event": "Task failure", "exc": "DockerException(\"Error while fetching server API version: ('Connection aborted.', PermissionError(13, 'Permission denied'))\")", "level": "warning", "logger": "authentik.root.celery", "pid": 19332, "request_id": "task-5a6e3fd539f244efa6788a1e0f652336", "timestamp": "2022-08-13T22:33:05.906402"}
{"event": "Task authentik.outposts.tasks.outpost_service_connection_state[5a6e3fd5-39f2-44ef-a678-8a1e0f652336] raised unexpected: DockerException(\"Error while fetching server API version: ('Connection aborted.', PermissionError(13, 'Permission denied'))\")", "exc_info": ["<class 'docker.errors.DockerException'>", "DockerException(\"Error while fetching server API version: ('Connection aborted.', PermissionError(13, 'Permission denied'))\")", "<billiard.einfo.Traceback object at 0x14665b5a4850>"], "level": "error", "logger": "celery.app.trace", "timestamp": 1660429985.906865}
{"event": "Task finished", "level": "info", "logger": "authentik.root.celery", "pid": 19332, "request_id": "task-5a6e3fd539f244efa6788a1e0f652336", "state": "FAILURE", "task_id": "5a6e3fd5-39f2-44ef-a678-8a1e0f652336", "task_name": "outpost_service_connection_state", "timestamp": "2022-08-13T22:33:05.907043"}
Version and Deployment (please complete the following information):