Authentik для начинающих. Часть 10. Финальная архитектура (Production Blueprint)

Версия курса: Authentik 2025.12.x

Что мы делаем в этой части

Это финальная глава курса.

Здесь мы:

собираем всю систему Authentik в реальную архитектуру для твоих сервисов

Не теорию, не интерфейс — а готовую модель, как это должно работать в жизни.

Что у тебя уже есть

Ты уже разобрал:

• Users / Groups
• Authentication / Authorization
• Flows / Stages
• Policies
• OIDC (OAuth2)
• Proxy Provider
• Sources (Google / LDAP)
• Outposts

Теперь всё это нужно объединить.

Общая идея системы

Authentik становится центральным узлом всей инфраструктуры.

Финальная архитектура

                    INTERNET
                        ↓
               Reverse Proxy (Nginx / Traefik)
                        ↓
                  Authentik Outpost
                        ↓
                 Authentik Core (IdP)
                        ↓
        ┌──────────────┼──────────────┐
        │              │              │
   OIDC Apps      Proxy Apps      External Logins
        │              │              │
 ┌──────┼──────┐   ┌───┼────┐     ┌───┼────┐
 │      │      │   │        │     │        │
Nextcloud Immich Stocktorg Gramps Google LDAP

Разделение системы на уровни

Уровень 1. Пользователи

Users + Groups + Attributes

Это “кто есть кто”.

Примеры групп:

• Family
• Admins
• Board
• Accountants
• CooperativeMembers

Уровень 2. Логика доступа

Policies + Flows + Stages

Это “можно или нельзя”.

Примеры:

• обязательно 2FA
• только Admins
• только из офиса
• только в рабочее время

Уровень 3. Подключение сервисов

Providers (OIDC / Proxy)

Это “как подключить сервис”.

Примеры:

• Nextcloud OIDC
• Immich OIDC
• Stocktorg Proxy

Уровень 4. Приложения

Applications

Это “что видит пользователь”.

Реальная модель твоей системы

1. Семейная зона

Immich

Group: Family
Access: Photos, Memories
Auth: OIDC

2. Рабочая зона

Nextcloud

Group: Family + Workers
Auth: OIDC + 2FA

3. Кооператив

Groups:
- Board
- Accountants
- Members

Rules:

• Board → full access
• Accountants → financial data
• Members → limited access

4. Сайт магазина

Stocktorg

Admins only via Proxy Provider
2FA required

5. Родословная система

Gramps Web

Family group only

Единая модель безопасности

1. Идентификация

Who are you?
→ User

2. Роль

What group are you in?
→ Group

3. Проверка правил

Are you allowed?
→ Policy

4. Вход в систему

Flow + 2FA

5. Доступ к сервису

Provider + Application

Безопасная архитектура (очень важно)

Правильная схема

INTERNET
  ↓
Reverse Proxy
  ↓
Outpost (Auth check)
  ↓
Authentik Core
  ↓
Services (closed backend)

Неправильная схема

INTERNET → напрямую Nextcloud / Immich ❌

Главные принципы системы

1. Один вход

Single Sign-On (SSO)

2. Один источник прав

Groups + Policies

3. Централизованная безопасность

2FA + Flows + Policies

4. Любой сервис можно подключить

OIDC OR Proxy Provider

Как проектировать новую систему

Шаг 1

Определить группы:

• кто будет пользоваться системой

Шаг 2

Определить уровни доступа:

• кто что может видеть

Шаг 3

Выбрать способ подключения:

• OIDC (современные сервисы)
• Proxy (старые сайты)

Шаг 4

Настроить Policies:

• 2FA
• группы
• IP (если нужно)

Шаг 5

Подключить Providers

Шаг 6

Создать Applications

Типовая ошибка новичков (финальная)

❌ начинают с подключения сервисов

Правильный порядок:

1. Users
2. Groups
3. Policies
4. Flows
5. Providers
6. Applications
7. Outposts

Итог всей системы

Если собрать всё вместе:

