Аутентификация API

Автоматизация — полноправный гражданин mesh, — но и аутентифицироваться она должна соответственно: с помощью ограниченных по области учётных данных, которые можно ротировать или отзывать без затрагивания базовой идентичности mesh.

Ограниченные учётные данные для автоматизации

Используйте ограниченные по области учётные данные для автоматизации и избегайте широких операторских токенов. Сборочному конвейеру не нужны права подключения; скрипту мониторинга не нужен доступ на запись ACL. Учётные данные должны отображаться на границы организации, продукта и окружения , чтобы интеграцию можно было ротировать или отзывать без влияния на что-либо ещё, — и чтобы журнал аудита мог точно указать, какой токен что сделал.

Типовой запрос ограниченного токена

  # create a token scoped to the builders team, git surface only
  POST /v1/auth/tokens
  {
    "name": "ci-runner-main",
    "scope": { "team": "builders", "surface": "git", "environment": "production" },
    "expires": "2026-11-01T00:00:00Z"
  }

REST API координатора по пути /v1

Координатор предоставляет свой control plane по пути /v1 : auth, nodes, peers, ACL, relays, ingress, MeshCA, firewall, telemetry, snapshots, monitoring и WAF. Дашборд проксирует те же API — всё, что вы можете сделать в UI, автоматизация может сделать через API, при тех же RBAC и разрешениях уровня методов.

Типовой вызов координатора

  curl -s https://coordinator.rizoma.mesh/v1/nodes \
    -H "Authorization: Bearer <scoped-token>" \
    -H "Accept: application/json"

API Webpanel по пути /api/v1

Управляющий API Webpanel находится по пути /api/v1 и защищает себя с помощью сессионных cookies, CSRF-защиты, ограничения частоты и RBAC, с метриками Prometheus для самой поверхности API. Если координатор обслуживает межмашинную автоматизацию, то Webpanel предназначен для браузерных сессий и административного инструментария — используйте сессионные потоки для людей и ограниченные токены для скриптов.

Обе поверхности предоставляют эндпоинты проверки состояния ( healthz, readyz ), чтобы балансировщики нагрузки и мониторинг могли отличить работающий процесс от готового сервиса.

Ротация и отзыв

Планируйте ротацию как часть интеграции, а не как реагирование на инцидент. Токены со сроками действия вынуждают к плановому обновлению; отзыв должен быть возможен без затрагивания базовой идентичности mesh — отзыв ограниченного токена никогда не должен требовать переподключения узлов или перевыпуска сертификатов. При изменении области интеграции выпустите новый токен и выведите старый из обращения в тот же день.

Широкие токены — это будущие отчёты об инцидентах. Если компрометация вынуждает вас ротировать всё из-за того, что один токен мог делать всё, — проблемой был сам токен. Сначала ограничение области, затем частая ротация, а проверку обоих пунктов выполняет журнал аудита .

Назад Audit & Logging Далее Node Management