Сценарии применения¶

Эта страница отвечает на вопрос «из чего складывается работающее решение целиком» для каждого из пяти сценариев, ради которых Alatyr обычно и внедряют. Для каждого сценария показано, какие компоненты входят в поставку Alatyr, что заказчик разворачивает и настраивает у себя, и какие варианты развёртывания существуют. Alatyr выдаёт и отзывает identity-материал — сам по себе он не заменяет ни RADIUS-сервер, ни Active Directory, ни sshd: без этих компонентов сценарии не работают, и на схемах они показаны явно.

Если вам нужно НАСТРОИТЬ сценарий, а не оценить его целиком

Здесь — карта: кто с кем разговаривает и чья зона ответственности. Что нажимать и в каком порядке — в разделе своей цели: Wi-Fi и проводной 802.1X, mTLS пользователя, SSH-доступ, Вход в домен по смарт-карте, Доступ к Kubernetes.

Как читать схемы

Одна и та же нотация используется на всех схемах ниже:

Синие блоки со сплошной рамкой — компоненты, входящие в Alatyr: сервер (Go + PostgreSQL), агент на устройстве, админка.
Серые блоки с пунктирной рамкой — то, что заказчик разворачивает и администрирует сам: PKI-бэкенд, сетевое оборудование, RADIUS, Active Directory, целевые серверы, приложения.
Зелёные блоки — аппаратное хранилище ключа на самом устройстве (TPM 2.0 на Windows/Linux, Secure Enclave на macOS). Приватный ключ создаётся там и оттуда не извлекается — наружу уходит только запрос на подпись или публичная половина ключа.

Сервер Alatyr во всех сценариях один и тот же и разворачивается один раз: Docker Compose или Helm-чарт для Kubernetes — см. Установка. PostgreSQL и PKI-бэкенд — внешние по отношению к продукту зависимости, даже когда поставляемые манифесты поднимают их «в комплекте» для демонстрации.

Что нужно для работы после выдачи сертификата

Основной цикл выдачи (подкоманда run) — короткоживущий процесс по расписанию: он получает сертификат, записывает его в хранилище операционной системы и завершается. Сервер Alatyr после этого не нужен для того, чтобы уже выданный сертификат работал: пока он действителен, подключения не разрываются и вход в систему не блокируется, даже если сервер недоступен.

Но часть сценариев требует постоянно работающего процесса на самом устройстве — это важно учитывать при планировании:

Сценарий	Что происходит после выдачи
Wi-Fi и проводной доступ, Windows	Работает штатный клиент 802.1X в ОС. Постоянные процессы Alatyr не нужны.
Wi-Fi и проводной доступ, macOS	Работает штатный клиент 802.1X, но подпись ключом Secure Enclave выполняет CryptoTokenKit-расширение Alatyr внутри установленного приложения. Постоянно работающего процесса нет — расширение поднимает сама ОС по запросу; удаление или отключение приложения ломает аутентификацию.
Wi-Fi и проводной доступ, Linux	NetworkManager запрашивает PIN к ключу в TPM при каждой активации соединения — его отдаёт постоянный сервис `alatyr-agent-secretd`. Без него соединение не поднимется.
mTLS	Работает TLS-стек приложения или браузера. Постоянные процессы Alatyr не нужны; на macOS сертификат отдаётся приложениям через то же CryptoTokenKit-расширение, что и для Wi-Fi.
Вход в домен Windows	Вход выполняет сама Windows. Процессы Alatyr не нужны.
SSH	Подпись выполняет аппаратный ssh-agent внутри процесса агента — он должен быть запущен.
Kubernetes	Сертификата «после выдачи» здесь не существует: `kubectl` получает новый на десять минут при каждом обращении, поэтому агент нужен ПОСТОЯННО, а не один раз. См. Два режима доставки credential.

Подробнее о постоянных процессах агента на каждой ОС — в разделе Агенты.

Wi-Fi и проводной доступ по 802.1X (EAP-TLS)¶

Самый частый сценарий: сотрудники подключаются к корпоративной сети без общего пароля и без ручной раздачи сертификатов. Устройство доказывает свою подлинность клиентским сертификатом, приватный ключ которого физически находится в TPM или Secure Enclave.