Authentik = центр управления доступом
Outpost = исполнитель
Proxy = защита сайтов
OIDC = вход в приложения
Policies = правила
Groups = роли

Что у тебя теперь есть

Ты построил не просто “SSO систему”.

Ты построил:

централизованную систему идентификации и контроля доступа уровня небольшой компании или кооператива

Следующий шаг (если продолжать курс)

Можно развить это дальше:

• схема резервного доступа (break-glass admin)
• отказоустойчивость Authentik (HA cluster)
• интеграция с VPN (WireGuard + SSO)
• автоматическое создание пользователей из CRM
• журналирование и аудит входов
• Zero Trust модель

Authentik для начинающих. Часть 9. Outposts, Proxy, Docker и продакшн-схема всей инфраструктуры

Версия курса: Authentik 2025.12.x

Зачем нужна эта часть

До этого мы научились:

• входу пользователей (Flows)
• ролям (Groups)
• правилам доступа (Policies)
• подключению сервисов (OIDC)
• защите сайтов (Proxy Provider)
• внешним логинам (Sources)

Теперь самый важный шаг:

сделать Authentik реальным “центром безопасности” всей инфраструктуры

Что такое Outpost

Outpost (форпост) — это “исполнитель” Authentik.

Простое объяснение

Authentik решает “можно или нельзя”,
Outpost применяет это решение на реальном трафике.

Схема

User → Nginx/Traefik → Outpost → Authentik → Allow/Deny → Service

Где используется Outpost

Outpost нужен для:

• Proxy Provider
• Forward Auth
• защиты сайтов
• работы через Docker / Kubernetes

Основные типы Outpost

1. Docker Outpost (самый популярный)

Работает как контейнер.

Используется в:

• домашнем сервере
• VPS
• Docker Compose

2. Kubernetes Outpost

Для больших инфраструктур.

3. Embedded Outpost

Встроенный в систему (реже используется отдельно).

Как выглядит реальная схема (домашний сервер)

            Internet
                ↓
           Nginx / Traefik
                ↓
          Authentik Outpost
                ↓
           Authentik Core
                ↓
 ┌────────────┼────────────┐
 │            │            │
Nextcloud   Immich     Stocktorg

Что делает Outpost

Он выполняет 3 задачи:

1. Перехват запроса

User → /admin → Outpost

2. Проверка у Authentik

Is user allowed?

3. Ответ

• 200 OK → доступ разрешён
• 302 Redirect → на логин
• 403 Forbidden → отказ

Forward Auth (сердце Proxy схемы)

Как работает

User → сайт
     → Outpost спрашивает Authentik
     → Authentik отвечает
     → доступ или редирект

Docker схема (практическая)

Пример docker-compose

authentik-server
authentik-worker
authentik-postgres
authentik-redis
authentik-outpost

Важное

Outpost — это отдельный контейнер, который:

• подключается к Authentik
• обслуживает Proxy Provider

Traefik vs Nginx

Nginx

• классический вариант
• ручная конфигурация
• гибкий

Traefik

• автоматический
• удобен в Docker
• часто используется с Authentik

Пример продакшн-схемы

Твоя инфраструктура

• Stocktorg
• Nextcloud
• Immich
• Element
• Gramps Web

Архитектура

              Internet
                  ↓
            Reverse Proxy
           (Nginx / Traefik)
                  ↓
        Authentik Outpost Layer
                  ↓
            Authentik Core
                  ↓
     ┌────────────┼────────────┐
     │            │            │
  Stocktorg   Immich     Nextcloud

Proxy Provider + Outpost

Очень важно понять разницу:

Proxy Provider

• логика
• правила
• политика доступа

Outpost

• исполняет Proxy Provider
• работает с трафиком
• стоит “на линии фронта”

Где это настраивается

1. В Authentik

Providers → Proxy Provider

2. Outposts

Applications → Outposts

3. Связка

Provider → Outpost → Application

Почему Outpost обязателен

Без Outpost:

• Proxy Provider не работает
• нет перехвата трафика
• нет защиты сайтов

Практический пример: защита админки

Было:

