Authentik на Ubuntu 24.04: пошаговая установка

MAATRIX

Единый вход для десятка внутренних сервисов — это не роскошь, а вопрос гигиены: если у Grafana, GitLab и внутренней вики разные пароли, рано или поздно кто-то заведёт «Passw0rd123» и забудет включить 2FA. Keycloak решает эту задачу, но у него тяжёлый Java-стек и интерфейс, в котором легко потеряться. Authentik делает то же самое проще: понятный UI, гибкий редактор потоков авторизации (flows) и развёртывание одним docker-compose. Ниже — установка с нуля на чистом Ubuntu 24.04, с рабочим конфигом и первым защищённым приложением.

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

Authentik — self-hosted IdP (identity provider) с поддержкой OAuth2/OIDC, SAML, LDAP и proxy-аутентификации для сервисов, которые вообще не умеют в SSO. Ключевая идея — «flows»: вместо жёстко зашитой логики входа вы собираете сценарий авторизации из блоков (проверка пароля, TOTP, согласие пользователя, редирект) визуально, через веб-интерфейс.

Практическая разница с Keycloak:

• Ресурсы. Authentik на Python/Go + PostgreSQL + Redis стартует комфортно на 2 vCPU / 4 ГБ RAM. Keycloak на JVM обычно просит от 4 ГБ и дольше поднимается.
• UI. В Authentik настройка провайдера — это пара форм с понятными подписями. В Keycloak та же задача требует знания их внутренней терминологии (realm, client scope, mapper).
• Proxy-аутентификация. Authentik из коробки умеет вешать прокси перед сервисом, который вообще не поддерживает OAuth — например, перед внутренней панелью мониторинга без встроенной авторизации. Это закрывает много «серых» сервисов одним слоем.
• Зрелость SAML. Если у вас корпоративный SSO с жёсткими требованиями к SAML (например, интеграция с Microsoft-инфраструктурой), у Keycloak опыта в этой части больше — он старше и обкатан на крупных внедрениях.

Если вам нужен единый вход для self-hosted сервисов (Grafana, Nextcloud, GitLab, внутренние дашборды) и не критична экзотика SAML — Authentik закроет задачу быстрее и с меньшей административной нагрузкой.

Требования к серверу и подготовка Ubuntu 24.04

Минимально Authentik требует немного, но продакшен-инстанс с несколькими приложениями и активным логированием стоит закладывать с запасом:

Для боевой инсталляции, которая будет аутентифицировать пользователей десятка сервисов, разумно взять VPS с 4 ГБ RAM — под PostgreSQL, Redis и сам Authentik с запасом на пиковые нагрузки при логине. Арендовать такой сервер можно в каталоге VPS maatrix.io — доступны локации RU/US/UK, оплата картой или криптовалютой.

Подготовка системы — обновление и базовые пакеты:

apt update && apt upgrade -y
apt install -y curl wget git ca-certificates gnupg apache2-utils

Проверьте, что домен для Authentik (например, sso.ваш-домен.ru) уже указывает на IP сервера — записи A/AAAA понадобятся на шаге с SSL. Если домен ещё не настроен, разберитесь с DNS отдельно — есть подробный разбор настройки домена и DNS с нуля на Ubuntu 24.04.

Открытые порты на этом этапе — только 80 и 443 (веб) и 22 (SSH). Порт 9000, на котором Authentik слушает по умолчанию, наружу светить не будем — он закроется за reverse-proxy.

Установка Docker Compose и запуск Authentik

Authentik официально распространяется только как набор Docker-образов — устанавливать его «в систему» нет смысла, вся логика собрана в docker-compose.yml с сервисами server, worker, PostgreSQL и Redis.

Ставим Docker по официальному репозиторию:

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  tee /etc/apt/sources.list.d/docker.list > /dev/null

apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

systemctl enable --now docker
docker --version

Если Docker Compose нужен отдельно, весь процесс пошагово разобран в статье про установку Docker Compose для продакшена на Ubuntu 24.04.

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

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

Генерируем .env с паролем базы и секретным ключом — их нельзя оставлять пустыми или брать «для теста»:

cat <<'EOF' > .env
PG_PASS=CHANGE_ME
AUTHENTIK_SECRET_KEY=CHANGE_ME
AUTHENTIK_ERROR_REPORTING__ENABLED=false
EOF

sed -i "s/PG_PASS=CHANGE_ME/PG_PASS=$(openssl rand -base64 36 | tr -d '\n=+/')/" .env
sed -i "s/AUTHENTIK_SECRET_KEY=CHANGE_ME/AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')/" .env

Перед запуском откройте docker-compose.yml и проверьте тег образа в строке image: ghcr.io/goauthentik/server:... — на странице релизов проекта (goauthentik.io/docs/releases) актуальную стабильную версию стоит уточнять на момент установки, а не полагаться на :latest в продакшене: фиксация конкретного тега убережёт от неожиданного апгрейда при пересборке контейнеров.

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