Кто с кем взаимодействует¶

flowchart TD
    subgraph DeviceBox["Устройство сотрудника"]
        HW["TPM 2.0 / Secure Enclave"]
        Agent["Агент Alatyr"]
        OS["Сетевой стек ОС<br/>клиент 802.1X"]
    end

    subgraph AlatyrBox["Входит в Alatyr"]
        Admin["Админка"]
        Server["Сервер Alatyr"]
    end

    PKI[("PKI-бэкенд<br/>Vault PKI или внешний SCEP CA")]
    Net["Точка доступа<br/>или коммутатор"]
    Radius["RADIUS-сервер"]

    HW <--> |"1"| Agent
    Agent <--> |"2, 6"| Server
    Admin --> |"3"| Server
    Server <--> |"4, 5"| PKI
    Agent --> |"7"| OS
    OS --> |"8"| Net
    Net --> |"9"| Radius
    Radius --> |"10"| PKI

    classDef alatyr fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#111827
    classDef external fill:#f3f4f6,stroke:#9ca3af,stroke-width:1px,stroke-dasharray: 4 3,color:#111827
    classDef device fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#111827
    class Agent,Server,Admin alatyr
    class PKI,Net,Radius external
    class HW,OS device

В каком порядке это происходит¶

sequenceDiagram
    participant HW as TPM / Secure Enclave
    participant Agent as Агент Alatyr
    participant OS as Сетевой стек ОС
    participant Admin as Админка
    participant Server as Сервер Alatyr
    participant PKI as PKI-бэкенд
    participant Net as Точка доступа
    participant Radius as RADIUS-сервер

    Agent->>HW: 1. создать ключ
    Agent->>Server: 2. запрос на сертификат (CSR)
    Admin->>Server: 3. одобрить заявку
    Server->>PKI: 4. подписать
    PKI-->>Server: 5. сертификат
    Server-->>Agent: 6. сертификат + профиль 802.1X
    Agent->>OS: 7. записать в хранилище ОС
    Note over Agent: дальше агент не участвует
    OS->>Net: 8. подключение по EAP-TLS
    Net->>Radius: 9. RADIUS
    Radius->>PKI: 10. проверка цепочки и отзыва

Что означает каждый шаг¶

№	Шаг	Кто выполняет
1	Агент создаёт ключ в TPM или Secure Enclave; приватная половина остаётся в железе	Alatyr
2	Агент отправляет запрос на сертификат (CSR) по HTTPS	Alatyr
3	Администратор одобряет заявку в админке	Alatyr
4	Сервер запрашивает подпись у PKI-бэкенда	Alatyr → заказчик
5	PKI-бэкенд возвращает подписанный сертификат	Заказчик
6	Сервер отдаёт агенту сертификат и профиль 802.1X	Alatyr
7	Агент записывает сертификат и профиль в хранилище ОС — на этом его работа заканчивается	Alatyr
8	Штатный клиент 802.1X в ОС подключается к сети по EAP-TLS	ОС устройства
9	Точка доступа передаёт аутентификацию RADIUS-серверу	Заказчик
10	RADIUS-сервер проверяет цепочку доверия и отзыв (CRL или OCSP)	Заказчик

Компонент	Чья зона
Агент, генерация ключа в TPM/Secure Enclave, отправка CSR	Alatyr
Сервер: заявки, одобрение, выпуск, отзыв, журнал аудита	Alatyr
Админка: одобрение заявок, список сетей, отзыв сертификатов	Alatyr
Установка выданного сертификата и профиля 802.1X на устройство	Alatyr (либо MDM/GPO — см. ниже)
PKI-бэкенд (Vault PKI или внешний SCEP CA), публикация CRL/OCSP	Заказчик
RADIUS-сервер (FreeRADIUS, NPS, любой другой RFC-совместимый)	Заказчик
Точки доступа, коммутаторы, VLAN, RADIUS-клиенты на них	Заказчик
PostgreSQL	Заказчик

Варианты развёртывания