https://stocktorg.com.ua/admin → сразу доступ

Стало:

https://stocktorg.com.ua/admin
        ↓
Authentik Outpost
        ↓
Login + 2FA
        ↓
Access granted

Ограничение по группам

Пример политики

ALLOW IF user in group Admins

Или более строго

ALLOW IF:
- Admins
- AND 2FA enabled
- AND IP = office

Ошибка №1

❌ Outpost установлен, но не привязан

Симптом:

• сайт открыт без логина

Причина:

Outpost не связан с Proxy Provider

Ошибка №2

❌ Прямой доступ к backend

Опасность:

пользователь обходит Authentik

Решение:

закрыть backend firewall’ом

Ошибка №3

❌ Несколько Outpost без смысла

Лучше:

• 1 Outpost на сегмент сети
• или на домен

Как думать правильно

Authentik — это мозг

решает кто ты и что тебе можно

Outpost — это руки

применяет решения в реальном трафике

Proxy Provider — это правила

определяют доступ

Практическое задание №9

Шаг 1

Установить Outpost (Docker)

Шаг 2

Привязать к Proxy Provider

Шаг 3

Настроить Nginx / Traefik

Шаг 4

Защитить один сервис:

• Stocktorg или тестовый сайт

Шаг 5

Проверить:

• без Authentik → нет доступа
• с Authentik → доступ есть

Что должно остаться в голове

Outpost = исполнитель Authentik
Proxy Provider = правила доступа
Reverse Proxy = точка входа в систему

Итог части 9

Теперь у тебя есть полноценная архитектура:

• централизованный вход
• контроль доступа
• защита любых сайтов
• продакшн-схема инфраструктуры

Следующая глава

Часть 10. Финальная архитектура: проектируем систему Authentik для кооператива, магазина и домашнего сервера (реальный production blueprint).

Authentik для начинающих. Часть 8. Sources — внешние пользователи (Google, LDAP, GitHub и другие)

Версия курса: Authentik 2025.12.x

Зачем нужна эта часть

До этого момента мы жили в мире, где:

• пользователи создаются вручную в Authentik
• группы тоже создаются вручную
• всё под контролем одной системы

Это хорошо для домашнего сервера.

Но в реальности часто нужно:

подключить внешние источники пользователей

Например:

• Google аккаунты
• корпоративный LDAP / Active Directory
• GitHub / GitLab логин
• внешние базы пользователей

Что такое Source (Источник)

Source (Источник) — это способ “подтянуть” пользователей извне.

Простое объяснение

Source = внешний поставщик пользователей

Пример

Google → Authentik → локальные сервисы

Где это в интерфейсе

Откройте:

Источники (Directory → Federation & Social Login)

или:

Directory → Federation & Social Login

Какие бывают Sources

1. OAuth Source (Google, GitHub, GitLab)

Самый популярный вариант.

Примеры:

• Google
• GitHub
• GitLab

2. LDAP Source

Для корпоративных сетей:

• Active Directory
• FreeIPA
• OpenLDAP

3. SAML Source

Используется в:

• крупных компаниях
• университетах
• государственных системах

4. Built-in Users (локальные)

Это те пользователи, которые мы создавали в Части 2.

Как работает Source

Поток данных

External Provider
      ↓
Authentik (Source)
      ↓
User created / linked
      ↓
Groups assigned
      ↓
Access to services

OAuth Source (самый важный для тебя)

Пример: Google login

Пользователь нажимает:

Login with Google

Что происходит:

1. Redirect в Google
2. Вход в Google
3. Google возвращает данные
4. Authentik создаёт пользователя

Что передаётся из OAuth

Обычно:

Автоматическое создание пользователей

В Authentik можно включить:

• Create user on login
• Update user attributes
• Sync groups (если настроено)

LDAP Source (корпоративный уровень)

Где используется

Office network → Active Directory → Authentik

Что даёт LDAP

• единые пользователи в компании
• централизованная авторизация Windows/Linux
• интеграция с внутренними сервисами

Пример схемы

