Переменные и секреты — одна сущность
Не два хранилища, а одна запись с флагом видимости: plain видна всем с доступом к проекту, masked отдаётся по явному запросу с записью в аудит, restricted не показывается человеку вовсе.
Хранилище секретов и переменных, из которого сервисы забирают значения сами. Ниже — что именно умеет система; где проходит граница её гарантий, написано на странице о безопасности.
Не два хранилища, а одна запись с флагом видимости: plain видна всем с доступом к проекту, masked отдаётся по явному запросу с записью в аудит, restricted не показывается человеку вовсе.
current читают потребители, previous даёт откат в одно действие, pending хранит значение, которое создано, но ещё не применено. Откат публикует старое значение новой версией — история остаётся монотонной.
Universal Auth обменивает client_id и secret на короткоживущий токен; enrollment-токен живёт минуты и ровно одно использование. Повторный обмен означает утечку — он отклоняется атомарно и поднимает тревогу.
Identity привязана к проекту, окружению и, если нужно, к списку ключей: сервису биллинга можно выдать DB_*, а не всё окружение. Дополнительно — список разрешённых адресов.
create → set → test → finish, идемпотентно и с возобновлением с любой фазы. Новое значение становится текущим только после успешной проверки.
Изменения и доступы, связанные хеш-цепочкой. В журнал попадают имена ключей и HMAC значения — достаточно, чтобы увидеть изменение, и недостаточно, чтобы узнать значение.
Схема описывает, какие ключи обязательны и в каких средах. Команда validate сверяет её с тем, что реально лежит в сервисе, и останавливает деплой, если ключа не хватает — до рантайма, а не после. Проверка идёт по именам, значения не раскрываются.