docker compose pull
docker compose up -d
docker compose ps

Первый старт занимает пару минут — server ждёт, пока PostgreSQL и Redis станут healthy, затем накатывает миграции самостоятельно. Смотрите логи, если что-то не поднимается:

docker compose logs -f server

Первоначальная настройка: мастер, домен, почта

По умолчанию Authentik слушает на портах 9000 (HTTP) и 9443 (HTTPS) внутри контейнера, которые проброшены наружу теми же номерами. Пока reverse-proxy не настроен, зайдите напрямую через IP сервера:

http://IP_СЕРВЕРА:9000/if/flow/initial-setup/

Мастер начальной настройки запросит:

• email и пароль для встроенного администратора akadmin;
• (опционально) параметры SMTP — без них Authentik всё равно работает, но не сможет отправлять письма для сброса пароля и уведомлений, так что для боевого инстанса SMTP стоит настроить сразу.

После завершения мастера откроется админ-панель (/if/admin/). Здесь стоит сразу заглянуть в:

• System → Settings — базовые параметры, включая часовой пояс и глобальный брендинг;
• Directory → Users — здесь виден единственный пользователь akadmin; для повседневной работы заведите отдельного администратора и не логиньтесь под встроенным аккаунтом постоянно;
• Events → Logs — журнал входов и ошибок, полезен для диагностики на следующих шагах.

Если вы уже настраивали PostgreSQL на других серверах и хотите понимать, что происходит «под капотом» compose-стека, пригодится общий разбор установки PostgreSQL на Ubuntu 24.04 — Authentik использует ту же СУБД без экзотических настроек.

SSL и reverse-proxy: закрываем Authentik доменом с HTTPS

Аутентификационный сервер, торчащий наружу по HTTP на нестандартном порту — плохая идея даже для внутреннего использования: логин и пароль должны идти только по HTTPS, а адрес — быть человекочитаемым (sso.ваш-домен.ru, а не IP:9000).

Проще всего закрыть Authentik через Caddy — он сам получает и продлевает сертификат Let's Encrypt без ручной возни с certbot. Если Caddy ещё не стоит, разверните его по инструкции Caddy с авто-SSL на Ubuntu 24.04, затем добавьте блок:

sso.ваш-домен.ru {
    reverse_proxy localhost:9000
}

systemctl reload caddy

Caddy сам выпустит сертификат при первом обращении к домену — убедитесь, что DNS-запись A уже указывает на сервер, иначе выпуск сертификата не пройдёт.

После этого закройте порт 9000 от внешнего доступа — либо уберите проброс порта в docker-compose.yml (замените "9000:9000" на "127.0.0.1:9000:9000"), либо ограничьте порт файрволом. Базовые правила ufw разобраны в статье про настройку файрвола UFW на Ubuntu 24.04 — для Authentik достаточно разрешить 80/443 и SSH, всё остальное закрыть.

Если вы уже используете Traefik как основной reverse-proxy для докер-стека, логика та же — навешиваете лейблы на сервис server в compose-файле вместо отдельного блока Caddy; конфигурация Traefik под Docker разобрана в статье про Traefik как reverse-proxy для Docker.

Первое приложение: Proxy Provider для сервиса без своего логина

Самый частый сценарий — повесить Authentik перед сервисом, у которого либо нет встроенной авторизации, либо она слабая (например, внутренняя панель без 2FA). Делается это через Proxy Provider в режиме forward auth.

1. Applications → Providers → Create. Тип — Proxy Provider, режим — Forward auth (single application). Указываете внешний URL приложения, которое защищаете (например, https://dashboard.внутр-домен.ru).
2. Applications → Applications → Create. Привязываете созданный провайдер, задаёте slug и иконку — это то, что увидит пользователь на стартовой странице Authentik.
3. Outposts → создаём/используете embedded outpost — это компонент, который физически перехватывает трафик и проверяет сессию. Для одного-двух приложений хватает встроенного (embedded) outpost, отдельный контейнер поднимать не нужно.
4. На стороне reverse-proxy защищаемого сервиса добавляете forward-auth директиву, указывающую на Authentik outpost — для Caddy это модуль forward_auth, для Traefik — middleware forwardAuth. Пример для Caddy:

dashboard.внутр-домен.ru {
    forward_auth localhost:9000 {
        uri /outpost.goauthentik.io/auth/caddy
        copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Email
    }
    reverse_proxy localhost:8080
}

После этого при заходе на dashboard.внутр-домен.ru пользователя редиректит на форму входа Authentik, а после успешной авторизации — обратно в приложение с уже проставленной сессией.

Для сервисов, которые умеют OAuth2/OIDC нативно (GitLab, Grafana, Nextcloud) — используйте OAuth2/OpenID Provider вместо Proxy Provider: это честная интеграция без прослойки forward-auth, с полноценным logout и профилем пользователя. В каждом сервисе процесс похож: создаёте provider в Authentik → копируете Client ID/Secret → вставляете в настройки внешнего SSO самого сервиса.

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