Известные ограничения¶
Эта страница собирает в одном месте то, чего Alatyr не обещает — чтобы это выяснилось до внедрения, а не на работающей установке. Каждый пункт ниже — краткое резюме; полное описание механизма, включая то, почему он устроен именно так, находится на странице, на которую ведёт ссылка.
Здесь только сквозные ограничения — масштабирование, отзыв, SCEP, платформы. Пределы КОНКРЕТНОЙ цели живут в её собственном разделе, и там их больше: Wi-Fi → Нюансы и пределы, mTLS → Нюансы и пределы, SSH → Нюансы и пределы, Вход по карте → Пределы и нюансы, Kubernetes → Нюансы и пределы.
Масштабирование и отказоустойчивость¶
SCEP-поллинг рассчитан на одну реплику сервера¶
При нескольких репликах сервера с включённым SCEP-issuer'ом между
снятием блокировки с заявки после коммита и обновлением времени
следующей попытки есть короткое окно, в течение которого заявку в
статусе ca_pending может забрать вторая реплика и отправить
дублирующий запрос во внешний SCEP CA. База данных при этом не
рассинхронизируется, но CA может выпустить лишний сертификат, о котором
Alatyr больше не будет знать.
Практически это означает: если у вас включён SCEP-issuer и сервер
масштабируется горизонтально, поллинг ca_pending должен идти только с
одной реплики — например, выделенным компонентом с одной репликой,
пока остальной трафик обслуживают остальные реплики.
Подробнее — Отказоустойчивость (HA).
Rate limiting не общий на репликах¶
Ограничение частоты запросов хранится в памяти каждого процесса сервера,
а не в общем хранилище. Это касается не только /enroll*-эндпоинтов, но
и того же механизма на эндпоинте аттестации лицензии, на Keyholder API и
на агентских запросах, ограничиваемых по идентификатору заявки, — то
есть всех ограничений частоты на сервере. При N репликах за
балансировщиком нагрузки эффективный лимит на один ключ (IP, либо пара
IP+принципал/заявка — в зависимости от эндпоинта) умножается примерно на
N, потому что каждая реплика считает свой собственный счётчик с нуля.
Если строгий лимит на IP — часть модели угроз конкретного развёртывания, это стоит учитывать при выборе числа реплик.
Подробнее — Отказоустойчивость (HA).
В поставляемых манифестах нет отказоустойчивости PostgreSQL¶
Ни Docker Compose, ни Helm-чарт из поставки не разворачивают PostgreSQL в отказоустойчивой конфигурации: база всегда работает как один под без реплики для чтения и без автоматического failover. При пересоздании пода (деплой новой версии, вытеснение с ноды, рестарт) база на время недоступна.
Отказоустойчивость базы данных — задача инфраструктуры, на которой разворачивается Alatyr: управляемый Postgres с HA у облачного провайдера либо самостоятельно поддерживаемый кластер (например, Patroni с потоковой репликацией).
Подробнее — Отказоустойчивость (HA).
Отзыв и доступ¶
Отзыв ОДНОГО сертификата не трогает SSH-ключи устройства¶
Каскада между отдельным сертификатом и SSH-доступом нет: POST
/api/v1/certificates/{serial}/revoke отзывает ровно тот сертификат,
который назвали.
SSH-ключи забирает другое действие — полный отзыв устройства («убить
устройство», POST /api/v1/devices/{serial}/revoke). Он отзывает все
активные ключи машины, и делает это независимо от того, удалось ли
отозвать её сертификаты: защитное действие не ждёт ответа CA. Если
каскад по ключам всё-таки не прошёл, ответ приходит со статусом
ssh_keys_revoke_failed — это единственный исход, при котором устройство
считается «убитым», а его ключи могут ещё открывать доступ, и потому он
перебивает в ответе все остальные.
Практически: отзыва сертификата недостаточно, чтобы закрыть SSH. Нужен
либо полный отзыв устройства, либо отзыв ключей по одному —
GET /api/v1/devices/{serial}/ssh-keys, затем POST
/api/v1/admin/ssh-keys/{id}/revoke.
Подробнее — SSH Key Registry.
Автоодобрение SSH-ключей доверяет принципалу, который заявляет сам агент¶
Сервер не связывает устройство с конкретным человеком — такой привязки
в модели данных нет. principal — это имя локальной учётной записи,
которое присылает клиент, и опровергнуть его серверу нечем; базовая
проверка при регистрации одна — совпадение со списком разрешённых
значений.
Практически: при включённом автоодобрении любое устройство с валидным enrollment-токеном получит рабочий SSH-доступ под любым принципалом из allowlist, без единого человеческого решения. Поведение по умолчанию — ручное одобрение, а не автоодобрение.
Частично это закрывает отдельная ступень — «Привязка SSH-ключа к
человеку» в настройках. Она сверяет корпоративную личность, которую
агент заявляет вместе с ключом, с тем, что сервер знает сам: есть ли на
ЭТОМ устройстве одобренный человеком сертификат user_mtls, ad_logon
или k8s на ту же личность. Ступеней три: не сверять (умолчание);
сверять и записывать вердикт в строку ключа, не отклоняя регистрацию;
отклонять регистрацию, если личность противоречит выданным на устройстве
сертификатам — либо если проверить её не удалось вовсе.
Это подтверждение, а не доказательство: оба поля по-прежнему приходят от клиента, разница в том, что одно из них есть чем опровергнуть, а второе нечем.
Подробнее — SSH Key Registry.
IP-allowlist Keyholder API не ограничивает, какой принципал запрашивается¶
Allowlist ограничивает, откуда можно обращаться к /keyholder/keys, но
не то, ключи какого принципала запрашиваются. Любой хост внутри
разрешённой подсети может запросить ключи произвольного принципала, а
не только «своего».
Для тех, кому одного allowlist недостаточно, есть опциональный bearer-токен сервера, дополнительно защищающий эндпоинт.
Подробнее — SSH Key Registry.
Отзыв доступа к Kubernetes не дотягивается до кластера¶
API-сервер Kubernetes при аутентификации по клиентскому сертификату не проверяет отзыв вовсе: ни CRL, ни OCSP он не спрашивает. Отзыв внутри Alatyr останавливает следующую выдачу, а уже выданный сертификат продолжает работать до истечения — поэтому он живёт десять минут.
Практически: новый доступ прекращается в пределах десяти минут, но уже
установленные соединения (kubectl exec, port-forward, watch) это не
разрывает. Чтобы завершить сессию на ходу, нужно снять привязку RBAC или
убить под в самом кластере.
Подробнее — Доступ к Kubernetes.
Подтверждение при выдаче доступа к кластеру не работает на macOS¶
Ступень «Подтверждение при выдаче доступа к кластеру» умеет спросить человека на Windows и Linux. На macOS механизма спросить пока нет, и поднятая ступень там отказывает в выдаче вместо того, чтобы выдать молча. То же происходит на любой машине без графического сеанса.
Практически: умолчание ступени — «Спросить раз в окно», поэтому на macOS доступ к кластеру потребует осознанно опустить её до «Не спрашивать».
Подробнее — Доступ к Kubernetes.
Блокировку устройства можно обойти, заявив другой серийный номер¶
Блокировка привязана к строке устройства, которая определяется по
серийному номеру, заявленному самим агентом. Устройство, физически
контролирующее собственный агент, может обойти блокировку, заявив
другой серийный номер при повторном enroll (для placeholder-серийников
— просто не предъявив continuity_key).
Готового способа закрыть этот обход сегодня нет. Настройки
TPM_REJECT_UNATTESTED и TPM_REQUIRE_AK_CERTIFY повышают требования к
аттестации ключа, но не связывают заявленный серийный номер с конкретным
железом — устройство с исправным TPM может пройти любую из этих проверок
под новым серийным номером. Правильное решение — привязка блокировки к
аппаратной идентичности — намечено как доработка.
Подробнее — Администрирование.
SCEP¶
Нет операции отзыва сертификата¶
SCEP-протокол не имеет операции revoke. Кнопка отзыва в админке
отключена для SCEP-выпущенных сертификатов, а POST
/api/v1/certificates/{serial}/revoke на таком сертификате вернёт 400.
Отзывать такие сертификаты нужно на стороне внешнего CA напрямую — Alatyr не может сделать это за оператора с этим PKI-бэкендом.
Важно: это зависит от того, какой источник выпуска настроен для цели сертификата (purpose) сейчас, а не от того, каким источником сертификат был выпущен исторически. Если источник для этой цели с момента выпуска сменился на SCEP, отзыв через Alatyr вернёт ошибку и для сертификата, изначально выпущенного через Vault, — и наоборот.
Подробнее — Администрирование.
Поллинг переотправляет исходный запрос вместо GetCertInitial¶
Поллинг SCEP при каждой попытке переотправляет исходный PKCSReq, а не
использует GetCertInitial (SCEP message type 20). Это работает с
NDES, step-ca и большинством CA, но может не сработать со строго
RFC 8894-совместимыми CA, которые отклоняют повторный PKCSReq после
того, как заявка ушла в PENDING.
Если ваш SCEP CA настроен на строгое соответствие RFC 8894 — это первое,
что стоит проверить при заявках, зависших в ca_pending с ошибками CA.
Подробнее — Эксплуатация.
Сценарии применения и сети¶
Вход в домен Windows: настройку доверия в лесу AD делает администратор¶
Сертификат на карту доводит агент сам: он поднимает смарт-карту на устройстве, кладёт на неё одобренный сертификат, а штатная служба распространения Windows копирует его в личное хранилище пользователя и связывает с картой. Ручных шагов в выдаче нет.
Ручным остаётся другое, и это разовая настройка леса AD, а не работа с каждым устройством: публикация корневого сертификата в хранилище NTAuth и распространение доверия к нему. Для этого нужны права администратора домена, и делается это один раз на срок жизни УЦ.
Подробнее — Вход в домен по смарт-карте → Пределы и нюансы. Остальные пределы этой функции — платформы, RSA-ключ, отзыв через ADCS — там же.
Сетевой профиль, распространяемый через MDM/GPO, агент не удаляет¶
Когда у сети выключен переключатель «Распространять профиль через агента», Alatyr не может программно снять или «забыть» профиль, который распространяется извне (MDM/GPO/config management) — убрать его нужно вручную в той системе, которая его раскатывает.
Подробнее — Wi-Fi и проводной 802.1X → Кто ставит профиль.
Одновременно активной может быть только одна проводная сеть¶
На хосте может быть только один активный профиль 802.1X на Ethernet- интерфейс, поэтому сервер допускает не более одной активной проводной (wired) сети одновременно. Завести несколько wired-записей можно — активной делать только одну.
Подробнее — Wi-Fi и проводной 802.1X → Нюансы и пределы.
Имя RADIUS-сервера по умолчанию не проверяется¶
Пока у сети не задано имя RADIUS-сервера, супликант принимает любой сервер, чей сертификат выписан доверенным УЦ. Это умолчание выбрано осознанно — иначе обновление закрыло бы сеть в каждой инсталляции, где имя не задано, — но закрывать эту проверку надо вручную, на каждой сети.
Подробнее — Wi-Fi и проводной 802.1X → Имя RADIUS-сервера.
Платформенные особенности¶
macOS: аппаратную аттестацию нельзя проверить на стороне сервера до macOS 27¶
На Windows и Linux сервер может проверить, что ключ действительно живёт в
аппаратном хранилище: у TPM есть подписанный производителем EK-сертификат,
а TPM2_Certify доказывает, что представленный ключ находится в том же
чипе. На macOS такой цепочки не существует — Apple не публикует
центр сертификации для Secure Enclave, поэтому «сертификат», который
присылает Mac, самоподписанный: он подтверждает сам себя и не подтверждает
ничего больше.
Практическое следствие: заявку с macOS сервер не может отличить от
корректно оформленной заявки, отправленной чем угодно — уровень аттестации
full на этой платформе достижим без какого-либо оборудования. Для
Windows и Linux это не так.
Единственный механизм Apple, который закрывает этот разрыв — App
Attest: он подтверждает, что запрос пришёл с подлинного оборудования
Apple, от нашего приложения, без модификаций. Alatyr его поддерживает
(ступень app_attest_enforcement в разделе «Настройки → Безопасность»),
но:
App Attest доступен на Mac только начиная с macOS 27
До macOS 27 App Attest на компьютерах Mac не существовал — API был,
но isSupported возвращал false на любом Mac, что подтверждала и
документация Apple, и техподдержка разработчиков Apple вплоть до мая
2026 года. Возможность появилась в macOS 27.
Это значит, что любой Mac с macOS 26 и старше не может получить ключ
App Attest в принципе, независимо от настроек сервера, подписи агента
и конфигурации в портале Apple. Ступень required в таком парке
отклонит все маки без исключения, а ступень advisory покажет их как
«ещё не перешли на App Attest» — хотя перейти они не могут.
Поднимать ступень выше off имеет смысл только после того, как парк
маков обновлён на macOS 27. Сама возможность аттестации на macOS 27
дополнительно требует включённых Full Security Mode и System Integrity
Protection — оба включены по умолчанию.
Пока App Attest недоступен, барьером для macOS остаются ручное одобрение заявок и corp-ownership-проверка. Практические меры перечислены в Администрировании, раздел «Аутентификация источника заявки».
macOS: headless-машины без активной GUI-сессии не получают сертификат¶
Ключ подписи на macOS создаётся в Secure Enclave и живёт в data-protection
keychain залогиненного пользователя, которую держит secd — а secd
работает только внутри GUI-сессии. На машине без активного интерактивного
логина сертификат не выпускается.
Практически это исключает полностью headless Mac (например, в серверном или CI-сценарии) без хотя бы одной активной графической сессии.
Подробнее — Установка → Агент → macOS.
Linux: без TPM агент использует программный fallback-ключ¶
Ключ на Linux создаётся в TPM 2.0 через tpm2-pkcs11, но это soft
dependency: без модуля или при отсутствии TPM агент использует
программный fallback-ключ, хранящийся на диске, вместо аппаратного.
Практически это означает более слабую гарантию защиты ключа на машинах
без TPM или без установленного tpm2-pkcs11 — ключ не резидентен в
аппаратном хранилище. Мера — использовать целевые машины с TPM 2.0 и
установленным tpm2-pkcs11.
Подробнее — Агенты → Linux.