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

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

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

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

• Синие блоки со сплошной рамкой — компоненты, входящие в Alatyr: сервер (Go + PostgreSQL), агент на устройстве, Admin UI.
• Серые блоки с пунктирной рамкой — то, что заказчик разворачивает и администрирует сам: 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 внутри процесса агента — он должен быть запущен.

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

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["Admin UI"]
        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 Admin UI
    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	Администратор одобряет заявку в Admin UI	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
Admin UI: одобрение заявок, список сетей, отзыв сертификатов	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. Для второго случая есть переключатели «не распространять профиль агентом» — fleet-wide и отдельно на каждую сеть и ОС (Агенты).
• Тип сети: Wi-Fi и проводной 802.1X настраиваются в одном списке сетей; одновременно активной проводной сетью может быть только одна (Администрирование).

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

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

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

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

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

    subgraph AlatyrBox["Входит в Alatyr"]
        Admin["Admin UI"]
        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 Admin UI
    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	Агент создаёт ключ, защищённый проверкой присутствия (Touch ID, PIN)	Alatyr
2	Агент отправляет запрос на сертификат	Alatyr
3	Администратор одобряет заявку — для user_mtls одобрение человеком обязательно, сервисный аккаунт с ролью cert-auto-approver такую заявку одобрить не может	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 выдаётся машине и подписывается без всякого участия пользователя; если проверяющая сторона доверяет общему корню, такой машинный сертификат станет полноценной заменой пользовательскому — и смысл проверки присутствия будет утрачен. Поэтому хранилище доверенных CA на стороне приложения должно содержать именно intermediate для user_mtls, а не корневой сертификат и не связку, через которую проходит и wifi. Настройка целей выпуска описана в Архитектуре и PKI; политика одобрения заявок — в Администрировании.

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

Purpose ad_logon даёт вход в домен Windows по смарт-карте, где роль карты играет TPM Virtual Smart Card, создаваемая агентом на самом устройстве. Пользователь входит по PIN виртуальной карты, а не по доменному паролю.

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

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

    subgraph AlatyrBox["Входит в Alatyr"]
        Admin["Admin UI"]
        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 Virtual Smart Card
    participant Admin as Admin UI
    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	Агент создаёт на устройстве TPM Virtual Smart Card и ключ в ней	Alatyr
2	Агент формирует запрос с UPN и расширениями для доменного входа	Alatyr
3	Администратор одобряет заявку — заявка несёт идентичность человека, поэтому сервисный аккаунт с ролью cert-auto-approver одобрить её не может	Alatyr
4	Сервер обращается за сертификатом к SCEP-сервису (NDES)	Alatyr → заказчик
5	NDES выпускает сертификат в ADCS по шаблону Smart Card Logon	Заказчик
6	Сертификат возвращается серверу	Заказчик
7	Сервер отдаёт сертификат агенту	Alatyr
8	Агент помещает сертификат в виртуальную смарт-карту — на этом его работа заканчивается	Alatyr
9	Пользователь входит в домен по PIN смарт-карты вместо пароля; вход выполняет сама Windows	ОС устройства
10	Контроллер домена проверяет, что CA доверен для доменной аутентификации	Заказчик

Компонент	Чья зона
Создание TPM Virtual Smart Card на устройстве	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 отклонит его на экране входа. На текущем этапе установка уже выпущенного сертификата на виртуальную смарт-карту выполняется администратором вручную — это раскрытое ограничение, а не автоматизированный шаг. Требования к сертификату и порядок выпуска — Архитектура и PKI, поведение агента на Windows — Агенты.

SSH-доступ

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

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

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). Заказчик отдельно настраивает их регулярное обновление из эндпоинтов GET /api/v1/ssh/ca-public-key и GET /api/v1/ssh/krl (требуют роли администратора)	Заказчик

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

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. Развёрнутое сравнение механизмов, модель доступа Keyholder API и её задокументированные ограничения — SSH Key Registry; список эндпоинтов — REST API.

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

Во всех четырёх случаях приватный ключ создаётся в аппаратном хранилище устройства и не покидает его, а каждая заявка по умолчанию попадает в статус pending. Автоматическое одобрение сервисным аккаунтом (роль cert-auto-approver) возможно только для цели wifi; заявки user_mtls, ad_logon и ssh несут в себе идентичность человека и всегда требуют одобрения администратором. Отдельный механизм — реестр «сырых» SSH-ключей: у него собственный переключатель автоодобрения, по умолчанию выключенный. Подробнее — Администрирование. Цели выпуска независимы: можно внедрить только Wi-Fi, добавить mTLS позже, а SSH не использовать вовсе — каждая цель настраивается на свой источник выпуска отдельно. Дальше по документации: Архитектура и PKI — как устроен выпуск, Установка — как развернуть сервер и агенты, Расчёт ресурсов и Отказоустойчивость (HA) — что учесть перед продакшеном.