Казалось бы, простая задача: перенести секреты между хранилищами Vault. Но на практике возникают сложности. И их столько, что мы в Orion soft разработали свою утилиту для миграции – StarVault Shuttle.

В этой статье я расскажу, почему мы остановились на таком решении и как работает наша утилита. Также поговорим про подводные камни миграции через бэкапы и обсудим другие задачи «переезда» на новый Vault, например, необходимость «уборки» в хранилище.

Мы уже рассказывали, как решили создать собственное хранилище секретов StarVault. Наши партнеры и заказчики, которым актуальна миграция с HashiCorp Vault, спрашивали: как быстро и без проблем перенести секреты из одного Vault в другой. 

Для этого существует три способа:

  1. Перенести все руками — долго и трудоемко; 

  2. Сделать бэкап и восстановить — быстрее, но есть нюансы;

  3. Взять утилиту, которая все сделает сама.

Как будем мигрировать

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

Миграция через бэкап тоже не всегда удобна. Вы можете сделать резервную копию нужных секретов, но загружать ее придется с учетом Storage Backend. Хранение секретов может быть построено на разных технологиях: файловая система, Consul, etcd, объектное хранилище. Если Storage Backend будет отличаться, придется пошаманить, чтобы выгрузить бэкапы, например, из объектного хранилища, и разместить их уже в Integrated Storage (Raft).

Если миграция включает СУБД, вам понадобится специалист для выполнения Backup/Restore на уровне базы данных. Можно поискать отдельного человека, который сделает его для таблицы в PostgreSQL. А можно вызвать шаттл ;)

Что такое StarVault Shuttle

Мы решили разработать свое готовое решение для миграции секретов с исходного хранилища Vault. Целью было сделать миграцию максимально комфортной для пользователя. Мы взяли открытое API Vault, написали код на Python и Flask. Для взаимодействия с Vault задействовали клиент HVAC. 

Shuttle поддерживает два режима миграции секретов: онлайн и офлайн.

Онлайн-миграция

Здесь все просто: 

  1. Запускаем утилиту;

  2. Вводим настройки и реквизиты доступа;

  3. Получаем доступ к исходному Vault.

4. Выбираем секреты для миграции;

5. Нажимаем кнопку миграции. Если параметры целевого хранилища были введены правильно, секреты тут же появляются в новом Vault. На миграцию 100 секретов уходит несколько секунд. 

Миграция происходит автоматически.

Офлайн-миграция

Этот режим полезен, когда контуры со старым и новым Vault изолированы друг от друга. В этом случае нужно выгрузить секреты и загрузить их в новой системе. Но чем это отличается от обычного Backup/Restore?

На первый взгляд, решение похоже на бэкапы. Но есть важное отличие: вам не нужно думать, какой бэкенд используется в новом хранилище. Shuttle отдает секреты через Vault API, а хранилище само размещает их на своем бекэнде, каким бы он ни был.  

  1. Выбираем нужные секреты в дереве секретов; 

  2. Нажимаем «Экспорт». Сохраняется зашифрованный файл (алгоритм AES-256);

  1. Записываем файл на флешку и переносим во второй контур;

  2. Снова через StarVault Shuttle загружаем секреты в новое хранилище.

Как работать с Shuttle

Shuttle предлагает два метода работы — через консоль (CLI) и через веб-интерфейс.

Работа через консоль

Для многих сисадминов самый простой способ — запустить скрипт через CLI:

# Подключение
python start.py --src-vault <src_vault_url> --src-token <src_token> \
--src-key <src_key> --dst-vault <dst_vault_url> \
--dst-token <dst_token> --dst-key <dst_key>
# Выбор Secret Engines из доступных
Available Secret Engines:
1. cubbyhole/
2. identity/
3. kubernetes/
4. kv_test_v1/
5. kv_test_v2/
6. ldap/
7. sys/
8. transit/

Enter the numbers of the engines you want to export separated by spaces: 4 5 8
# Информирование о процессе миграции
KV secrets created successfully in kv_test_v1/
KV secrets created successfully in kv_test_v2/
Transit key testkey created successfully in transit/
Transit key testkey2 created successfully in transit/

Работа через веб-интерфейс

С помощью веб-интерфейса можно:

  • Контролировать процесс миграции на каждом этапе;

  • Выбирать, какие именно секреты переносить в новое хранилище;

  • Избавляться от устаревших или ненужных данных.

Чем больше миграций, тем актуальнее задача «уборки» в хранилище. Ведь в Vault часто остаются уже никому не нужные секреты, устаревшая информация и другие артефакты. Они, может, и не мешают, но зачем переносить их в новый Vault?

Shuttle позволяет выбрать только нужные секреты для миграции.

Какие секреты поддерживаются

Сейчас утилита поддерживает следующие Secret Engines:

  • Key-Value (KV): версии 1 и 2, конфигурация и kv-секреты;

  • SSH: конфигурация и роли;

  • Transit: конфигурация и ключи;

  • LDAP: конфигурация, роли и библиотеки;

  • Kubernetes: конфигурация и роли;

  • PKI Certificates: конфигурация, роли, сертификаты и ключи;

  • Databases: конфигурация, соединения и роли.

По некоторым Secret Engines еще ведутся доработки:

  • SSH. Сейчас переносятся только конфигурации ролей. Мы работаем над миграцией сертификатов;

  • Transit. Пока мигрируют только конфиги. В ближайшее время добавим миграцию самих ключей шифрования.

Одна утилита vs. люди с терпением

Shuttle упрощает и ускоряет процесс миграции секретов между Vault'ами. Вы можете использовать любое хранилище, поддерживающее Vault API. 

С Shuttle не потребуется привлекать к задаче специалиста по СУБД или человека, умеющего делать бэкапы, или кого-то для ручной миграции с огромным терпением и таким же количеством времени. 

Еще наша утилита поможет:

  • Провести «уборку» в хранилище;

  • Сменить бэкенд;

  • Объединить Vault'ы;

  • Перейти на новую платформу.

И все это с минимальными затратами времени 

А что думаете вы? Нужна ли вам такая утилита? Если да, поделитесь в комментариях, какие дополнительные функции хотели бы в ней видеть?

Комментарии (3)


  1. Ign0r
    05.09.2024 03:49
    +2

    При переносе Secret Engines "PKI Certificates", что произойдёт в случае наличия объекта RootCA с неэкспортируемым приватным ключём?


  1. PStepanov90
    05.09.2024 03:49

    @MaxMorar политики, indentity и настройки IDP предполагается переносить руками?


  1. trublast
    05.09.2024 03:49

    Немного странно в 2024г подключаться к Vault по http )

    А если говорить про https - кастомные сертифкаты поддерживаются? А валидируются? Как передать CA для src и для dst?

    Чем не устроила, например, https://github.com/jonasvinther/medusa для миграции данных, через api?
    Или встроенный функционал по миграции бэкендов https://developer.hashicorp.com/vault/docs/commands/operator/migrate ?