aws, aws-practice, devops, kubernetes

AWS Восстановление данных Vault из бэкапа (перенос между aws аккаунтами с разными KMS ключами)

Thank you for reading this post, don't forget to subscribe! 

  • Вос­ста­нов­ле­ние снап­шо­та пол­но­стью заме­ня­ет теку­щее хра­ни­ли­ще Vault содер­жи­мым снапшота.

  • После вос­ста­нов­ле­ния сно­ва ста­но­вят­ся валид­ны­ми root-токен и recovery-клю­чи от исход­но­го кла­сте­ра (того, где сни­ма­ли снапшот).

  • Если исход­ный кла­стер исполь­зо­вал AWS KMS (воз­мож­но, в дру­гом реги­оне), на вре­мя вос­ста­нов­ле­ния пона­до­бит­ся доступ к ста­ро­му KMS-клю­чу, что­бы рас­шиф­ро­вать данные.

  • Во вре­мя мигра­ции типа seal вы уви­ди­те Seal Migration in Progress: true — это нор­маль­но, пока вы не завер­ши­те мигра­цию на каж­дом pod’е.

 

1) Поднимите пустой кластер (или один узел)

Раз­вер­ни­те «чистый» Vault (в при­ме­ре — деп­лой из инфра­струк­тур­но­го репо­зи­то­рия через Terragrunt). Пока кла­стер не ини­ци­а­ли­зи­ро­ван, pod’ы будут пере­за­пус­кать­ся (про­ве­ры пада­ют) — это ожи­да­е­мо.

Вре­мен­ная реко­мен­да­ция (опци­о­наль­но): выклю­чить probes на вре­мя восстановления

Поз­же вер­нё­те probes обрат­но через Helm values.

2) Выполните минимальную начальную инициализацию (временно)

Это нуж­но лишь для того, что­бы зара­бо­та­ли API/CLI для коман­ды вос­ста­нов­ле­ния (снап­шот всё рав­но пере­за­пи­шет данные).

Вре­мен­ные клю­чи и root-токен из это­го шага не при­го­дят­ся после восстановления.
Будут исполь­зо­вать­ся учёт­ные дан­ные снапшота.

3) Скопируйте снапшот в pod

4) Дайте временный доступ к старому KMS (если снапшот зашифрован в другом регионе)

Если исход­ный Vault исполь­зо­вал AWS KMS в eu-central-1, выдай­те роли pod’а вре­мен­ные пра­ва на ста­рый ключ:


Если в окру­же­нии pod’а гло­баль­но уста­нов­ле­но AWS_REGION=us-east-1, то настрой­ка реги­о­на в seal "awskms" { region = "eu-central-1" } может быть пере­опре­де­ле­на пере­мен­ной окру­же­ния. Вре­мен­но задай­те нуж­ный реги­он явно через зна­че­ния чарта:

Пере­мен­ная окру­же­ния AWS_REGION име­ет при­о­ри­тет над region в бло­ке seal "awskms" {}.
Это тре­бу­ет­ся толь­ко на вре­мя вос­ста­нов­ле­ния, если ста­рый ключ в дру­гом регионе.

5) Восстановите Raft-снапшот

Выпол­ни­те на одном pod’е (лиде­ре после шага 2):

После вос­ста­нов­ле­ния:

  • Про­цесс­ные настрой­ки (vault.hcl, env, Helm values) оста­нут­ся как в деп­лое.

  • Storage data/policies/auth/mounts будут точ­ной копи­ей исход­но­го кластера.

  • С это­го момен­та исполь­зуй­те root-токен и recovery-клю­чи от исход­но­го кла­сте­ра (источ­ни­ка снапшота).

6) Выполните unseal и завершите миграцию seal

Если в снап­шо­те был Shamir или KMS в дру­гом реги­оне, вы, ско­рее все­го, увидите:

Запу­сти­те мигра­цию на каж­дом pod’е:

  • Seal Migration in Progress: true озна­ча­ет, что не все pod’ы завер­ши­ли миграцию.

  • Когда каж­дый pod будет мигри­ро­ван, вы увидите:

    • Seal Migration in Progress: false

    • Sealed: false (при усло­вии, что KMS доступен)

7) Переключитесь на новый KMS в целевом регионе

Когда вос­ста­нов­ле­ние про­шло успешно:

  1. Обно­ви­те блок seal на ваш целе­вой KMS/регион (при­мер для us-east-1):

  1. Убе­ри­те вре­мен­ную пере­мен­ную окру­же­ния, кото­рой фик­си­ро­ва­ли ста­рый регион:

  1. Уда­ли­те вре­мен­ные пра­ва досту­па к ста­ро­му KMS-ключу.

  2. Перезапустите/переразверните Vault.

  3. Сно­ва уви­ди­те Seal Migration in Progress: true — это ожи­да­е­мо при смене KMS/региона.

Повто­ри­те на каж­дом pod’е:

Ожи­да­е­мое ито­го­вое состояние:

  • Seal Type: awskms

  • Sealed: false

  • Seal Migration in Progress: false (поле может и вовсе отсутствовать)

8) Включите probes

Реко­мен­ду­ет­ся вер­нуть readiness/liveness через Helm values (а не через kubectl patch):

Убе­ди­тесь, что убра­ли все вре­мен­ные настрой­ки (напри­мер, AWS_REGION для ста­ро­го региона).

9) Проверьте доступ к данным

Исполь­зуй­те root-токен от исход­но­го кла­сте­ра (источ­ни­ка снапшота):

Заод­но мож­но про­ве­рить доступ­ность дан­ных через UI.

Полезная ссылка