Как установить и настроить Authentik на VPS

MAATRIX

Когда у вас на сервере живёт пять-десять сервисов — Grafana, Gitea, Nextcloud, Portainer, — у каждого свой логин и пароль, свой список пользователей, и нигде нет единой политики двухфакторной аутентификации. Authentik закрывает эту проблему: это self-hosted SSO-провайдер с современным веб-интерфейсом и визуальным редактором сценариев входа, который проще в освоении, чем Keycloak, но не уступает ему в гибкости. Ниже — установка на VPS через Docker Compose, настройка первого провайдера и защита сервисов, у которых нет своей поддержки OIDC.

Что такое Authentik и когда он лучше Keycloak

Authentik — открытый identity provider на Python/Go, который умеет OAuth2/OIDC, SAML2, LDAP (через outpost) и SCIM-провижининг. Ключевая особенность — flow-редактор: логика входа собирается из отдельных «стадий» (идентификация, пароль, TOTP, согласие, редирект) как из блоков, и каждую стадию можно обвязать политиками — по группе, IP, гео, времени суток. Это нагляднее, чем XML-подобные Authentication Flows в Keycloak.

Где Authentik действительно удобнее:

• Инфраструктура и так строится на Docker — Authentik сам разворачивается через compose, без отдельного JVM-процесса и тюнинга heap.
• Нужен единый портал приложений («Applications») с брендированием, а не только техническая аутентификация.
• Команда небольшая, и никто не хочет разбираться в realm/client/scope модели Keycloak ради пяти внутренних сервисов.

Где Keycloak всё ещё сильнее: крупные корпоративные SAML-интеграции с готовыми коннекторами под конкретные вендоры, более зрелая документация и комьюнити, федерация с Active Directory «из коробки» на уровне, привычном enterprise-админам. Для домашней лаборатории и небольшой команды Authentik обычно выигрывает по скорости настройки.

Требования к серверу

Authentik — это как минимум три контейнера: сервер, воркер, PostgreSQL и Redis (Redis и Postgres часто разворачивают тем же compose-файлом). Даже под небольшую нагрузку закладывайте с запасом:

Также понадобится:

• Установленный Docker Engine с плагином docker compose (v2).
• Доменное имя с A-записью на IP сервера — например, auth.example.com. Без валидного домена OAuth2/OIDC редиректы работать не будут, самоподписанный сертификат тут не вариант для продакшена.
• Открытые порты 80/443 для внешнего трафика — сам Authentik слушает 9000 (HTTP) и 9443 (HTTPS) только для внутреннего использования, наружу его лучше не светить напрямую.

Установка Authentik через Docker Compose

Создайте рабочую директорию и скачайте официальный compose-файл:

mkdir -p /opt/authentik && cd /opt/authentik
curl -o docker-compose.yml https://goauthentik.io/docker-compose.yml

Сгенерируйте .env со случайными паролем БД и секретным ключом — их нельзя оставлять пустыми или брать из примеров в интернете:

echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env

Проверьте актуальный список переменных в скачанном .env.example (в разных версиях набор опций слегка отличается) и при необходимости добавьте:

echo "AUTHENTIK_ERROR_REPORTING__ENABLED=false" >> .env

Поднимите стек:

docker compose pull
docker compose up -d
docker compose ps

Дождитесь, пока authentik-server и authentik-worker перейдут в статус healthy — при первом запуске накатываются миграции БД, это может занять минуту-две. Логи стоит посмотреть отдельно:

docker compose logs -f server

Первый вход и базовая настройка

Пока фронта с SSL нет, зайдите напрямую по IP на порт 9443 (сертификат будет самоподписанным — это ожидаемо и временно):

https://<IP-сервера>:9443/if/flow/initial-setup/

Эта страница работает только до момента, пока не создан первый администратор — задайте email и пароль для akadmin. После входа откроется административный интерфейс /if/admin/, где стоит освоиться с разделами:

• Applications — список приложений, которые видит пользователь на портале.
• Providers — техническая конфигурация протокола (OAuth2/OIDC, SAML, Proxy, LDAP) для каждого приложения.
• Outposts — выносные компоненты, которые обслуживают forward auth и LDAP вне основного контейнера.
• Flows & Stages — тот самый визуальный редактор сценариев входа.
• Events — журнал аудита: кто, когда и откуда логинился.

Создайте первое приложение для примера — скажем, Grafana с OIDC. В Providers создаёте OAuth2/OIDC Provider, указываете redirect URI вида https://grafana.example.com/login/generic_oauth, тип клиента confidential, нужные scopes (openid profile email). В Applications связываете провайдера с приложением и получаете Client ID и Client Secret для настройки на стороне Grafana.