PKI-бэкенд: Vault PKI или внешний SCEP CA — настраивается отдельно для purpose wifi, независимо от остальных целей выпуска. Это единственная цель с fallback-поведением: если профиль выпуска не настроен явно, используется Vault-issuer из переменных окружения сервера (Архитектура и PKI).
Кто ставит сетевой профиль: сам агент либо внешний MDM/GPO/config management (Кто ставит профиль).
Тип сети: Wi-Fi и проводной 802.1X настраиваются в одном списке сетей; одновременно активной проводной сетью может быть только одна (Wi-Fi и проводной 802.1X).

Что потребуется от заказчика. RADIUS-сервер должен доверять тому же CA, который подписал клиентские сертификаты, — иначе EAP-TLS не пройдёт. Обратное требование не менее важно: профиль 802.1X закрепляет CA-сертификат как якорь доверия, поэтому серверный сертификат RADIUS тоже должен вести к этому якорю. Кроме того, RADIUS должен проверять отзыв (CRL или OCSP) — Alatyr отзывает сертификат у CA, но принудить сетевой сегмент к перепроверке он не может.

Что именно проверить на стороне RADIUS, как завести сеть и почему имя RADIUS-сервера стоит задать сразу — раздел Wi-Fi и проводной 802.1X. Про выпуск и отзыв — Архитектура и PKI.

mTLS для внутренних приложений¶

Клиентский сертификат user_mtls выдаётся не машине, а пользователю: ключ защищён подтверждением владельца (отпечаток, PIN устройства или PIN карты) и лежит в пользовательском хранилище. Приложение или обратный прокси перед ним аутентифицирует пользователя по этому сертификату, без пароля.

Здесь — сценарий целиком. Что и в каком порядке настраивать — в разделе mTLS пользователя.

Кто с кем взаимодействует¶

flowchart TD
    subgraph DeviceBox["Устройство сотрудника"]
        HW["Secure Enclave / TPM<br/>ключ с проверкой присутствия"]
        Agent["Агент Alatyr"]
    end

    subgraph AlatyrBox["Входит в Alatyr"]
        Admin["Админка"]
        Server["Сервер Alatyr"]
    end

    PKI[("Отдельный intermediate CA<br/>только для user_mtls")]
    Proxy["Точка терминации mTLS<br/>обратный прокси или приложение"]
    App["Внутреннее приложение"]

    HW <--> |"1"| Agent
    Agent <--> |"2, 6"| Server
    Admin --> |"3"| Server
    Server <--> |"4, 5"| PKI
    Agent --> |"7"| Store["Хранилище сертификатов ОС"]
    Store --> |"8"| Proxy
    Proxy --> |"9"| PKI
    Proxy --> |"10"| App

    classDef alatyr fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#111827
    classDef external fill:#f3f4f6,stroke:#9ca3af,stroke-width:1px,stroke-dasharray: 4 3,color:#111827
    classDef device fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#111827
    class Agent,Server,Admin alatyr
    class PKI,Proxy,App external
    class HW,Store device

В каком порядке это происходит¶

sequenceDiagram
    participant HW as Secure Enclave / TPM
    participant Agent as Агент Alatyr
    participant Admin as Админка
    participant Server as Сервер Alatyr
    participant Store as Хранилище ОС
    participant PKI as Intermediate CA
    participant Proxy as Точка терминации mTLS
    participant App as Приложение

    Agent->>HW: 1. создать ключ с проверкой присутствия
    Agent->>Server: 2. запрос на сертификат
    Admin->>Server: 3. одобрить заявку
    Server->>PKI: 4. подписать
    PKI-->>Server: 5. сертификат
    Server-->>Agent: 6. сертификат
    Agent->>Store: 7. записать в хранилище ОС
    Note over Agent: дальше агент не участвует
    Store->>Proxy: 8. TLS с клиентским сертификатом
    Proxy->>PKI: 9. проверка по этому intermediate
    Proxy->>App: 10. проверенная идентичность

Что означает каждый шаг¶

