Rotation Runbook

Обзор

Ротация credential выглядит тривиально — выпустить новый секрет, отозвать старый — и именно поэтому она идёт не так. Повторяющиеся сбои случаются не в самой ротации, а вокруг неё: потребитель, о котором никто не вспомнил; проверка, возвращающая зелёный статус без аутентификации; регрессия валидации, спрятанная за auth-ошибкой; секрет, записанный по пути, о котором не знает ни один другой документ. Этот навык формализует дисциплину, выведенную из реальных ротаций.

Когда использовать

• Ротация любого credential: API-ключ, токен, OAuth client secret, webhook signing secret, TLS-ключ, пароль БД.
• Реакция на утёкший или засвеченный credential (случайный коммит, plaintext-файл, находка аудита).
• Проверка, что прошлая ротация действительно сошлась (truth-check между secret store и producer).

Плейбук

1. Сначала инвентаризация всех потребителей. Перечислите каждое место, где читается credential: CI/CD secret stores, env-файлы, пути secret-manager, конфиги сервисов, cron-задачи, соседние проекты. Truth-check между secret store и producer: «копия потребителя ≠ истина producer» — первая гипотеза при HTTP 401 от ранее работавшей интеграции.
2. Осознанно выберите окно ротации. Предпочитайте grace-окно (двойная валидность), если провайдер его поддерживает; немедленный revoke (grace = 0) обязателен при активной утечке.
3. Верифицируйте только через auth-scoped endpoints. Публичные/каталожные endpoints возвращают успех без аутентификации — ложный зелёный. Обязательно в обе стороны: старый credential → явный отказ; новый → успех. Учитывайте задержку распространения у провайдера.
4. Реплей полного payload producer, а не минимальный probe. Auth-ошибка может маскировать регрессию валидации. Только полный end-to-end реплей доказывает работоспособность интеграции.
5. Секрет — по каноническому пути из schema-документа secret store проекта, никогда — по пути, придуманному на этапе плана.
6. Зафиксируйте ротацию — дата, имя credential, причина, evidence отказа/успеха, обновлённые потребители — в credential-документе проекта.
7. При утечке: сначала ротация, потом scrub истории; локальное зеркало как pre-scrub backup (backup-тег на том же remote уничтожается force-push); верификация scrub из свежего clone.