Обычно люди входят в Stronghold через OIDC. Если провайдер идентификации (в DP — Dex и внешний IdP) недоступен или ошибочно настроен, никто из администраторов не сможет войти. Аварийный доступ — заранее подготовленный, редко используемый и строго контролируемый способ войти в такой ситуации.

Цель

Подготовить два уровня аварийного доступа:

  • уровень 1 — отдельная учётная запись userpass с административной политикой, пароль к которой хранится в запечатанном конверте;
  • уровень 2 — процедура generate-root на случай, когда уровень 1 не помогает.

Настроить аудит использования и процедуру ротации после применения.

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

Перед началом подготовьте:

  • Токен Stronghold с административными правами.
  • Хранилище для конвертов (сейф) и не менее двух ответственных за доступ к нему.
  • Сведения о держателях долей ключа распечатывания или восстановления и пороге их кворума.
  • Для аудита — настроенное устройство аудита. Подробнее — в разделе «Аудит».

Шаг 1. Создайте аварийную политику

Политика должна позволять восстановить вход, но не обязана давать полный доступ к секретам. Пример политики для восстановления методов аутентификации и политик:

d8 stronghold policy write break-glass - <<'POLICY'
path "sys/auth" {
  capabilities = ["read"]
}
path "sys/auth/*" {
  capabilities = ["create", "read", "update", "delete", "sudo"]
}
path "auth/*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}
path "sys/policies/acl/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
path "identity/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
path "sys/mounts" {
  capabilities = ["read"]
}
POLICY

Расширяйте политику только тем, что действительно нужно при аварии.

Шаг 2. Создайте аварийную учётную запись

Создайте отдельную учётную запись userpass для аварийного входа.

  1. Включите отдельный экземпляр метода userpass, чтобы его использование легко отличалось в журналах аудита:

    d8 stronghold auth enable -path=breakglass userpass
  2. Сгенерируйте длинный случайный пароль на изолированной рабочей станции:

    openssl rand -base64 32
  3. Создайте пользователя с коротким сроком жизни токена:

    d8 stronghold write auth/breakglass/users/breakglass-1 password="<BREAKGLASS_PASSWORD>" token_policies=break-glass token_ttl=1h token_max_ttl=4h

    <BREAKGLASS_PASSWORD> — пароль, сгенерированный на предыдущем шаге.

  4. Запишите пароль на бумаге, положите в конверт, запечатайте, подпишите и поместите в сейф. Для правила двух лиц разделите пароль на две части и храните их в разных конвертах у разных ответственных.

  5. Удалите пароль из истории командной оболочки и буфера обмена.

Блокировка после неудачных попыток входа включена для userpass по умолчанию. Злоумышленник может намеренно заблокировать аварийную учётную запись; учитывайте это в процедуре и при необходимости создайте вторую учётную запись breakglass-2 в отдельном конверте.

Не используйте для аварийного доступа долгоживущие токены. Срок жизни токена ограничен системным максимальным TTL, и такой токен может истечь незаметно.

Шаг 3. Подготовьте процедуру generate-root

Если аварийная учётная запись недоступна, root-токен можно сгенерировать только с участием кворума держателей долей ключа распечатывания (при auto-unseal — ключа восстановления).

  1. Инициатор запускает процедуру. В ответе возвращаются nonce и otp:

    d8 stronghold operator generate-root -init
  2. Каждый держатель доли вносит её, указав nonce:

    d8 stronghold operator generate-root -nonce=<NONCE>

    <NONCE> — значение nonce из вывода команды с -init.

    Команда запрашивает долю ключа интерактивно. Когда кворум набран, выводится encoded_token.

  3. Инициатор расшифровывает токен:

    d8 stronghold operator generate-root -decode=<ENCODED_TOKEN> -otp=<OTP>

    Плейсхолдеры:

    • <ENCODED_TOKEN> — значение encoded_token, выведенное после набора кворума;
    • <OTP> — значение otp из вывода команды с -init.

Если процедура запущена по ошибке, отмените её командой d8 stronghold operator generate-root -cancel. Опишите процедуру в регламенте, укажите, кто держит доли и как их собрать.

В DP в режиме Automatic ключ распечатывания и root-токен хранятся в секрете stronghold-keys неймспейса d8-stronghold. Доступ к этому секрету равнозначен полному доступу к Stronghold: ограничьте его через RBAC и контролируйте по журналам аудита Kubernetes. Подробнее — в разделе «Настройка».

В DP в режиме Automatic Stronghold инициализируется с одной долей ключа распечатывания и порогом 1, поэтому для кворума generate-root достаточно одной доли. Эта доля хранится в поле unsealKey секрета stronghold-keys, а исходный root-токен — в поле rootToken. Для generate-root возьмите долю из секрета (или из его копии) и введите её на шаге 2. После процедуры храните новый root-токен как аварийный и отзывайте его после использования (d8 stronghold token revoke -self). Модуль использует root-токен из stronghold-keys только для миграции роли Kubernetes auth, если его собственный вход в Stronghold не удался; если поле rootToken пустое или секрета нет, этот шаг пропускается. Поэтому после первичной настройки root-токен можно отозвать и удалить из секрета.

Шаг 4. Настройте контроль использования

Каждое использование аварийного доступа должно вызывать оповещение.

  1. Убедитесь, что устройство аудита включено:

    d8 stronghold audit list
  2. Настройте в SIEM оповещение о любом входе через аварийный путь. Признаки в журнале аудита:

    • request.path равен auth/breakglass/login/breakglass-1;
    • request.path начинается с sys/generate-root;
    • в auth.policies присутствует root.

    Пример поиска по файловому журналу:

    jq -c 'select(.request.path | startswith("auth/breakglass/login") or startswith("sys/generate-root"))' /var/log/stronghold_audit.log

Использование при аварии

При аварии выполните следующие шаги:

  1. Два ответственных вскрывают конверт и фиксируют время и причину в журнале инцидента.

  2. Войдите:

    d8 stronghold login -method=userpass -path=breakglass username=breakglass-1
  3. Восстановите конфигурацию входа (например, auth/oidc_deckhouse/config) и проверьте, что обычный вход работает.

  4. Отзовите аварийный токен: d8 stronghold token revoke -self.

Ротация после применения

После каждого использования, даже учебного:

  1. Смените пароль и создайте новый конверт:

    d8 stronghold write auth/breakglass/users/breakglass-1/password password="<NEW_PASSWORD>"

    <NEW_PASSWORD> — новый случайный пароль.

  2. Отзовите все токены, выданные через аварийный путь:

    d8 stronghold lease revoke -prefix auth/breakglass/
  3. Если использовался generate-root, отзовите root-токен сразу после завершения работ:

    d8 stronghold token revoke <ROOT_TOKEN>

    <ROOT_TOKEN> — root-токен, полученный через generate-root.

  4. Проанализируйте журнал аудита за период использования и приложите выгрузку к отчёту об инциденте.

Проверка

Проводите учебное применение не реже раза в полгода:

  1. Войдите аварийной учётной записью на тестовом или рабочем кластере.
  2. Проверьте набор прав: d8 stronghold token capabilities sys/auth/oidc_deckhouse.
  3. Убедитесь, что в SIEM пришло оповещение.
  4. Выполните ротацию после применения.

Очистка

Если аварийный доступ больше не нужен (например, при выводе кластера из эксплуатации):

d8 stronghold auth disable breakglass
d8 stronghold policy delete break-glass

Уничтожьте конверты с паролями по акту.

Дополнительные ресурсы