AD (Windows Server)
      ↓
Authentik LDAP Source
      ↓
Nextcloud / internal apps

GitHub Source (для разработчиков)

Пример

GitHub login → Authentik → доступ к dev tools

Полезно для:

• CI/CD систем
• внутренних dev панелей
• тестовых сред

Как связываются внешние пользователи с группами

Очень важный момент.

Автоматическое правило

Можно задать:

IF email endswith @stocktorg.com.ua
→ add to group Admins

Или вручную

После первого входа:

• пользователь появляется в Authentik
• ты добавляешь его в нужные группы

Сценарий для твоей системы

Вариант 1: семья

Google login → Family group

Вариант 2: кооператив

email domain → CooperativeMembers

Вариант 3: админы сайта

Stocktorg

GitHub login → Admins group

Безопасность Sources

Очень важно.

Риск №1

❌ Любой Google аккаунт получает доступ

Решение

• фильтр по email домену
• ручное подтверждение пользователей
• политики групп

Риск №2

❌ Автоматическое создание админов

Решение

default group = User
not Admin

Где это настраивается в Authentik

Основной раздел

Sources → Create

Настройки:

• Provider (Google / LDAP / GitHub)
• Mapping (как создавать пользователей)
• Group assignment rules

Mapping (очень важная часть)

Mapping = правила преобразования данных.

Пример:

return {
  "username": email,
  "name": name,
}

Или:

if email.endswith("@company.com"):
    groups = ["Admins"]

Частые ошибки

Ошибка №1

❌ Подключили Google, но пользователи не создаются

Причина:

• не включен “Create users”

Ошибка №2

❌ Пользователь есть, но нет групп

Причина:

• не настроен mapping

Ошибка №3

❌ Все становятся Admin

Причина:

• неправильное правило групп

Как это выглядит в полной системе

Google / LDAP / GitHub
        ↓
        Source
        ↓
Authentik Users
        ↓
Groups (Family / Board / Admins)
        ↓
Policies
        ↓
Applications

Практическое задание №8

Шаг 1

Выбрать источник:

• Google OAuth (рекомендуется)

Шаг 2

Создать Source в Authentik

Шаг 3

Настроить:

• client id
• client secret
• redirect URI

Шаг 4

Протестировать вход

Шаг 5

Добавить правила групп:

• Family
• Users
• Admins

Что должно остаться в голове

Source = внешний источник пользователей
Mapping = правила преобразования данных
Groups = назначение прав

Итог части 8

Теперь Authentik умеет:

• локальные пользователи
• внешние логины (Google / GitHub)
• корпоративные LDAP системы
• автоматическое создание аккаунтов

Следующая глава

Часть 9. Proxy Outpost и реальные продакшн-схемы: Docker, Nginx, Traefik и защита всей инфраструктуры целиком (домашний сервер + кооператив + сайт).

Authentik для начинающих. Часть 7. Policies (Политики): умные правила доступа

Версия курса: Authentik 2025.12.x

Зачем нужна эта часть

До этого мы уже научились:

• входу (Authentication)
• ролям (Groups)
• подключению сервисов (OIDC)
• защите сайтов (Proxy Provider)

Теперь самое важное:

как заставить систему принимать решения “кому можно, а кому нельзя” автоматически

Что такое Policy

Policy (Политика) — это правило, которое возвращает:

• True (разрешить)
• False (запретить)

Простая формула

Policy = IF условие → разрешить / запретить

Где находятся политики

Откройте:

Политики (Policies)

или:

Policies

Как Policy используется в Authentik

Policy никогда не работает сама по себе.

Она подключается к:

• Flow (потоки входа)
• Provider (доступ к сервисам)
• Application (приложения)

Базовые типы Policies

1. Group Policy (самая важная)

Проверяет группу пользователя.

Пример:

IF user in group "Admins"
→ allow

В интерфейсе:

Политика группы (Group Policy)

2. Expression Policy (самая мощная)

Позволяет писать условия на Python-подобном языке.

Пример:

return "Board" in [g.name for g in user.groups.all()]

