ADR 0019: Делегирование управления точными сервисными аккаунтами

Статус: accepted. Дата: 2026-09-24.

Контекст

ADR 0017 допускает только локальный bootstrap для управления credentials. Передача его секрета интеграциям даёт избыточные полномочия. Нужен завершённый ограниченный профиль ADR 0016 без wildcard ресурсов, скрытых цепочек доверия и расширения прежнего administrator.

Решение

Bootstrap назначает конкретному активному, выпущенному им key ID управление конкретным чужим account ID. Grant содержит отдельные семь administration actions и ceiling точных repository bindings. Data rights оператора и административный ceiling независимы. Создание аккаунтов и назначение grants остаются root-only.

Вся старая policy должна входить в ceiling перед её изменением или enable/disable; новый набор тоже проверяется. Rotate/revoke проверяет сохранённые bindings исходного key, а не только effective intersection. Чтение metadata не ограничено ceiling внутри явно назначенной цели. Право выпуска даёт доступ к новому секрету целевого аккаунта и тем самым доверие в пределах ceiling.

Аккаунты-операторы и цели включённых grants образуют непересекающиеся множества. Самоуправление и переделегирование запрещены; delegated-issued key нельзя назначить операторским. Grant привязан к credential, не наследуется ротацией и не принимается из client Principal. Это ограничивает инцидент конкретным операторским ключом и заставляет явно назначать полномочия его замене.

Миграция 10 добавляет grants и issuer key reference. Активация pending key повторно проверяет issuer, текущий grant, ceiling и срок. Уже активный ключ самостоятельный: снятие grant не вызывает каскадный отзыв. Его срок ограничен issuer при выдаче/активации; дальнейший отзыв требует явной операции над ним/его аккаунтом. Это сохраняет работоспособность потребителей при плановой смене оператора и не обещает динамическую иерархию credentials.

Все control mutations повторно проверяют authority после существующей advisory-блокировки 18471/12; изменения и audit в одной транзакции. Чтение — один repeatable-read snapshot без общей блокировки. Списки фильтруются в SQL до LIMIT. Bytes остаются вне control transaction.

CAS сохраняет revision после DELETE через tombstone. Предел 64 хранимых grants на key, 10 000 глобально и 16 ceiling bindings ограничивает время/размер discovery. Tombstones учитываются в лимитах; archival пока отсутствует. HTTP/SDK/OpenAPI описаны в runbook.

Последствия и альтернативы

Простой общий admin-флаг отвергнут: он не ограничивает цель и выдаваемые права. Рекурсивное пересечение дерева делегирования отложено: нужны определённые правила cascade revocation, транзитного сокращения, циклов, expiry и стоимости каждого запроса. Импорт старого ownership и selectors не включены.

Control writes сериализуются как прежде; чтения не блокируют друг друга этой блокировкой. Это приемлемо для ограниченного administrative API, но не доказательство распределённой пропускной способности. Readiness требует migrations 8/9/10. Additive схема сохраняет прежние данные, однако mixed-version rollout не допускается из-за старого activation поведения. Выдача bytes, основной storage lifecycle и заявленный HA-профиль не меняются.

Приёмка

Интеграционные тесты проверяют happy path и отрицательные права, отсутствие повышения/самоуправления/цепочек, pending activation после отзыва, явную независимость active keys, отсутствие наследования grants при rotation, CAS/tombstone и пределы под конкуренцией. Проверяются stale authority после ожидания lock, SQL filtering до pagination и rollback при отказе audit. Полный HTTP inventory включает новые routes и HEAD; схемы ответов компилируются и проверяются на реальных ответах.