Известные ограничения¶
Эта страница собирает в одном месте ограничения Alatyr, которые уже задокументированы на сайте по отдельности — при отказоустойчивости, отзыве устройств и SSH-ключей, SCEP-интеграции и платформенном поведении агента. Каждый пункт ниже — краткое резюме; полное описание механизма, включая то, почему он устроен именно так, находится на странице, на которую ведёт ссылка.
Масштабирование и отказоустойчивость¶
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-ключей
(регистрация по-прежнему создаётся, но остаётся в статусе pending), но
не отзывает уже одобренные — они продолжают выдаваться через Keyholder
API, пока администратор не отзовёт каждый ключ отдельно.
Практически это значит, что отозванное устройство может сохранять рабочий SSH-доступ через ранее одобренные ключи. Чтобы отозвать SSH-доступ вместе с устройством, ключи устройства нужно получить и отозвать явно, по одному.
Подробнее — SSH Key Registry.
Автоодобрение SSH-ключей доверяет принципалу, который заявляет сам агент¶
Сервер не связывает устройство с конкретным человеком — такой привязки
в модели данных нет. При включённом автоодобрении единственная проверка
регистрации ключа — совпадение заявленного principal со списком
разрешённых значений; сам principal — поле, которое присылает клиент.
Практически: при включённом автоодобрении любое устройство с валидным enrollment-токеном получит рабочий SSH-доступ под любым принципалом из allowlist, без единого человеческого решения. Поведение по умолчанию — ручное одобрение, а не автоодобрение.
Подробнее — SSH Key Registry.
IP-allowlist Keyholder API не ограничивает, какой принципал запрашивается¶
Allowlist ограничивает, откуда можно обращаться к /keyholder/keys, но
не то, ключи какого принципала запрашиваются. Любой хост внутри
разрешённой подсети может запросить ключи произвольного принципала, а
не только «своего».
Для тех, кому одного allowlist недостаточно, есть опциональный bearer-токен сервера, дополнительно защищающий эндпоинт.
Подробнее — SSH Key Registry.
Блокировку устройства можно обойти, заявив другой серийный номер¶
Блокировка привязана к строке устройства, которая определяется по
серийному номеру, заявленному самим агентом. Устройство, физически
контролирующее собственный агент, может обойти блокировку, заявив
другой серийный номер при повторном enroll (для placeholder-серийников
— просто не предъявив continuity_key).
Готового способа закрыть этот обход сегодня нет. Настройки
TPM_REJECT_UNATTESTED и TPM_REQUIRE_AK_CERTIFY повышают требования к
аттестации ключа, но не связывают заявленный серийный номер с конкретным
железом — устройство с исправным TPM может пройти любую из этих проверок
под новым серийным номером. Правильное решение — привязка блокировки к
аппаратной идентичности — намечено как доработка.
Подробнее — Администрирование.
SCEP¶
Нет операции отзыва сертификата¶
SCEP-протокол не имеет операции revoke. Кнопка отзыва в Admin UI
отключена для 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: установку сертификата на смарт-карту доводит администратор¶
Агент создаёт TPM Virtual Smart Card и отправляет запрос на сертификат для входа в домен Windows, но одобренный сертификат на карту сам не устанавливает — на текущем этапе это делает администратор вручную. Это ограничение определяет применимость всего сценария.
Подробнее — Сценарии применения → Вход в домен Windows по смарт-карте.
Сетевой профиль, распространяемый через MDM/GPO, агент не удаляет¶
Когда для сети включён переключатель «не устанавливать профиль агентом», Alatyr не может программно снять/забыть профиль, который распространяется извне (MDM/GPO/config management) — убрать его нужно вручную в той системе, которая его раскатывает.
Подробнее — Агенты → Отключение установки сетевых профилей агентом.
Одновременно активной может быть только одна проводная сеть¶
На хосте может быть только один активный профиль 802.1X на Ethernet- интерфейс, поэтому сервер допускает не более одной активной проводной (wired) сети одновременно. Завести несколько wired-записей можно — активной делать только одну.
Подробнее — Администрирование → Сети (Wi-Fi + проводной 802.1X).
Платформенные особенности¶
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.