3. Time Policy

Ограничение по времени.

Пример:

Разрешить доступ только с 08:00 до 18:00

4. IP Policy

Ограничение по IP адресу.

Пример:

Разрешить только из локальной сети 192.168.1.0/24

5. Authentication Policy

Проверяет:

• вошёл ли пользователь
• прошёл ли 2FA

6. Device / MFA Policy

Проверяет:

• есть ли 2FA
• доверенное ли устройство

Как Policies объединяются

Очень важный момент:

Policies можно комбинировать

Пример логики

User должен:
- быть в группе Board
- пройти 2FA
- заходить с домашнего IP

Как это читается

ALLOW only if:
(Group = Board)
AND (2FA passed)
AND (IP allowed)

Policy Binding (привязка политики)

Политика сама по себе ничего не делает.

Её нужно “подключить”.

Где это делается

В:

• Flow
• Provider
• Application

Пример

Flow → Policies → Decision

Сложная логика (AND / OR)

AND (И)

Все условия должны быть выполнены:

Group = Board
AND 2FA = OK

OR (ИЛИ)

Достаточно одного:

Group = Admin
OR Group = Support

Практические сценарии для твоей системы

Сценарий 1. Админка кооператива

ALLOW IF:
- Group = Board
- AND 2FA enabled

Сценарий 2. Финансовые данные

ALLOW IF:
- Group = Accountants
- AND 2FA enabled
- AND IP = office network

Сценарий 3. Семейные сервисы

Immich

ALLOW IF:
- Group = Family

Сценарий 4. Админка сайта

Stocktorg

ALLOW IF:
- Group = Admins

Expression Policy (самое мощное оружие)

Пример 1: проверка группы

return "Admins" in [g.name for g in user.groups.all()]

Пример 2: проверка email домена

return user.email.endswith("@stocktorg.com.ua")

Пример 3: комбинированное условие

return (
    "Board" in [g.name for g in user.groups.all()]
    and user.is_active
)

Ошибки новичков

Ошибка №1

❌ Политика создана, но не подключена

Policy сама ничего не делает.

Ошибка №2

❌ Слишком сложные правила сразу

Начинайте с:

• Group Policy

Ошибка №3

❌ Путают Flow и Policy

• Flow = процесс
• Policy = условие

Как правильно думать

Flow — это сценарий

Login → Password → 2FA → Success

Policy — это фильтр

Можно ли дальше?

Реальная схема Authentik с политиками

Практическое задание №7

Шаг 1

Создать политики:

• Admins only
• Board only
• Family only

Шаг 2

Добавить 2FA requirement

Шаг 3

Добавить IP restriction (если есть локальная сеть)

Шаг 4

Подключить политики к:

• Flow входа
• Proxy Provider
• OIDC Provider

Шаг 5

Протестировать:

• разные пользователи
• разные группы
• разные условия

Что должно остаться в голове

Итог части 7

Теперь Authentik для тебя — это:

• не просто SSO
• не просто вход
• а система правил доступа уровня организации

Следующая глава

Часть 8. Sources и LDAP/OAuth интеграции: подключаем внешних пользователей (Google, GitHub, LDAP, Active Directory).

После неё ты сможешь объединять Authentik не только со своими сервисами, но и с внешними системами пользователей.

Authentik для начинающих. Часть 6. Proxy Provider — защита любых сайтов без встроенного SSO

Версия курса: Authentik 2025.12.x

Зачем нужен Proxy Provider

До этого мы подключали сервисы, которые уже умеют OIDC:

• Nextcloud
• Immich
• Grafana и т.д.

Но есть проблема:

Большинство сайтов вообще не поддерживают SSO

Например:

• сайт магазина (Stocktorg)
• админка PHP / Laravel / WordPress
• внутренние панели
• старые приложения
• самописные сервисы

Решение

Authentik умеет работать как обратный прокси с авторизацией через Proxy Provider.

Как это работает (простая схема)

Без Authentik:

Пользователь → сразу сайт → нет защиты или своя авторизация