Reverse proxy и SSL-сертификат

Отдавать Authentik наружу напрямую через 9443 — плохая практика: не будет нормального HTTP/2, логирования на уровне веб-сервера и единой точки для сертификатов. Поставьте перед ним nginx или Caddy на 80/443, если ещё не настраивали reverse proxy — есть отдельный разбор, как установить nginx как reverse proxy на VPS.

Минимальный server-блок nginx с проксированием на внутренний HTTP-порт Authentik (важно пробросить заголовки для WebSocket — часть UI использует live-обновления):

server {
    listen 443 ssl http2;
    server_name auth.example.com;

    ssl_certificate     /etc/letsencrypt/live/auth.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/auth.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Сертификат получите через certbot — процесс подробно разобран в статье про Let's Encrypt SSL на VPS. Если вам ближе автоматический SSL без отдельного certbot-шага, вариант с Caddy на VPS для одного домена настраивается буквально в несколько строк конфига.

После того как домен заработал по HTTPS, зайдите в System → Settings и убедитесь, что базовый URL (branding domain) в настройках совпадает с https://auth.example.com — иначе redirect URI в провайдерах будут указывать на неправильный адрес и OIDC-логин будет падать с ошибкой mismatch.

Flow-редактор и защита сервисов через forward auth

Flow-редактор — это то, ради чего многие переходят с Keycloak. Откройте Flows & Stages → default-authentication-flow (или создайте копию, чтобы не трогать системный) и посмотрите на цепочку: Identification Stage → Password Stage → (опционально) MFA Stage. Чтобы обязать 2FA для группы администраторов:

1. Создайте Stage типа Authenticator Validation (TOTP).
2. Добавьте её в цепочку после Password Stage.
3. На биндинге стадии задайте Policy — условие «пользователь состоит в группе admins» через Policy Bindings, чтобы обычные пользователи не спотыкались о лишний шаг, если вы ещё не готовы включать 2FA для всех.

Для сервисов, у которых нет собственной поддержки OIDC/SAML (например, Portainer в базовой версии или внутренние дашборды без auth-модуля), используется forward auth: Authentik выступает прослойкой, которая проверяет сессию перед тем, как nginx пропустит запрос дальше. Схема:

1. В Providers создаёте Proxy Provider в режиме Forward auth (single application), указываете внешний URL защищаемого сервиса.
2. В Outposts создаёте (или используете встроенный) Proxy Outpost и привязываете к нему провайдера — Authentik сам поднимет вспомогательный контейнер authentik-proxy.
3. В nginx перед защищаемым сервисом добавляете auth_request на этот outpost:

location /outpost.goauthentik.io/ {
    proxy_pass http://authentik-proxy:9000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location / {
    auth_request /outpost.goauthentik.io/auth/nginx;
    error_page 401 = @goauthentik_proxy_signin;
    proxy_pass http://portainer:9000;
}

Точные пути и имена сервисов проверьте в актуальной документации Authentik под вашу версию — синтаксис auth_request блока периодически уточняется в официальных примерах. Для легаси-приложений, которые понимают только LDAP-бинд, есть отдельный тип outpost — LDAP, он экспонирует пользователей Authentik как обычный LDAP-каталог.

Резервное копирование и обновление

База данных PostgreSQL — единственное, что критично бэкапить: в ней хранятся пользователи, провайдеры, flow и секреты приложений. Простой дамп из контейнера:

docker compose exec postgresql pg_dumpall -U authentik > authentik-backup-$(date +%F).sql

Складывайте бэкапы за пределами сервера — общие принципы ротации и автоматизации разобраны в статье про бэкап Docker volume на VPS, подход применим и к томам Authentik (media с логотипами и брендингом, если вы их меняли).

Обновление — стандартное для compose-стека:

cd /opt/authentik
docker compose pull
docker compose up -d

Перед мажорным апгрейдом (смена первой цифры версии) обязательно смотрите changelog проекта — иногда там есть шаги миграции, которые нужно выполнить руками до up -d, а не после.

Из базовой защиты сервера: держите SSH только по ключу, ограничьте firewall (ufw allow 80,443, SSH — по необходимости с ограничением по IP), поставьте fail2ban перед nginx — как это сделать, описано в статье про fail2ban для nginx. Отдельно: AUTHENTIK_SECRET_KEY из .env — не просто пароль, его ротация обнуляет все активные сессии, так что меняйте его осознанно, а не «на всякий случай».

Частые вопросы