№	Шаг	Кто выполняет
1	Агент создаёт ключ на той ступени подтверждения владельца, которую администратор выбрал для цели: без подтверждения, отпечаток/PIN устройства или PIN карты	Alatyr
2	Агент отправляет запрос на сертификат	Alatyr
3	Администратор одобряет заявку. Сервисный аккаунт с ролью `cert-auto-approver` может одобрять `user_mtls`, только если эта цель разрешена ему явно (`allowed_purposes`); по умолчанию ему разрешён один `wifi`	Alatyr
4	Сервер запрашивает подпись у отдельного intermediate CA	Alatyr → заказчик
5	Intermediate CA возвращает подписанный сертификат	Заказчик
6	Сервер отдаёт сертификат агенту	Alatyr
7	Агент кладёт сертификат в пользовательское хранилище ОС — на этом его работа заканчивается	Alatyr
8	Приложение или браузер пользователя устанавливает TLS-соединение с клиентским сертификатом	ОС устройства
9	Точка терминации mTLS проверяет сертификат по этому intermediate CA	Заказчик
10	Приложение получает проверенную идентичность пользователя	Заказчик

Компонент	Чья зона
Выпуск ключа с проверкой присутствия в пользовательском контексте	Alatyr
Заявка, одобрение, выпуск и отзыв	Alatyr
Установка сертификата в пользовательское хранилище устройства	Alatyr
Отдельный intermediate CA для `user_mtls` в PKI-бэкенде	Заказчик
Точка терминации mTLS (обратный прокси или само приложение)	Заказчик
Сопоставление идентичности из сертификата с учётной записью в приложении	Заказчик

Варианты развёртывания

PKI-бэкенд: Vault PKI или внешний SCEP CA. В отличие от wifi, у user_mtls нет fallback: без явно настроенного и включённого профиля выпуска заявки отклоняются.
Где терминируется mTLS: на обратном прокси перед приложением (тогда проверенная идентичность передаётся приложению заголовком, которому оно доверяет только от этого прокси) либо непосредственно в приложении.

Что потребуется от заказчика. Одно требование здесь важнее всех остальных вместе взятых: user_mtls обязан выпускаться из отдельного intermediate CA, не из того же, что wifi. Пока центр у них общий, машинный сертификат wifi для вашего приложения неотличим от пользовательского, и защиты нет вовсе. Разбор и порядок действий — mTLS пользователя → Настройка.

Дальше ваша сторона отвечает за точку терминации mTLS и за список отзыва: без него отозванный сертификат пускает до конца своего срока (Отзыв доступа). Готовые настройки haproxy, nginx и OpenVPN — Приёмники сертификатов. Настройка целей выпуска — Архитектура и PKI; политика одобрения заявок — Администрирование.

Вход в домен Windows по смарт-карте¶

Цель ad_logon (в интерфейсе — «Вход в AD») даёт вход в домен Windows по смарт-карте. Роль карты играет смарт-карта, которую поднимает сам агент на устройстве: он устанавливает собственный считыватель и обслуживает карту в облике GIDS, а на стороне Windows её обслуживает штатный подписанный минидрайвер msclmd. Ключ карты не покидает устройство, и отдельного оборудования не нужно: ни физического считывателя, ни пластиковой карты в этом сценарии нет. Сотрудник входит PIN'ом карты, а не доменным паролем. Тот же сертификат работает и при входе по RDP — с оговорками, разобранными в «Входе по RDP».

Здесь — сценарий целиком: кто с кем взаимодействует и чья зона ответственности. Что и в каком порядке настраивать — в разделе Вход в домен по смарт-карте.

Кто с кем взаимодействует¶

flowchart TD
    subgraph DeviceBox["Windows-устройство в домене"]
        Agent["Агент Alatyr"]
        VSC["Смарт-карта агента<br/>ключ + PIN"]
    end

    subgraph AlatyrBox["Входит в Alatyr"]
        Admin["Админка"]
        Server["Сервер Alatyr"]
    end

    NDES["SCEP-сервис (NDES)"]
    ADCS[("ADCS CA<br/>шаблон Smart Card Logon")]
    DC["Контроллер домена"]
    Trust["NTAuth store<br/>и доверие корню CA"]

    Agent <--> |"1, 8"| VSC
    Agent <--> |"2, 7"| Server
    Admin --> |"3"| Server
    Server <--> |"4, 6"| NDES
    NDES <--> |"5"| ADCS
    VSC --> |"9"| DC
    DC --> |"10"| Trust

    classDef alatyr fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#111827
    classDef external fill:#f3f4f6,stroke:#9ca3af,stroke-width:1px,stroke-dasharray: 4 3,color:#111827
    classDef device fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#111827
    class Agent,Server,Admin alatyr
    class NDES,ADCS,DC,Trust external
    class VSC device