С Proxy Provider:

Пользователь → Authentik → логин + 2FA → сайт открывается

Что такое Proxy Provider

Proxy Provider — это режим, при котором Authentik:

• стоит перед вашим сайтом
• перехватывает запросы
• проверяет пользователя
• пропускает или блокирует доступ

Где это в интерфейсе

Откройте:

Провайдеры (Providers)

или:

Providers

Нажмите:

👉 Создать (Create)

Выберите:

👉 Proxy Provider

Основные параметры Proxy Provider

1. Name

Пример:

Stocktorg Proxy

2. External Host

Это адрес, который видит пользователь:

https://stocktorg.com.ua

3. Internal Host

Это реальный сервер внутри сети:

http://192.168.1.50:8080

или

http://nginx:80

4. Authentication Flow

Выбираем Flow:

default-authentication-flow

5. Mode

Обычно:

• Forward Auth (рекомендуется)
• Reverse Proxy

Шаг 2. Создаём Application

Открываем:

Приложения (Applications)

или:

Applications

Создаём:

Name

Stocktorg

Provider

Выбираем:

Stocktorg Proxy

Шаг 3. Подключение через Nginx (пример)

Обычно Proxy Provider работает через:

• Nginx
• Traefik
• Docker labels

Пример логики Nginx

location / {
    auth_request /outpost.goauthentik.io/auth/nginx;
    proxy_pass http://backend;
}

Шаг 4. Forward Auth (самый важный режим)

В этом режиме:

1. Пользователь идёт на сайт
2. Nginx спрашивает Authentik: “можно?”
3. Authentik проверяет:
   • логин
   • группу
   • 2FA
4. Ответ:
   • OK → пропуск
   • DENY → редирект на вход

Реальный пример: защита сайта Stocktorg

Было:

https://stocktorg.com.ua → сразу сайт

Стало:

https://stocktorg.com.ua
        ↓
Authentik login
        ↓
2FA проверка
        ↓
доступ к сайту

Ограничение доступа по группам

Очень важная функция.

Пример:

Только админы

Group = Admins

Только бухгалтерия

Group = Accountants

Только кооператив

Group = CooperativeMembers

Как это выглядит в Policy

Что можно защитить Proxy Provider’ом

1. Админки

• WordPress admin
• Laravel admin panel
• CMS

2. Внутренние сервисы

• Portainer
• Grafana
• monitoring

3. Ваш сайт

Stocktorg

4. Самописные системы

• кооперативная платформа
• CRM
• ERP

Важное ограничение Proxy Provider

Он НЕ заменяет авторизацию внутри приложения.

Он только:

закрывает вход на уровне доступа к сайту

Частая ошибка №1

❌ Открытый backend без Authentik

Например:

http://192.168.1.50:8080 доступен напрямую

Это опасно

Пользователь может обойти Authentik.

Решение

• закрыть backend firewall’ом
• разрешить доступ только через proxy

Частая ошибка №2

❌ Неправильный External Host

Должен совпадать с реальным доменом:

https://stocktorg.com.ua

Частая ошибка №3

❌ Нет привязки Application

Proxy Provider без Application = не отображается пользователю

Как это всё связывается

Практическое задание №6

Шаг 1

Создать Proxy Provider:

• Stocktorg Proxy
• External: ваш сайт

Шаг 2

Создать Application:

• Stocktorg

Шаг 3

Настроить Nginx/Traefik:

• подключить auth_request

Шаг 4

Ограничить доступ:

• только группа Admins

Шаг 5

Проверить вход:

• без Authentik → нет доступа
• через Authentik → доступ есть

Что должно остаться в голове

Итог части 6

Теперь у тебя есть:

• SSO для современных сервисов (OIDC)
• защита старых и любых сайтов (Proxy Provider)
• единая система контроля доступа

Следующая глава

Часть 7. Policies глубоко: сложные правила доступа (группы + IP + время + 2FA + атрибуты пользователей).

Там мы превратим Authentik из “логин-системы” в полноценную систему управления правами уровня организации/кооператива.