Модель данных
Сущности, из которых складывается любая конфигурация, и слова, которыми они называются везде: в API, в кабинете и в этой документации.
Организация, проект, окружение
Организация — граница биллинга и участников. Внутри неё проекты, внутри
проектов окружения (dev, staging, production и любые свои — по
умолчанию не создаётся ни одного). Записи живут в окружении: одно и то же
имя ключа в разных окружениях — разные значения, и это нормальный,
ожидаемый случай.
Запись: переменная или секрет
Хранилище одно, а поведение задаёт видимость:
| Видимость | Кто видит значение | Когда использовать |
|---|---|---|
plain | все, у кого есть доступ к проекту | уровень логирования, URL внешнего сервиса |
masked | по явному запросу, с записью в аудит | пароли, токены, ключи API |
restricted | только identity, человеку — никогда | ключи, которые не нужны людям вовсе |
Имя ключа — [A-Z][A-Z0-9_]*, до 128 символов. Переменная (var) обязана
быть plain, секрет — masked или restricted; тип и видимость ключа
обязаны совпадать во всех окружениях проекта.
У записи может быть срок жизни (expiresAt): за некоторое время до
истечения сервер поднимает событие secret.near-expiry в журнале и
вебхук.
Версии и метки
Каждое изменение значения создаёт новую версию. Указатели записи показывают, какая версия чем является:
current— то, что читают потребители;previous— предыдущее значение, откат в одно действие;pending— значение, которое уже создано ротацией, но ещё не применено (см. ротацию).
Откат не переставляет указатели, а публикует старое значение новой версией: история остаётся монотонной, и по ней видно, что откат вообще был.
Сервис и identity
Сервис — то, что вы деплоите: воркер, API, cron. Контейнер. Машинная identity — учётные данные одного сервиса в одном окружении: client ID, способ входа, TTL access-токена и скоуп — проект, окружение и, если нужно, набор ключей.
У identity два режима выдачи: universal (постоянный client secret) и
enrollment (одноразовый enrollment-токен, который сервис при первом
старте меняет на постоянные учётные данные). Оба подробно разобраны на
странице Сервисы и identity.
Роли
Две независимые плоскости. Роль в организации (owner, admin, member)
управляет проектами и участниками, но сама по себе не даёт доступа к
секретам — за это отвечает роль в проекте (admin, member, viewer).
Всё запрещено по умолчанию. Владелец организации может выдать себе
проектную роль, но это явное действие, и оно попадает в журнал.