В каком порядке это происходит¶

sequenceDiagram
    participant Agent as Агент Alatyr
    participant VSC as Смарт-карта агента
    participant Admin as Админка
    participant Server as Сервер Alatyr
    participant NDES as SCEP-сервис (NDES)
    participant ADCS as ADCS CA
    participant DC as Контроллер домена

    Agent->>VSC: 1. поднять смарт-карту и завести ключ
    Agent->>Server: 2. запрос с UPN
    Admin->>Server: 3. одобрить заявку
    Server->>NDES: 4. запрос по SCEP
    NDES->>ADCS: 5. выпуск по шаблону Smart Card Logon
    NDES-->>Server: 6. сертификат
    Server-->>Agent: 7. сертификат
    Agent->>VSC: 8. положить сертификат на карту
    Note over Agent: дальше агент не участвует
    VSC->>DC: 9. вход по PIN смарт-карты
    DC->>DC: 10. проверка доверия к CA (NTAuth)

Что означает каждый шаг¶

№	Шаг	Кто выполняет
1	Агент поднимает на устройстве свою смарт-карту (собственный считыватель, апплет GIDS) и заводит в ней ключ	Alatyr
2	Агент формирует запрос с UPN и расширениями для доменного входа	Alatyr
3	Администратор одобряет заявку. Заявка несёт личность человека, поэтому сервисному аккаунту цель `ad_logon` по умолчанию не разрешена — открыть её можно только явным решением администратора	Alatyr
4	Сервер обращается за сертификатом к SCEP-сервису (NDES)	Alatyr → заказчик
5	NDES выпускает сертификат в ADCS по шаблону Smart Card Logon	Заказчик
6	Сертификат возвращается серверу	Заказчик
7	Сервер отдаёт сертификат агенту	Alatyr
8	Агент кладёт сертификат на карту; штатная служба распространения Windows копирует его в личное хранилище пользователя и связывает с картой — на этом работа агента заканчивается	Alatyr
9	Пользователь входит в домен по PIN смарт-карты вместо пароля; вход выполняет сама Windows	ОС устройства
10	Контроллер домена проверяет, что CA доверен для доменной аутентификации	Заказчик

Компонент	Чья зона
Смарт-карта на устройстве: считыватель, апплет, ключ, PIN	Alatyr
Формирование запроса с UPN и нужными расширениями, заявка и одобрение	Alatyr
Обращение к SCEP-сервису за сертификатом	Alatyr
ADCS CA и шаблон сертификата Smart Card Logon	Заказчик
SCEP-сервис (NDES), доступный серверу Alatyr	Заказчик
Публикация CA в NTAuth store и распространение доверия корню	Заказчик (права Domain Admin)
Контроллеры домена, учётные записи, групповые политики	Заказчик

Варианты развёртывания

PKI-бэкенд: только SCEP/ADCS. Vault PKI для этой цели не подходит и отклоняется сервером: он не умеет выпускать расширение сертификата, обязательное для строгого сопоставления сертификата с учётной записью (KB5014754). Это единственная цель выпуска с жёстко зафиксированным источником — см. Архитектура и PKI.
Платформа: только Windows. Доменный вход по смарт-карте с macOS в этот сценарий не входит.

Что потребуется от заказчика. Настройка на стороне Active Directory принципиально не автоматизируется Alatyr и выполняется администратором домена один раз на каждый CA: выпускающий CA публикуется в NTAuth store, а его корень раздаётся как доверенный для входа по смарт-карте на все контроллеры домена и клиенты. Без этих двух шагов сертификат будет технически корректным, но Windows отклонит его на экране входа. На текущем этапе установка уже выпущенного сертификата на карту выполняется администратором вручную — это раскрытое ограничение, а не автоматизированный шаг. Что именно включить в шаблоне ADCS и как опубликовать УЦ в NTAuth — Настройка входа по карте; пределы функции — Пределы и нюансы; поведение агента на Windows — Агенты.

SSH-доступ¶

