Автоматическое распечатывание HashiCorp Vault с помощью Transit Secret (Часть 5.1)
ЛЕТОПИСЕЦ КИТЕЖ-ГРАДА
Введение: В данной статье будет рассказано, как достичь автоматического распечатывания Vault после его запуска. То бишь, без ручного ввода ключей для распечатывания, как это было продемонстрировано в предыдущих частях. На самом деле существует несколько вариантов того, как именно Vault можно распечатать. Это и интеграция с облачным поставщиком услуг (например, AWS), и использование Vault версии Enterprise. Однако в этот раз я сделаю упор на возможностях непосредственно самого Vault, что позволит нам ограничиться лишь внешним сервером, на котором всё и будет запущено. При этом само распечатывание будет достигнуто с помощью механизма транзитных секретов. Сперва более подробно поговорим о том, что это такое, а после перейдем непосредственно к реализации сценария, когда у нас один Vault автоматически распечатывает другой. И последнее, я рекомендую ознакомиться с самой первой частью из этого цикла, поскольку в этой статье я не раз буду ссылаться на Vault, который был установлен ранее. Не то чтобы это принципиально важно, но тогда некоторые аспекты могут показаться не столь очевидными.
Основы Transit Secrets Engine: Механизм транзитных секретов выполняет криптографические функции для передаваемых данных. Vault не хранит данные, отправленные в механизм секретов. Данный механизм можно также рассматривать как Cryptography as a Service или Encryption as a Service. Механизм транзитных секретов может подписывать и проверять данные, генерировать хэши и данные HMAC, а также действовать как источник случайных байтов. Основной вариант использования Transit – шифрование данных из приложений с сохранением этих зашифрованных данных в каком-либо первичном хранилище данных. Это снимает с разработчиков приложений бремя правильного шифрования / дешифрования и перекладывает эту нагрузку на Vault. Поддерживается деривация ключей, что позволяет использовать один и тот же ключ для нескольких целей путем получения нового ключа на основе значения контекста, предоставленного пользователем. В этом режиме дополнительно может поддерживаться конвергентное шифрование, которое позволяет использовать одни и те же входные значения для создания одного и того же зашифрованного текста. Механизм Transit также поддерживает управление версиями ключей. Версии ключей, более ранние, чем указанная в строке min_decryption_version, архивируются, а остальные версии ключей относятся к рабочему набору. На данный момент механизм секретов Transit поддерживает следующие типы ключей (все типы ключей также генерируют отдельные ключи HMAC):
AES128-GEM96: AES-GCM со 128-битным ключом AES и 96-битным одноразовым номером. Поддерживает шифрование, дешифрование, получение ключей и конвергентное шифрование.
AES256-GEM96: AES-GCM с 256-битным ключом AES и 96-битным одноразовым номером. Поддерживает шифрование, дешифрование, генерацию ключей и конвергентное шифрование (по умолчанию).
ChaCha20-Poly1305: ChaCha20-Poly1305 с 256-битным ключом. Поддерживает шифрование, дешифрование, получение ключей и конвергентное шифрование.
ED25519: ED25519 поддерживает подпись, проверку подписи и получение ключей.
ECDSA-P256: ECDSA с использованием кривой P-256. Поддерживает подпись и проверку подписи.
ECDSA-P384: ECDSA с использованием кривой P-384. Поддерживает подпись и проверку подписи.
ECDSA-P521: ECDSA с использованием кривой P-521. Поддерживает подпись и проверку подписи.
RSA-2048: 2048-битный ключ RSA. Поддерживает шифрование, дешифрование, подпись и проверку подписи.
RSA-3072: 3072-битный ключ RSA. Поддерживает шифрование, дешифрование, подпись и проверку подписи.
RSA-4096: 4096-битный ключ RSA. Поддерживает шифрование, дешифрование, подпись и проверку подписи.
HMAC: Поддержка генерации и проверки HMAC.
Managed Key: Управляемый ключ, который поддерживает различные операции, в зависимости от используемого решения по управлению ключами.
Примечание: Следующие несколько примеров не относятся непосредственно к настройке автоматического распечатывания Vault. Они представлены здесь исключительно ради общего ознакомления с данным механизмом секретов.
Большинство механизмов необходимо настраивать заранее, прежде чем они смогут выполнять свои функции. И Transit не является исключением. Для активации данного механизма используйте следующую команду:
vault secrets enable transit
Success! Enabled the transit secrets engine at: transit/
По умолчанию имя секрета будет соответствовать имени механизма секретов. Однако это поведение можно изменить, указав во время создания аргумент -path, который позволит задать пользовательское значение для пути:
vault secrets enable -path new-transit transit
Success! Enabled the transit secrets engine at: new-transit/
vault secrets list
Path Type Accessor Description ---- ---- -------- ----------- new-transit/ transit transit_dfabc29e n/a
Далее попробуем создать непосредственно сам ключ шифрования:
vault write -force new-transit/keys/my-key
Key Value --- ----- allow_plaintext_backup false auto_rotate_period 0s deletion_allowed false derived false exportable false imported_key false keys map[1:1705512907] latest_version 1 min_available_version 0 min_decryption_version 1 min_encryption_version 0 name my-key supports_decryption true supports_derivation true supports_encryption true supports_signing false type aes256-gcm96
После того как механизм секретов был настроен, а пользователь или узел обладают токеном Vault с соответствующим разрешением, можно попытаться использовать данный механизм секретов. Например, попробуем зашифровать некоторые данные в виде открытого текста, используя конечную точку /encrypt с именованным ключом:
vault write new-transit/encrypt/my-key plaintext=$(echo "my secret data" | base64)
Key Value --- ----- ciphertext vault:v1:3s6r1m7qFF4E1W/Kov2zjzTkSyIQUrszePw5aqcU0xpiE+KWo7TEwl5MWA== key_version 1
Примечание: Все данные открытого текста должны быть закодированы в формате Base64. Причиной такого поведения является то, что Vault не требует, чтобы открытый текст был текстом как такого. Это может быть двоичный файл, как, например, PDF или изображение. При этом самый простой и безопасный механизм транспортировки таких данных как часть полезной нагрузки JSON – это их кодирование в формате Base64.
Вернемся к выводу, полученный после выполненной ранее команды. Первый префикс (представляет собой хранилище) указывает на то, что он был обернут Vault. V1 говорит о том, что для шифрования открытого текста использовался ключ версии 1, поэтому при смене ключей Vault поймет, какую версию использовать для расшифровки. Остальное представляет собой конкатенацию вектора инициализации и зашифрованного текста в формате Base64. Обратите внимание, что Vault не хранит эти данные. Вызывающая сторона несет ответственность за хранение зашифрованного текста. Когда вызывающему объекту нужен открытый текст, он должен предоставить зашифрованный вариант самому Vault, для последующей расшифровки значения. HTTP API Vault устанавливает максимальный размер запроса в 32 МБ, чтобы предотвратить атаку по типу отказ в обслуживании, но это значение можно изменить. Теперь расшифруем фрагмент данных, используя конечную точку /decrypt с именованным ключом:
vault write new-transit/decrypt/my-key ciphertext=vault:v1:3s6r1m7qFF4E1W/Kov2zjzTkSyIQUrszePw5aqcU0xpiE+KWo7TEwl5MWA==
Key Value --- ----- plaintext bXkgc2VjcmV0IGRhdGEK
Полученные данные были закодированы в формате Base64. Раскодируем их, чтобы получить необработанный открытый текст:
base64 --decode <<< "bXkgc2VjcmV0IGRhdGEK"
my secret data
Теперь поменяем базовый ключ шифрования. Это создаст новый ключ шифрования и добавит его в связку ключей для именованного ключа:
vault write -f new-transit/keys/my-key/rotate
Key Value --- ----- allow_plaintext_backup false auto_rotate_period 0s deletion_allowed false derived false exportable false imported_key false keys map[1:1705512907 2:1705514410] latest_version 2 min_available_version 0 min_decryption_version 1 min_encryption_version 0 name my-key supports_decryption true supports_derivation true supports_encryption true supports_signing false type aes256-gcm96
Будущие шифрования будут использовать этот новый ключ. При этом старые данные всё ещё можно расшифровать с помощью нетривиальных методов. Далее обновим уже зашифрованные данные до нового ключа. Vault расшифрует значение, используя соответствующий ключ в связке ключей, а затем зашифрует полученный открытый текст новым ключом в существующей связке:
vault write new-transit/rewrap/my-key ciphertext=vault:v1:3s6r1m7qFF4E1W/Kov2zjzTkSyIQUrszePw5aqcU0xpiE+KWo7TEwl5MWA==
Key Value --- ----- ciphertext vault:v2:BothYgrWlMhLUbTPdUMeIKsFoM+9jzsGD9aZIcKX3gXkiaguIxPP+5vk2Q== key_version 2
Сей процесс не раскрывает данные открытого текста. Таким образом, политика Vault может предоставить почти ненадежному процессу возможность переобертывать зашифрованные данные, поскольку сам процесс не может получить доступ к данным в виде открытого текста. Более подробно о работе транзитного механизма на примере реального использования рассказывается в этой статье.
Процесс распечатывания и запечатывания Vault: Для более детального понимания того, как правильно настраивать автоматическое распечатывание, необходимо хорошо понимать основные принципы работы данного процесса. В какой-то мере я уже затрагивал эту тему в первой части этого цикла статей. Теперь попробуем погрузиться в данный вопрос чуть глубже. Когда сервер Vault запускают, то он, по умолчанию, всегда стартует в запечатанном состоянии. В этом состоянии Vault знает о том, где и как получить доступ к физическому хранилищу, но он не знает, как его расшифровать. Процесс распечатывания – это процесс получения корневого ключа в виде открытого текста, который необходим для считывания ключа дешифрования. Наличие данного ключа, в свою очередь, позволяет расшифровать данные, хранящиеся в Vault. До этого момента какие-либо операции с Vault практически невозможны. Например, аутентификация, управление таблицами монтирования и т. д. невозможны. Единственная доступная операция – непосредственное распечатывание Vault, а также отображение состояния, в котором он находится. Но почему так? Как уже было отмечено ранее, данные, хранящиеся в Vault, зашифрованы. Для расшифровки данных в Vault необходим ключ шифрования. Сам ключ шифрования также хранится вместе с данными (в связке ключей), но зашифрован другим ключом шифрования, известным как корневой ключ. Поэтому для расшифровки данных Vault должен расшифровать ключ шифрования, для которого требуется корневой ключ. То бишь, процесс распечатывания – это процесс получения доступа к этому корневому ключу. Корневой ключ хранится вместе со всеми другими данными Vault, но шифруется еще одним механизмом: ключом распечатывания или Unseal Key. В итоге мы получаем следующую последовательность: данные в Vault шифруются с помощью ключа шифрования в связке ключей, а сама связка ключей зашифрована корневым ключом, и при этом корневой ключ зашифрован ключом распечатывания. Ниже представлена визуальная схема описанной выше последовательности:
По умолчанию в конфигурации Vault используется печать Шамира. Вместо того, чтобы передавать администратору ключ распечатывания как единый ключ, Vault использует алгоритм, известный как секретный обмен Шамира, для разделения ключа на доли или осколки. Определенное количество осколков необходимо для реконструкции или восстановления ключа распечатывания, который после будет использован для дешифровки корневого ключа. Именно так и организован процесс распечатывания: осколки ключа вводятся по одному (в любом порядке) до тех пор, пока не будет введено достаточное количество для восстановления ключа распечатывания и последующей дешифровки корневого ключа. После того, как узел Vault был распечатан, он остается в таком состоянии до тех пор, пока не произойдет одно из следующих событий:
Vault был запечатан через API.
Сервер Vault был перезапущен.
В Vault возникла неисправная ошибка.
Распечатывание усложняет общий процесс автоматизации Vault. Различные инструменты позволяют легко устанавливать, настраивать и запускать Vault в автоматическом режиме, но его распечатывание с помощью Shamir – это довольно-таки ручной процесс. Поэтому использование автоматического распечатывания весьма уместно. Сама функция автоматического распечатывания была разработана, чтобы помочь снизить операционную сложность при обеспечении безопасности для ключа распечатывания. Эта функция делегирует ответственность за защиту ключа распечатывания, тем самым перекладывая её с конечного пользователя на доверенное устройство или службу. Во время запуска Vault подключается к отвечающему за печать устройству или сервису, и запрашивает у него расшифровку корневого ключа:
Примечание: Вот по этой ссылке вы также можете ознакомиться с рекомендуемыми паттернами при использовании автоматического распечатывания. Причём это касается не только механизма Transit. Там также отражены рекомендации по использованию облачных решений, однако я, пока что, данную тему не затрагиваю, поскольку интеграция с любым облачным провайдером в контексте Vault – это большой и отдельный пласт информации.
Настройка автоматического распечатывания Vault: Итак, тезисно ознакомившись с процессами распечатывания и запечатывания, перейдем непосредственно к настройке автоматического распечатывания Vault. И тут необходимо отметить несколько важных моментов. Во-первых, использование механизма Transit подразумевает, что у вас в распоряжении будет находиться два сервера Vault. Первый, как и предполагается, используется для хранения секретов, тогда как основной задачей второго сервера является получение ключей по распечатыванию первого. Таким образом, каждый раз, после перезапуска или по ещё какой-либо причине, Vault будет находиться в запечатанном состоянии, что вынудит его передать ключи для распечатывания второму серверу. И всё это будет происходить прозрачно для конечного пользователя (при условии что доступность между двумя серверами не была нарушена). Во-вторых, в первой части данного цикла я уже запускал Vault, который был доступен по адресу vault.kitezh.online. В этой части мы вернемся к данному серверу и именно он будет распечатывать наш новый (второй по счету) сервер Vault, который будет запущен по ходу дела. Более того, его новое доменное имя представляет собой значение вида vault-01.kitezh.online. А новый сервер будет запущен по адресу vault-02.kitezh.online. Итого:
- Домен vault-01.kitezh.online – это вторичный сервер, запущенный ранее, который будет распечатывать основной сервер Vault, используемый для хранения секретов.
- Домен vault-02.kitezh.online – это первичный сервер с точки зрения хранения секретов, который будет обращаться к vault-01.kitezh.online за ключами для распечатывания.
В целом данную схему можно изобразить следующим образом:
На адреса и наличие кластеров не стоит обращать внимание, поскольку эти схемы были взяты из официальной документации, и в данном случае они отражают лишь общую тенденцию использования. Поэтому я и упомянул домены, назначенные для используемых мною двух серверов, поскольку они неоднократно будут фигурировать во время конфигурирования. Это далеко не все нюансы, но другие будут раскрыты во время дальнейшего повествования, иначе выйдет та ещё путаница. Думаю с преамбулой покончено. Откроем консоль сервера vault-01.kitezh.online и выполним несколько проверочных команд для понимания ситуации:
Примечание: Ещё раз хотел бы отметить, что настройка текущего сервера Vault (он же vault-01.kitezh.online) была подробно описана в этой статье.
vault status
Key Value --- ----- Seal Type shamir Initialized true Sealed false Total Shares 5 Threshold 3 Version 1.15.2 Build Date 2023-11-06T11:33:28Z Storage Type file Cluster Name vault-cluster-885138a3 Cluster ID 2a9953df-085d-3cce-4c64-6212102983c5 HA Enabled false
systemctl status vault.service
● vault.service - Vault Loaded: loaded (/etc/systemd/system/vault.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2024-01-15 21:42:56 UTC; 3 days ago * * *
Далее необходимо определить адрес сервера и пройти аутентификацию в Vault. У меня всё это уже было сделано, но я напоминаю, что для определения переменных стоит использовать следующие команды:
export VAULT_ADDR="https://vault-01.kitezh.online" # Это адрес моего сервера;
export VAULT_TOKEN="hvs.zEir51sRntznzgzJyFwGfszVg4" # Это мой корневой токен;
Или, в качестве альтернативы, для входа в Vault воспользуйтесь этой командой:
vault login hvs.zEir51sRntznzgzJyFwGfszVg4 # Это мой корневой токен;
Теперь перейдем к настройке механизма секретов. Чтобы включить его, используйте данную команду:
vault secrets enable transit
Success! Enabled the transit secrets engine at: transit/
После исполним следующую команду, чтобы создать ключ шифрования с именем autounseal:
vault write -f transit/keys/autounseal
Key Value --- ----- allow_plaintext_backup false auto_rotate_period 0s deletion_allowed false derived false exportable false imported_key false keys map[1:1705695368] latest_version 1 min_available_version 0 min_decryption_version 1 min_encryption_version 0 name autounseal supports_decryption true supports_derivation true supports_encryption true supports_signing false type aes256-gcm96
Теперь создадим политику с одноименным названием, которая разрешит обновление по путям transit/encrypt/autounseal и transit/decrypt/autounseal:
vault policy write autounseal -<<EOF
path "transit/encrypt/autounseal" {
capabilities = [ "update" ]
}
path "transit/decrypt/autounseal" {
capabilities = [ "update" ]
}
EOF
Success! Uploaded policy: autounseal
И сразу осуществим проверку только что созданной политики:
vault policy list
autounseal default root
В качестве завершения создадим бесхозный клиентский токен, который нельзя продлить. Прикрепим к нему полученную ранее политику и укажем, что период жизни создаваемого токен будет составлять 768 часов, что, примерно, соответствует одному месяцу:
vault token create -orphan -renewable=false -policy="autounseal" -period=768h
Key Value --- ----- token hvs.CAESIDJqWz1Huxgz7jMZD2M7x8AKm9Wj9lStii-bCNR68xbYGh4KHGh2cy5MQXdkbW1odVkySjdrSGg1WElodG5ZN00 token_accessor sziTwBtNk5oNoYLyDpe9CyYR token_duration 768h token_renewable false token_policies ["autounseal" "default"] identity_policies [] policies ["autounseal" "default"]
Но тут возникает первый нюанс. Дело в том, что токен, полученный на стороне vault-01, далее по сценарию используется непосредственно самим vault-02. То бишь, vault-02, используя предоставленный токен, будет обращаться к vault-01, для собственного распечатывания. И если токен протухнет, то в доступе будет отказано, а vault-02 не удастся распечатать до тех пор, пока ключ не будет обновлен. Поэтому крайне важно при создании токена выставить такие для себя параметры и сроки, которые соответствуют вашей политики создания и ведения токенов в Vault. Я уверен, что найдется несколько имплементаций для решения данного вопроса, но в моём случае я ограничусь самым простым вариантом, исключительно для демонстрации. Думаю с этим разобрались. Теперь давайте перейдем к консоли сервера vault-02 и начнем процесс запуска. В данном случае, поскольку второй сервер разворачивается исключительно ради демонстрации автоматического распечатывания, запуск сервера будет выглядеть несколько урезанным, но на функциональность Vault это никак не повлияет. То бишь, без SSL, systemd и т.д. Я просто не хочу повторять без надобности то, что уже было рассмотрено ранее. Итак, сперва необходимо создать конфигурационный файл, в котором будут прописаны как общие параметры, так и те, что относятся к автоматическому распечатыванию:
vi config-autounseal.hcl
disable_mlock = true
ui = true
api_addr = "http://0.0.0.0:8100"
storage "file" {
path = "./vault/data"
}
listener "tcp" {
address = "0.0.0.0:8100"
tls_disable = "true"
}
seal "transit" {
address = "https://vault-01.kitezh.online:443"
token = "hvs.CAESIDJqWz1Huxgz7jMZD2M7x8AKm9Wj9lStii-bCNR68xbYGh4KHGh2cy5MQXdkbW1odVkySjdrSGg1WElodG5ZN00"
key_name = "autounseal"
mount_path = "transit/"
disable_renewal = "false"
# tls_skip_verify = "true" -- если ваш сервер не обладает SSL;
}
Здесь немного задержимся и поговорим о представленном конфигурационном файле. Секция storage и listener уже должны быть знакомы исходя из прошлых статей. Это же касается и первый трех параметров в самом начале. А вот секция seal является новой и именно благодаря ей vault-02 знает о том, к кому и куда именно обращаться за ключами для распечатывания Vault. Сперва мы указываем механизм секретов (в данном случае это Transit). При этом сама «печать» может быть активирована одним из следующих вариантов:
Наличие блока seal "transit" в конфигурационном файле Vault.
Наличие переменной среды VAULT_SEAL_TYPE, установленной как transit.
Рассмотрим каждый из упомянутых параметров в блоке seal более подробно:
Address: Данная строка является обязательной, но её также можно переопределить с помощью переменной VAULT_ADDR. В ней указывается полный адрес доменного имени сервера Vault (если используется один экземпляр) или адрес кластера (если используется кластер).
Token: Данная строка является обязательной, но её также можно переопределить с помощью переменной VAULT_TOKEN. В ней указывается токен, который имеет доступ к механизму секретов Transit. В нашем случае это тот токен, который был сгенерирован ранее на узле vault-01.
Key_name: Данная строка является обязательной, но её также можно переопределить с помощью переменной VAULT_TRANSIT_SEAL_KEY_NAME. В ней указывается имя транзитного ключа, используемый для шифрования и дешифрования данных. В нашем случае это autounseal.
Mount_path: Данная строка является обязательной, но её также можно переопределить с помощью переменной VAULT_TRANSIT_SEAL_MOUNT_PATH. В ней указывается путь монтирования к механизму секретов Transit. В нашем случае это то же имя, что и название самого механизма.
Disable_renewal: Использование данной строки опционально и её также можно определить с помощью переменной VAULT_TRANSIT_SEAL_DISABLE_RENEWAL. Она отключает автоматическое продление токена в случае, если его жизненный цикл управляется каким-либо другим механизмом вне Vault.
Более подробно обо всех параметрах секции seal для механизма секретов Transit можно узнать вот по этой ссылке. Сохранив конфигурационный файл создадим точно такую же директорию, как та, что прописана в самом конфиге, в секции storage. Там будут храниться данные Vault:
mkdir -p ~/vault/data
Теперь попробуем запустить наш сервер. Напоминаю, что выше описанные действия были произведены на узле vault-02. Команда для запуска:
vault server -config=config-autounseal.hcl # Путь к конфигурационному файлу;
==> Vault server started! Log data will stream in below: 2024-01-23T16:58:01.187Z [INFO] proxy environment: http_proxy="" https_proxy="" no_proxy="" 2024-01-23T16:58:01.239Z [INFO] incrementing seal generation: generation=1 2024-01-23T16:58:01.240Z [INFO] core: Initializing version history cache for core 2024-01-23T16:58:01.240Z [INFO] events: Starting event system 2024-01-23T16:58:01.241Z [INFO] core: stored unseal keys supported, attempting fetch 2024-01-23T16:58:01.241Z [WARN] failed to unseal core: error="stored unseal keys are supported, but none were found"
Сервер Vault был запущен и вроде бы всё хорошо, однако в самом конце текущего вывода можно наблюдать строку предупреждения, в которой говорится, что расположение ключей поддерживается, но сами ключи для распечатывания не были найдены. Оно и верно, ведь их ещё даже не существует, поскольку сервер не прошел этап инициализации. В общем на текущий момент это нормальное поведение. Далее необходимо открыть второе окно консоли на узле vault-02 и выполнить следующую команду:
VAULT_ADDR=http://127.0.0.1:8100 vault operator init
Unseal Key 1: RFLRb26zHqmwtZajlXYfNc/mN9FK6qyQbofgy5qT6YYB Unseal Key 2: dDMEp7ul7NwqKfTr59LkKXY2NfZdqF+WgFyL7Lz6ap7M Unseal Key 3: T8YCgacUPltgxL53hbzqCUbAOJP8i3jLpH4WMda4+Rwn Unseal Key 4: Zf4LROdJ+4zkIpbyo2sJBemVCgCLhBC7cuPQ4/rkMzUy Unseal Key 5: XgsNYvv4KQuuz9xuwQUHJdljB2UqpzfmVsFNPpCmoLfZ Initial Root Token: hvs.Km4dSdMYKaYHQ6KSWiH45RgE Success! Vault is initialized
В моём случае сервер Vault запускается на всех нулях с использованием порта 8100. Таким образом, с помощью данной команды были получены ключи для распечатывания и одновременно с этим, если вернутся к журналу сообщений запущенного ранее сервера Vault на узле vault-02, то мы обнаружим следующее:
2024-01-23T17:05:20.532Z [INFO] core.cluster-listener.tcp: starting listener: listener_address=0.0.0.0:8101 2024-01-23T17:05:20.533Z [INFO] core.cluster-listener: serving cluster requests: cluster_listen_address=[::]:8101 2024-01-23T17:05:20.533Z [INFO] core: post-unseal setup starting 2024-01-23T17:05:20.534Z [INFO] core: loaded wrapping token key 2024-01-23T17:05:20.534Z [INFO] core: successfully setup plugin runtime catalog 2024-01-23T17:05:20.534Z [INFO] core: successfully setup plugin catalog: plugin-directory="" 2024-01-23T17:05:20.536Z [INFO] core: successfully mounted: type=system version="v1.15.4+builtin.vault" path=sys/ namespace="ID: root. Path: " 2024-01-23T17:05:20.536Z [INFO] core: successfully mounted: type=identity version="v1.15.4+builtin.vault" path=identity/ namespace="ID: root. Path: " 2024-01-23T17:05:20.537Z [INFO] core: successfully mounted: type=cubbyhole version="v1.15.4+builtin.vault" path=cubbyhole/ namespace="ID: root. Path: " 2024-01-23T17:05:20.539Z [INFO] core: successfully mounted: type=token version="v1.15.4+builtin.vault" path=token/ namespace="ID: root. Path: " 2024-01-23T17:05:20.540Z [INFO] rollback: Starting the rollback manager with 256 workers 2024-01-23T17:05:20.540Z [INFO] core: restoring leases 2024-01-23T17:05:20.541Z [INFO] expiration: lease restore complete 2024-01-23T17:05:20.541Z [INFO] rollback: starting rollback manager 2024-01-23T17:05:20.541Z [INFO] identity: entities restored 2024-01-23T17:05:20.541Z [INFO] identity: groups restored 2024-01-23T17:05:20.542Z [INFO] core: usage gauge collection is disabled 2024-01-23T17:05:20.548Z [INFO] core: post-unseal setup complete 2024-01-23T17:05:20.548Z [INFO] core: vault is unsealed 2024-01-23T17:05:20.548Z [INFO] core: unsealed with stored key 2024-01-23T17:05:21.345Z [WARN] core: attempted unseal with stored keys, but vault is already unsealed
Данный вывод говорит нам о том, что сервер Vault прошел инициализацию и уже был распечатан. Мы можем убедиться в этом выполнив данную команду:
VAULT_ADDR=http://127.0.0.1:8100 vault status
Key Value --- ----- Seal Type transit Recovery Seal Type shamir Initialized true Sealed false Total Recovery Shares 5 Threshold 3 Version 1.15.4 Build Date 2023-12-04T17:45:28Z Storage Type file Cluster Name vault-cluster-0575a8ab Cluster ID f0cfa64a-a254-8346-67c2-add680130d91 HA Enabled false
Теперь, ради чистоты эксперимента, вернемся к первому окну консоли на узле vault-02 и прервем работу запущенного сервера Vault:
^C ==> Vault shutdown triggered 2024-01-23T17:10:40.245Z [INFO] core: marked as sealed 2024-01-23T17:10:40.245Z [INFO] core: pre-seal teardown starting 2024-01-23T17:10:40.246Z [INFO] rollback: stopping rollback manager 2024-01-23T17:10:40.246Z [INFO] core: pre-seal teardown complete 2024-01-23T17:10:40.246Z [INFO] core: stopping cluster listeners 2024-01-23T17:10:40.246Z [INFO] core.cluster-listener: forwarding rpc listeners stopped 2024-01-23T17:10:40.460Z [INFO] core.cluster-listener: rpc listeners successfully shut down 2024-01-23T17:10:40.460Z [INFO] core: cluster listeners successfully shut down 2024-01-23T17:10:40.461Z [INFO] core: vault is sealed
После этого действия, при повторном запуске, без технологии автоматического распечатывания Vault, в обязательном порядке, должен был бы запросить у нас необходимое количество осколков для распечатывания. Однако этого не произойдет, поскольку мы настроили процесс автоматического распечатывания с помощью механизма секретов Transit. Давайте убедимся в этом на практике. Ничего не меняя, во всё том же окне попробуем запустить Vault ещё раз:
vault server -config=config-autounseal.hcl
==> Vault server started! Log data will stream in below: 2024-01-23T17:18:11.743Z [INFO] events: Starting event system 2024-01-23T17:18:11.745Z [INFO] core: stored unseal keys supported, attempting fetch 2024-01-23T17:18:11.748Z [INFO] core.cluster-listener.tcp: starting listener: listener_address=0.0.0.0:8101 2024-01-23T17:18:11.748Z [INFO] core.cluster-listener: serving cluster requests: cluster_listen_address=[::]:8101 2024-01-23T17:18:11.748Z [INFO] core: post-unseal setup starting 2024-01-23T17:18:11.749Z [INFO] core: loaded wrapping token key 2024-01-23T17:18:11.749Z [INFO] core: successfully setup plugin runtime catalog 2024-01-23T17:18:11.749Z [INFO] core: successfully setup plugin catalog: plugin-directory="" 2024-01-23T17:18:11.751Z [INFO] core: successfully mounted: type=system version="v1.15.4+builtin.vault" path=sys/ namespace="ID: root. Path: " 2024-01-23T17:18:11.751Z [INFO] core: successfully mounted: type=identity version="v1.15.4+builtin.vault" path=identity/ namespace="ID: root. Path: " 2024-01-23T17:18:11.751Z [INFO] core: successfully mounted: type=cubbyhole version="v1.15.4+builtin.vault" path=cubbyhole/ namespace="ID: root. Path: " 2024-01-23T17:18:11.754Z [INFO] core: successfully mounted: type=token version="v1.15.4+builtin.vault" path=token/ namespace="ID: root. Path: " 2024-01-23T17:18:11.754Z [INFO] rollback: Starting the rollback manager with 256 workers 2024-01-23T17:18:11.755Z [INFO] core: restoring leases 2024-01-23T17:18:11.756Z [INFO] expiration: lease restore complete 2024-01-23T17:18:11.756Z [INFO] rollback: starting rollback manager 2024-01-23T17:18:11.756Z [INFO] identity: entities restored 2024-01-23T17:18:11.756Z [INFO] identity: groups restored 2024-01-23T17:18:11.757Z [INFO] core: usage gauge collection is disabled 2024-01-23T17:18:11.762Z [INFO] core: post-unseal setup complete 2024-01-23T17:18:11.762Z [INFO] core: vault is unsealed 2024-01-23T17:18:11.762Z [INFO] core: unsealed with stored key
Если вы внимательно посмотрите на последние строки в представленном выше журнале, то увидите, что Vault уже был распечатан, без какого-либо ручного ввода со стороны администратора. Чтобы убедиться в этом, выполним команду по отображению статуса ещё раз:
VAULT_ADDR=http://127.0.0.1:8100 vault status
Key Value --- ----- Seal Type transit Recovery Seal Type shamir Initialized true Sealed false Total Recovery Shares 5 Threshold 3 Version 1.15.4 Build Date 2023-12-04T17:45:28Z Storage Type file Cluster Name vault-cluster-0575a8ab Cluster ID f0cfa64a-a254-8346-67c2-add680130d91 HA Enabled false
Послесловие: Это все действия, которые необходимо было совершить. Однако это не всё, о чём я хотел бы рассказать в рамках данной темы, поэтому будет ещё одна подчасть, но уже меньшего размера. Какие-либо дополнительные ссылки здесь приводить не буду, поскольку почти вся информация была взята из официальной документацией.