Здесь два независимых механизма. Вариант А: короткоживущие OpenSSH-сертификаты, подписанные Vault SSH secrets engine; sshd доверяет публичному ключу CA. Вариант Б: SSH Key Registry — реестр «сырых» аппаратных публичных ключей без всякого CA и без сертификатов; sshd спрашивает актуальный список ключей пользователя у Keyholder API.

Они не заменяют друг друга: реестр даёт мгновенный отзыв, сертификат продолжает пускать сотрудников, когда сервер Alatyr недоступен. Сравнение и порядок настройки — в разделе SSH-доступ.

Кто с кем взаимодействует¶

flowchart TD
    subgraph DeviceBox["Устройство сотрудника"]
        HW["TPM 2.0 / Secure Enclave"]
        Agent["Агент Alatyr"]
    end

    subgraph AlatyrBox["Входит в Alatyr"]
        Server["Сервер Alatyr"]
        KH["Keyholder API<br/>маршруты того же сервера"]
    end

    Vault[("Vault SSH secrets engine")]
    Sshd["sshd на целевом хосте"]

    HW <--> Agent
    Agent <--> |"вариант А"| Server
    Server <--> |"вариант А"| Vault
    Agent --> |"вариант Б"| Server
    Agent --> |"SSH-подключение"| Sshd
    Sshd <--> |"вариант А: скрипт заказчика обновляет локальные файлы"| Server
    Sshd --> |"вариант Б"| KH

    classDef alatyr fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#111827
    classDef external fill:#f3f4f6,stroke:#9ca3af,stroke-width:1px,stroke-dasharray: 4 3,color:#111827
    classDef device fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#111827
    class Agent,Server,KH alatyr
    class Vault,Sshd external
    class HW device

Вариант А — OpenSSH-сертификаты¶

sequenceDiagram
    participant HW as TPM / Secure Enclave
    participant Agent as Агент Alatyr
    participant Server as Сервер Alatyr
    participant Vault as Vault SSH engine
    participant Sshd as sshd на хосте

    Agent->>HW: 1. создать ключ
    Agent->>Server: 2. заявка на SSH-сертификат
    Server->>Vault: 3. подписать после одобрения
    Vault-->>Server: 4. OpenSSH-сертификат
    Server-->>Agent: 5. сертификат
    Agent->>Sshd: 6. подключение с сертификатом
    Note over Sshd: 7. проверка по локальным файлам — публичному ключу CA и KRL

№	Шаг	Кто выполняет
1	Агент создаёт ключ в аппаратном хранилище	Alatyr
2	Агент отправляет заявку на SSH-сертификат	Alatyr
3	После одобрения сервер запрашивает подпись в Vault SSH secrets engine	Alatyr → заказчик
4	Vault возвращает короткоживущий OpenSSH-сертификат	Заказчик
5	Сервер передаёт сертификат агенту	Alatyr
6	Пользователь подключается по SSH, предъявляя сертификат	Заказчик
7	`sshd` проверяет сертификат по локальным файлам — публичному ключу CA и списку отзыва (KRL). Заказчик отдельно настраивает их регулярное обновление; целевой сервер берёт KRL по адресу `GET /api/v1/keyholder/krl`, который аутентифицируется allowlist'ом по IP, а не админской ролью (Настройка SSH-доступа)	Заказчик

Вариант Б — реестр «сырых» ключей¶

sequenceDiagram
    participant HW as TPM / Secure Enclave
    participant Agent as Агент Alatyr
    participant Server as Сервер Alatyr
    participant KH as Keyholder API
    participant Sshd as sshd на хосте

    Agent->>HW: 1. создать ключ
    Agent->>Server: 2. регистрация публичного ключа
    Note over Server: 3. администратор одобряет ключ
    Agent->>Sshd: 4. подключение по SSH
    Sshd->>KH: 5. запрос ключей по логину
    KH-->>Sshd: 6. список активных ключей

№	Шаг	Кто выполняет
1	Агент создаёт ключ в аппаратном хранилище	Alatyr
2	Агент регистрирует публичную половину ключа в реестре	Alatyr
3	Администратор одобряет ключ — без этого он не выдаётся	Alatyr
4	Пользователь подключается по SSH	Заказчик
5	`sshd` запрашивает у Keyholder API список ключей этого логина	Заказчик
6	Keyholder API возвращает только одобренные активные ключи	Alatyr

Компонент	Чья зона
Аппаратный ssh-agent на устройстве, подпись ключом из TPM/Secure Enclave	Alatyr
Вариант А: заявка на сертификат, одобрение, публикация KRL	Alatyr
Вариант Б: реестр ключей, allowlist принципалов, Keyholder API	Alatyr
Vault с включённым SSH secrets engine (только вариант А)	Заказчик
Целевые хосты и настройка `sshd` на них	Заказчик
Сетевой доступ от целевых хостов до сервера Alatyr	Заказчик

Варианты развёртывания

Вариант А — сертификаты. Источник выпуска только один: Vault SSH secrets engine. У этого механизма нет CRL/OCSP в принципе, поэтому единственное средство отзыва — список отозванных ключей в бинарном формате OpenSSH (KRL), который sshd периодически перечитывает.
Вариант Б — реестр ключей. CA не нужен вообще; sshd получает актуальный список публичных ключей пользователя через AuthorizedKeysCommand. Отзыв мгновенный: отозванный ключ просто перестаёт возвращаться. Доступ к Keyholder API ограничивается обязательным списком разрешённых подсетей (пустой список = эндпоинт закрыт) и, по желанию, дополнительным серверным токеном.
Одобрение. Оба варианта по умолчанию требуют ручного одобрения; автоодобрение для реестра ключей включается отдельно и по умолчанию выключено.

Что потребуется от заказчика. Для варианта А — работающий Vault с включённым SSH secrets engine и настройка sshd на доверие публичному ключу CA плюс регулярное обновление файла KRL. Для варианта Б — настройка sshd на вызов внешней команды за списком ключей и сетевой доступ от целевых хостов (или bastion-хоста) до Alatyr. Пошаговый порядок — Настройка SSH-доступа; устройство механизма, модель доступа Keyholder API и её задокументированные ограничения — Реестр ключей и Keyholder API; список эндпоинтов — REST API.

Одна директива AuthorizedKeysCommand на область

Если на целевых серверах уже настроен другой источник ключей (например, FreeIPA), вторую директиву sshd молча пропустит. Прочитайте «Совмещение с FreeIPA» до начала работ.

Доступ к Kubernetes¶

Цель k8s заменяет kubeconfig с вшитым клиентским сертификатом, собранный руками и отправленный человеку. Ключ идентичности лежит в чипе устройства, а кластеру kubectl предъявляет отдельный сертификат на десять минут, который выписывается заново на каждый вызов и на диск не попадает. Куда ходить и какому CA доверять, устройству говорит реестр кластеров на сервере Alatyr.

Половина работы здесь — на стороне заказчика и намеренно не автоматизируется: API-сервер должен доверять цепочке Alatyr (--client-ca-file), а RBAC — привязываться к субъекту сертификата. Отзыв Kubernetes не проверяет вовсе, поэтому у механизма своя форма отзыва.

Схема целиком, порядок настройки и пределы — в разделе «Доступ к Kubernetes».

Что общего у всех сценариев¶

Во всех пяти случаях приватный ключ создаётся в аппаратном хранилище устройства и не покидает его, а каждая заявка по умолчанию попадает в статус pending и ждёт решения человека.

Автоматическое одобрение сервисным аккаунтом (роль cert-auto-approver) разрешено на каждом токене отдельно, и умолчание — только цель wifi. Заявки user_mtls, ad_logon, ssh и k8s несут в себе личность человека, поэтому открыть их автоодобрению можно лишь явным решением администратора — это осознанный размен, а не настройка по умолчанию. Отдельный механизм — реестр «сырых» SSH-ключей: у него собственный переключатель автоодобрения, тоже по умолчанию выключенный. Подробнее — Администрирование.

Цели независимы: можно внедрить только Wi-Fi, добавить mTLS позже, а SSH не использовать вовсе — каждая цель настраивается на свой источник выпуска отдельно, а какие цели положены конкретной машине, задаётся на её карточке в админке. Дальше по документации: Архитектура и PKI — как устроен выпуск, Установка — как развернуть сервер и агенты, Расчёт ресурсов, Отказоустойчивость (HA) и Лицензирование — что учесть перед продакшеном.