Введение в HashiCorp Vault и его установка на OpenSUSE (Часть 1)
ЛЕТОПИСЕЦ КИТЕЖ-ГРАДА
Введение: Данная статья, как и в случае с Jenkins, открывает ещё один цикл, в котором речь пойдет о таком программном обеспечении, как Vault от компании HashiCorp. Конкретно в этой части мы поговорим о том, что собой представляет Vault, вкратце рассмотрим его архитектуру, а также произведем установку данного ПО на дистрибутив OpenSUSE.
Архитектура Vault: Vault – это система управления секретами и шифрованием на основе идентификации. Секрет в контексте Vault может представлять собой всё то, о чём не должны знать посторонние лица и это также то, что вы хотите строго контролировать (ключи шифрования API, пароли и сертификаты, и т.д.). Секреты можно надежно хранить и управлять ими, используя для доступа как пользовательский интерфейс Vault, так и интерфейс командной строки. Также можно воспользоваться HTTP API. Современная система требует доступа к множеству секретов, поэтому добавление смены ключей, безопасного хранилища и подробных журналов аудита практически невозможно без специального решения. Здесь в дело и вступает Vault. После входа он проверяет и авторизует клиента (пользователей, компьютеры, приложения), прежде чем предоставить им доступ к секретам/сохраненным конфиденциальным данным:
В основном Vault работает с токенами, при этом каждый токен связан с политикой клиента. Каждая политика основана на путях, и правила политики ограничивают как действия, так и доступ к путям для каждого клиента. С помощью Vault вы можете создавать токены вручную и назначать их своим клиентам или же клиенты могут авторизоваться и получить токен самостоятельно. Основной рабочий процесс Vault состоит из четырех этапов:
Authenticate: Аутентификация в Vault представляет собой процесс, посредством которого клиент предоставляет информацию, которую Vault использует, чтобы определить, являются ли они теми, за кого себя выдают. Как только клиент проходит аутентификацию с помощью метода аутентификации, токен генерируется и связывается с политикой.
Validation: Vault проверяет клиента на соответствие сторонним доверенным источникам, таким как Github, LDAP, AppRole и т. д.
Authorize: Клиент сопоставляется с политикой безопасности Vault. Эта политика представляет собой набор правил, определяющих, к каким сегментам API клиент имеет доступ с помощью своего токена. Политики используют декларативный способ предоставления или запрещения доступа к определенным путям и операциям в Vault.
Access: Vault предоставляет доступ к секретам, ключам и возможностям шифрования, выдавая токен на основе политик, связанных с клиентом. Затем клиент может использовать свой токен Vault для будущих операций.
На рисунке ниже изображен основной рабочий процесс описанных этапов:
В целом Vault обладает множеством отдельных компонентов. Например, уровень шифрования Vault, называемый барьером, отвечает за шифрование и расшифровку данных Vault. Когда сервер Vault запускают, он записывает данные в своё хранилище. Поскольку серверная часть хранилища находится за пределами барьера, она считается ненадежной, поэтому Vault шифрует данные перед их отправкой в серверную часть хранилища. Этот механизм гарантирует, что если злоумышленник попытается получить доступ к серверной части хранилища, данные не будут скомпрометированы, поскольку они остаются зашифрованными до тех пор, пока Vault не расшифрует их. Во время запуска Vault тот находится как бы в запечатанном (или заархивированном) состоянии. Прежде чем начать выполнять какие-либо операции с Vault, его необходимо разархивировать. Это возможно путем предоставления ключей для распаковки, которые создаются при инициализации Vault. Во время инициализации также генерируется ключ шифрования, который используется для защиты всех данных Vault. Эти ключи защищены корневым ключом, который хранится вместе со всеми другими данными в Vault, но зашифрован иным механизмом: ключом разархивирования. По умолчанию Vault применяет совместное использование секрета Шамира для разделения ключа по разархивированию на настроенное количество осколков (Key Shares или Unseal Keys). Точное количество осколков требуется для восстановления ключа по разархивированию, который после используется уже для расшифровки корневого ключа хранилища. Ниже представлена схема компонентов Vault:
Можно указать как количество Key Shares, так и количество Unseal Keys. Технику Шамира также можно отключить, а корневой ключ использовать непосредственно для разархивирования. Как только Vault получает ключ шифрования, он расшифровывает данные в серверной части хранилища и переходит в распакованное состояние. После этого Vault загружает настроенные устройства аудита, методы аутентификации и механизмы секретов:
Когда клиент впервые подключается к Vault, ему необходимо пройти аутентификацию. Vault предоставляет настраиваемые методы аутентификации и обеспечивает гибкость используемого механизма аутентификации. Для операторов могут использоваться такие механизмы, как имя пользователя и пароль или GitHub, а приложения могут использовать открытые/закрытые ключи или токены для аутентификации. Запрос на проверку подлинности, проходящий через ядро, и метод проверки подлинности, определяют, является ли запрос действительным, после чего возвращается список связанных политик. Политики – это просто именованное правило ACL. Например, встроенная политика «root» разрешает доступ ко всем ресурсам. Вы можете создать любое количество именованных политик с точным контролем путей. Хранилище работает в режиме разрешенного доступа, что означает, что действие не разрешено, если доступ не предоставлен явным образом через политику. Поскольку с пользователем может быть связано несколько политик, действия разрешены тогда, когда это разрешено политикой. Политики хранятся и управляются внутренним хранилищем политик. На это внутреннее хранилище влияет серверная часть системы, которая всегда монтируется в sys/. После прохождения аутентификации создается новый клиентский токен, которым управляет хранилище токенов. Этот клиентский токен используется для будущих запросов. Такой метод похож на файл cookie, отправляемый веб-сайтом при входе пользователя в систему. В зависимости от конфигурации метода аутентификации клиентский токен может иметь связанную с ним аренду, и может потребоваться периодическое обновление, чтобы избежать аннулирования. Политики также используются для авторизации запроса клиента. Затем запрос направляется механизму секретов, который обрабатывается в зависимости от его типа. Когда механизм секретов возвращает секрет, ядро регистрирует его в диспетчере истечения срока действия и прикрепляет идентификатор аренды. Клиенты используют идентификатор аренды для обновления или отзыва своего секрета. Менеджер истечения срока действия автоматически аннулирует секрет, если клиент допускает истечение срока аренды. Ядро регистрирует запросы и ответы брокеру аудита, распределяя запросы по всем настроенным устройствам аудита. Вне потока запросов ядро выполняет определенные фоновые действия. Управление арендой имеет решающее значение, позволяя автоматически отзывать просроченные клиентские токены или секреты. Кроме того, Vault обрабатывает определенные случаи частичного сбоя, используя ведение журнала с упреждающей записью с диспетчером отката. Оно управляется в ядре и невидимо для пользователя.
Запуск Vault в режиме Development: Итак, перейдем к непосредственной установке самого Vault. Только хотелось бы отметить, что все представленные команды будут выполнены на дистрибутиве OpenSUSE Tumblweed, который является Rolling Release (так уж сложилось на момент написания статьи). Но все шаги с полной идентичностью могут быть выполнены на любой другой версии дистрибутива OpenSUSE Leap, который, напоминаю, является версией Stable. Сам Vault будет установлен с помощью предварительно собранного бинарного файла, поскольку компания HashiCorp не поддерживает официальный репозиторий для установки данного ПО с помощью пакетного менеджера zypper. Итак, для установки необходимо доставить несколько дополнительных пакетов (если они отсутствуют в системе) и скачать соответствующий файл, который можно найти вот по этой ссылке – https://developer.hashicorp.com/vault/downloads:
sudo zypper install -y wget unzip
wget https://releases.hashicorp.com/vault/1.13.3/vault_1.13.3_linux_amd64.zip
unzip vault_1.13.3_linux_amd64.zip
sudo mv vault /usr/bin/
Как вы могли заметить, на момент написания данной статьи актуальная версия Vault – 1.13.3. Чтобы убедиться в этом, можно выполнить следующую команду:
vault version
Vault v1.13.3 (3bedf816cbf851656ae9e6bd65dd4a67a9ddff5e), built 2023-06-06T18:12:37Z
А чтобы вывести весь доступный список команд используйте:
vault --help
Usage: vault <command> [args] Common commands: read Read data and retrieves secrets write Write data, configuration, and secrets delete Delete secrets and configuration list List data or secrets login Authenticate locally agent Start a Vault agent server Start a Vault server status Print seal and HA status unwrap Unwrap a wrapped secret Other commands: audit Interact with audit devices auth Interact with auth methods debug Runs the debug command events kv Interact with Vault's Key-Value storage lease Interact with leases monitor Stream log messages from a Vault server namespace Interact with namespaces operator Perform operator-specific tasks patch Patch data, configuration, and secrets path-help Retrieve API help for paths pki Interact with Vault's PKI Secrets Engine plugin Interact with Vault plugins and catalog policy Interact with policies print Prints runtime configurations secrets Interact with secrets engines ssh Initiate an SSH session token Interact with tokens transform Interact with Vault's Transform Secrets Engine transit Interact with Vault's Transit Secrets Engine version-history Prints the version history of the target Vault server
Далее необходимо запустить сам Vault и тут у нас есть несколько вариантов того, как это можно сделать на начальном этапе. Одним из вариантов является запуск Vault в режиме -dev. Vault, работая в данном режиме, не нуждается в дополнительных настройках, а CLI уже аутентифицирован для связи с ним. Это упрощает как эксперименты с Vault, так и сам процесс запуска, для последующего взаимодействия. Такой вариант хорошо подойдет для тех, кто, руководствуясь данной статьей, хочет лишь посмотреть, что собой представляет Vault. По сути флаг -dev просто сокращает многие настройки до небезопасных значений по умолчанию. Однако НИКОГДА не запускайте сервер в режиме -dev в Production среде. Это максимально небезопасно и при таком подходе данные будут теряться при каждом перезапуске (поскольку они хранятся в памяти). И как уже упоминалось ранее, данный режим был создан исключительно для разработки и экспериментов. Некоторые свойства сервера в режиме -dev можно переопределить с помощью флагов командной строки или путем указания файла конфигурации. Vault в режиме -dev обладает следующими возможностями по умолчанию:
Initialized and Unsealed: Vault уже инициализирован и распакован. Вам не нужно использовать команду vault operator unseal. Он сразу будет готов к использованию.
In-memory Storage: Все данные Vault хранятся в памяти. Сервер Vault не требует никаких прав доступа к файлам.
Bound to Local Address without TLS: Vault способен прослушивать 127.0.0.1:8200 (адрес сервера по умолчанию) без использования TLS.
Automatically Authenticated: Vault хранит токен корневого доступа, поэтому использование CLI для подключения к хранилищу доступно сразу. Если вы получаете доступ к Vault через API, вам необходимо пройти аутентификацию с помощью полученного ранее токена.
Single Unseal Key: Vault проходит этап инициализации с помощью одного ключа для распаковки. Хранилище уже разархивировано, но если вы хотите поэкспериментировать с архивированием/разархивированием, то для этого потребуется всего один ключ.
Key Value Store Mounted: Движок секретов KV версии 2 смонтирован в файле secret/. Имейте в виду, что есть различия с KV версии 1. Если вы хотите использовать версию 1, используйте флаг -dev-kv-v1.
Итак, давайте запустим Vault в режиме -dev. Для этого необходимо выполнить следующую команду:
vault server -dev
==> Vault server configuration: Api Address: http://127.0.0.1:8200 Cgo: disabled Cluster Address: https://127.0.0.1:8201 Go Version: go1.20.3 Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled") Log Level: Mlock: supported: true, enabled: false Recovery Mode: false Storage: inmem Version: Vault v1.13.2, built 2023-04-25T13:02:50Z Version Sha: b9b773f1628260423e6cc9745531fd903cae853f ==> Vault server started! Log data will stream in below: 2023-06-20T19:59:07.649+0300 [INFO] proxy environment: http_proxy="" https_proxy="" no_proxy="" 2023-06-20T19:59:07.650+0300 [WARN] no `api_addr` value specified in config or in VAULT_API_ADDR; falling back to detection if possible, but this value should be manually set 2023-06-20T19:59:07.650+0300 [INFO] core: Initializing version history cache for core 2023-06-20T19:59:07.651+0300 [INFO] core: security barrier not initialized 2023-06-20T19:59:07.651+0300 [INFO] core: security barrier initialized: stored=1 shares=1 threshold=1 2023-06-20T19:59:07.651+0300 [INFO] core: post-unseal setup starting 2023-06-20T19:59:07.668+0300 [INFO] core: loaded wrapping token key 2023-06-20T19:59:07.668+0300 [INFO] core: successfully setup plugin catalog: plugin-directory="" 2023-06-20T19:59:07.668+0300 [INFO] core: no mounts; adding default mount table 2023-06-20T19:59:07.670+0300 [INFO] core: successfully mounted: type=cubbyhole version="v1.13.2+builtin.vault" path=cubbyhole/ namespace="ID: root. Path: " 2023-06-20T19:59:07.670+0300 [INFO] core: successfully mounted: type=system version="v1.13.2+builtin.vault" path=sys/ namespace="ID: root. Path: " 2023-06-20T19:59:07.671+0300 [INFO] core: successfully mounted: type=identity version="v1.13.2+builtin.vault" path=identity/ namespace="ID: root. Path: " 2023-06-20T19:59:07.672+0300 [INFO] core: successfully mounted: type=token version="v1.13.2+builtin.vault" path=token/ namespace="ID: root. Path: " 2023-06-20T19:59:07.672+0300 [INFO] rollback: starting rollback manager 2023-06-20T19:59:07.673+0300 [INFO] core: restoring leases 2023-06-20T19:59:07.676+0300 [INFO] identity: entities restored 2023-06-20T19:59:07.676+0300 [INFO] identity: groups restored 2023-06-20T19:59:07.676+0300 [INFO] core: Recorded vault version: vault version=1.13.2 upgrade time="2023-06-20 16:59:07.676688685 +0000 UTC" build date=2023-04-25T13:02:50Z 2023-06-20T19:59:07.678+0300 [INFO] expiration: lease restore complete 2023-06-20T19:59:08.161+0300 [INFO] core: post-unseal setup complete 2023-06-20T19:59:08.162+0300 [INFO] core: root token generated 2023-06-20T19:59:08.162+0300 [INFO] core: pre-seal teardown starting 2023-06-20T19:59:08.162+0300 [INFO] rollback: stopping rollback manager 2023-06-20T19:59:08.162+0300 [INFO] core: pre-seal teardown complete 2023-06-20T19:59:08.162+0300 [INFO] core.cluster-listener.tcp: starting listener: listener_address=127.0.0.1:8201 2023-06-20T19:59:08.162+0300 [INFO] core.cluster-listener: serving cluster requests: cluster_listen_address=127.0.0.1:8201 2023-06-20T19:59:08.162+0300 [INFO] core: post-unseal setup starting 2023-06-20T19:59:08.163+0300 [INFO] core: loaded wrapping token key 2023-06-20T19:59:08.163+0300 [INFO] core: successfully setup plugin catalog: plugin-directory="" 2023-06-20T19:59:08.163+0300 [INFO] core: successfully mounted: type=system version="v1.13.2+builtin.vault" path=sys/ namespace="ID: root. Path: " 2023-06-20T19:59:08.163+0300 [INFO] core: successfully mounted: type=identity version="v1.13.2+builtin.vault" path=identity/ namespace="ID: root. Path: " 2023-06-20T19:59:08.163+0300 [INFO] core: successfully mounted: type=cubbyhole version="v1.13.2+builtin.vault" path=cubbyhole/ namespace="ID: root. Path: " 2023-06-20T19:59:08.164+0300 [INFO] core: successfully mounted: type=token version="v1.13.2+builtin.vault" path=token/ namespace="ID: root. Path: " 2023-06-20T19:59:08.165+0300 [INFO] core: restoring leases 2023-06-20T19:59:08.165+0300 [INFO] rollback: starting rollback manager 2023-06-20T19:59:08.165+0300 [INFO] expiration: lease restore complete 2023-06-20T19:59:08.165+0300 [INFO] identity: entities restored 2023-06-20T19:59:08.165+0300 [INFO] identity: groups restored 2023-06-20T19:59:08.166+0300 [INFO] core: post-unseal setup complete 2023-06-20T19:59:08.166+0300 [INFO] core: vault is unsealed 2023-06-20T19:59:08.169+0300 [INFO] core: successful mount: namespace="" path=secret/ type=kv version="" WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory and starts unsealed with a single unseal key. The root token is already authenticated to the CLI, so you can immediately begin using Vault. You may need to set the following environment variables: $ export VAULT_ADDR='http://127.0.0.1:8200' The unseal key and root token are displayed below in case you want to seal/unseal the Vault or re-authenticate. Unseal Key: aVcXjHfqh65SuXZWGo5+p7u0tT9Tq6723M0KmzWxrvE= Root Token: hvs.lbaAI3NfugcrEBJw2Nk4ddqW Development mode should NOT be used in production installations!
Если внимательно ознакомиться с выводом выше, то мы увидим, что Vault сообщает нам о том, что данный сервер запущен в режиме -dev. Также уже был пройден процесс распаковки и инициализации. Чтобы убедиться в этом, можно выполнить команду vault status, однако на текущем этапе она не сработает, поскольку мы, в качестве переменной, не определили адрес, к которому можно было бы обратиться. Сам Vault нам также об этом говорит. Не прерывая работу -dev режима, откройте ещё один терминал и выполните следующую команду:
export VAULT_ADDR='http://127.0.0.1:8200'
После этого попробуем выполнить проверку доступности Vault ещё раз:
vault status
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed false
Total Shares 1
Threshold 1
Version 1.13.2
Build Date 2023-04-25T13:02:50Z
Storage Type inmem
Cluster Name vault-cluster-55f08ad5
Cluster ID 089fcdad-2533-c867-8a79-3d03d428c0aa
HA Enabled false
В выводе выше также содержится некоторая дополнительная информация. В данном случае мы видим, что Vault был инициализирован, распакован, обладает одним Shares, и т.д. Это всё, что необходимо для того, чтобы Vault успешно заработал. Теперь его можно использовать для создания секретов, политик и т.д., однако это тема будущих статей. Единственное, что я добавил бы прямо сейчас, так это возможность работы на 0.0.0.0. Потому что у меня, например, инстанс, на котором запущен Vault, находится в GCP. И без особых ухищрений по типу туннелей я не могу обратиться к нему напрямую. Так что давайте изменим данный параметр. В общем случае команда будет выглядеть следующим образом:
vault server -dev -dev-listen-address="0.0.0.0:8200"
И не забываем, что после выполнения представленной выше команды необходимо будет переопределить адрес сервера в переменной:
export VAULT_ADDR='http://0.0.0.0:8200'
vault status
Key Value --- ----- Seal Type shamir Initialized true Sealed false Total Shares 1 Threshold 1 Version 1.13.2 Build Date 2023-04-25T13:02:50Z Storage Type inmem Cluster Name vault-cluster-53d77ee3 Cluster ID 87b293b1-1033-850e-8378-f7f3c7f0dae7 HA Enabled false
Далее можно попытаться открыть Web-страницу в браузере, обратившись к IP-адресу или доменному имени того сервера, где был запущен сам Vault:
На рисунке выше видно, что для входа необходимо ввести токен. Сам токен присутствует прямо в выводе запуска Vault. В нашем случае это токен вида hvs.lbaAI3NfugcrEBJw2Nk4ddqW, который был показан ранее. Скопируем и вставим его в поле, а после нажмем на Sign In:
Мануальная установка Vault: Далее рассмотрим более правильный вариант того, как должен быть запущен сервер Vault, с минимальными настройками для работы. Всё также будет использоваться бинарный файл, расположенный по пути /usr/bin/vault. После необходимо создать директорию, в которой будет храниться конфигурационный файл. Сам файл назовем config.hcl:
sudo mkdir /etc/vault
sudo touch /etc/vault/config.hcl
К конфигурационному файлу мы ещё вернемся, а пока необходимо получить сертификаты, так как Vault, скажем так, в Production режиме без них работать не будет (вообще может, но для этого необходимо принудительно выключить tls, что не совсем правильно, раз уж речь идет о Production). В качестве сертификатов будет использоваться Let's Encrypt. Для этого понадобится публичный домен и IP-адрес сервера. Вам необязательно иметь публичный адрес сервера для успешного запуска, однако подразумевается, что если вы будете запускать Vault в закрытом периметре, то вы сможете подвязать домен и соответствующий сертификат. Итак, в моём случае мне необходимо получить сертификат от Let's Encrypt. Для этого выполним следующий ряд команд:
sudo zypper install -y certbot
sudo certbot certonly --standalone -d vault.kitezh.online
Successfully received certificate. Certificate is saved at: /etc/letsencrypt/live/vault.kitezh.online/fullchain.pem Key is saved at: /etc/letsencrypt/live/vault.kitezh.online/privkey.pem This certificate expires on 2023-09-18. These files will be updated when the certificate renews.
После того как сертификат был получен, вернемся к конфигурационному файлу. Откройте его по пути /etc/vault/config.hcl, если вы повторяли за мной и вставьте следующее содержимое:
ui = true
storage "file" {
path = "/etc/vault/data"
}
listener "tcp" {
address = "0.0.0.0:443"
tls_cert_file = "/etc/letsencrypt/live/vault.kitezh.online/fullchain.pem"
tls_key_file = "/etc/letsencrypt/live/vault.kitezh.online/privkey.pem"
tls_disable = "false"
}
Давайте разберемся из чего же состоит данный конфигурационный файл. UI, равное true, означает, что по умолчанию, при запуске Vault, он также будет доступен через браузер. Секция storage настраивает серверную часть хранилища, которая представляет собой место для долговременного хранения информации Vault. Существует множество различных бэкендов (так называются места хранения данных в терминологии Vault) для хранения, где каждый обладает своим рядом уникальных параметров. Я буду использовать вариант file, поскольку в таком случае серверная часть хранилища файловой системы будет хранить данные Vault, используя стандартную структуру каталогов. Вообще это самый простой вариант использования при условии, что мы всё-таки хотим запустить Vault в Production режиме. Такой вариант приемлем, когда мы точно знаем, что у нас будет использоваться один сервер Vault, а такие вещи, как отказоустойчивость и скалирование не находятся на первом месте. Секция listener определяет список параметров, которые необходимы для запуска и последующего поддержания сервера Vault в рабочем состоянии. По сути это информация о том, на каком адресе и порту будет работать Vault.
Примечание: Больше параметров, которые можно использовать в конфигурационном файле, можно найти по следующей ссылке – https://developer.hashicorp.com/vault/docs/configuration.
Сохраним представленный выше конфигурационный файл. Немного позже мы ещё вернёмся к нему, а пока что создадим ещё один конфигурационный файл, уже для запуска Vault с помощью systemd:
sudo vim /etc/systemd/system/vault.service
[Unit] Description=Vault Documentation=https://vault.io [Service] ExecStart=/usr/bin/vault server -config=/etc/vault/config.hcl ExecReload=/bin/kill -HUP $MAINPID LimitNOFILE=65536 [Install] WantedBy=multi-user.target
Тут всё просто. Указываем бинарный файл для запуска сервера с параметром -config, который ссылается на конфигурационный файл Vault, расположенный по пути /etc/vault/config.hcl (в моём случае).
Примечание: Это самый примитивный конфигурационный файл Systemd, необходимый для запуска Vault. На той же Ubuntu, если Vault устанавливать с помощью пакетного менеджера apt, то по умолчанию данный юнит уже будет создан, а его содержимое будет выражено следующим образом:
[Unit] Description="HashiCorp Vault - A tool for managing secrets" Documentation=https://developer.hashicorp.com/vault/docs Requires=network-online.target After=network-online.target ConditionFileNotEmpty=/etc/vault.d/vault.hcl StartLimitIntervalSec=60 StartLimitBurst=3 [Service] Type=notify EnvironmentFile=/etc/vault.d/vault.env User=vault Group=vault ProtectSystem=full ProtectHome=read-only PrivateTmp=yes PrivateDevices=yes SecureBits=keep-caps AmbientCapabilities=CAP_IPC_LOCK CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK NoNewPrivileges=yes ExecStart=/usr/bin/vault server -config=/etc/vault.d/vault.hcl ExecReload=/bin/kill --signal HUP $MAINPID KillMode=process KillSignal=SIGINT Restart=on-failure RestartSec=5 TimeoutStopSec=30 LimitNOFILE=65536 LimitMEMLOCK=infinity [Install] WantedBy=multi-user.target
Далее осуществляем перезапуск демона и пробуем запустить сам Vault. Для этого понадобятся следующие команды:
sudo systemctl daemon-reload
sudo systemctl enable vault
sudo systemctl start vault
sudo systemctl status vault
● vault.service - Vault Loaded: loaded (/etc/systemd/system/vault.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2023-06-20 20:18:08 UTC; 6s ago Docs: https://vault.io Main PID: 7648 (vault) Tasks: 7 (limit: 2283) CGroup: /system.slice/vault.service └─ 7648 /usr/bin/vault server -config=/etc/vault/config.hcl
Теперь попробуем вывести информацию о состоянии Vault:
vault status
Error checking seal status: Get "https://127.0.0.1:8200/v1/sys/seal-status": dial tcp 127.0.0.1:8200: connect: connection refused
Почему в моём случае была получена данная ошибка? Дело в том, что ранее, когда мы запускали Vault в режиме -dev, переменная VAULT_ADDR была определена со значением 127.0.0.1:8200. Однако сейчас Vault работает на 0.0.0.0, а к IP-адресу сервера была назначена А-запись с доменными именем vault.kitezh.online, поэтому и обращаться мы должны соответствующим образом:
export VAULT_ADDR="https://vault.kitezh.online:443"
vault status
Key Value --- ----- Seal Type shamir Initialized false Sealed true Total Shares 0 Threshold 0 Unseal Progress 0/0 Unseal Nonce n/a Version 1.13.3 Build Date 2023-06-06T18:12:37Z Storage Type file HA Enabled false
Примечание: К слову, если переменная ни коем образом не была определена, то сообщение об ошибке будет равнозначно тому, что было получено выше.
Другое дело. Теперь можно работать с Vault через командную строку, однако он всё ещё не был инициализирован. Исправим данный факт с помощью следующей команды:
vault operator init
Unseal Key 1: ICRju9MYAsqJWbMH/kpsLgiTP+xMe6fU7Cd8A8BX4cGb Unseal Key 2: m5LEy0j3Gw/OpI+rvu2qG2N3tp4LQrtuf9FYPmMwoydM Unseal Key 3: tc+iV4hPXiuWHKwv9o4WhIfzmUU4DBE8SJcLut2ABx1R Unseal Key 4: 1FOuvwDhL2KwscoW/B9o13fGOq+qnRTM/ZCcftlQdrxA Unseal Key 5: RNxJyqsWHHDSn1Wp4ig3HU8w6vYnjI3BDBcj9aBgJI7s Initial Root Token: hvs.Xj38SRgFMsFZI6E7nGKifxTo Vault initialized with 5 key shares and a key threshold of 3. Please securely distribute the key shares printed above. When the Vault is re-sealed, restarted, or stopped, you must supply at least 3 of these keys to unseal it before it can start servicing requests. Vault does not store the generated root key. Without at least 3 keys to reconstruct the root key, Vault will remain permanently sealed! It is possible to generate new unseal keys, provided you have a quorum of existing unseal keys shares. See "vault operator rekey" for more information.
Сообщение выше говорит о том, что Vault был инициализирован, но ещё не распакован. В этом нам помогут ключи Unseal, полученные ранее. Их необходимо обязательно где-нибудь сохранить, как и корневой токен, поскольку в случае потери очень трудно всё это будет восстановить. Теперь, чтобы распаковать Vault в моём случае, необходимо выполнить следующую последовательность команд:
vault operator unseal ICRju9MYAsqJWbMH/kpsLgiTP+xMe6fU7Cd8A8BX4cGb
vault operator unseal tc+iV4hPXiuWHKwv9o4WhIfzmUU4DBE8SJcLut2ABx1R
vault operator unseal RNxJyqsWHHDSn1Wp4ig3HU8w6vYnjI3BDBcj9aBgJI7s
Key Value --- ----- Seal Type shamir Initialized true Sealed true Total Shares 5 Threshold 3 Unseal Progress 1/3 Unseal Nonce 44744a4b-d90a-4e04-ec0e-fb0fbb87b352 Version 1.13.3 Build Date 2023-06-06T18:12:37Z Storage Type file HA Enabled false Key Value --- ----- Seal Type shamir Initialized true Sealed true Total Shares 5 Threshold 3 Unseal Progress 2/3 Unseal Nonce 44744a4b-d90a-4e04-ec0e-fb0fbb87b352 Version 1.13.3 Build Date 2023-06-06T18:12:37Z Storage Type file HA Enabled false Key Value --- ----- Seal Type shamir Initialized true Sealed false Total Shares 5 Threshold 3 Version 1.13.3 Build Date 2023-06-06T18:12:37Z Storage Type file Cluster Name vault-cluster-bb708744 Cluster ID c6b54357-295a-5b62-cf6b-469872c4872c HA Enabled false
Понятно, что с помощью дополнительных параметров можно было изменить как число Unseal Key, так и количество, необходимое для разархивирования Vault, однако в сценарии по умолчанию оно будет выглядеть именно так. Осталось только осуществить вход по токену и всё:
vault login
Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token hvs.Xj38SRgFMsFZI6E7nGKifxTo token_accessor uz7mHBEQOzKVESEHl0N3toxT token_duration ∞ token_renewable false token_policies ["root"] identity_policies [] policies ["root"]
Дальнейшие действия, связанные с командной строкой Vault выходят за пределы повествования этой статьи. Так что об остальных возможностях Vault мы поговорим уже в следующий раз, однако несколько хитростей я всё же хотел бы отметить. Во-первых, чтобы постоянно не создавать себе переменную с адресом Vault, можно просто добавить команду в .bashrc:
echo export VAULT_ADDR="https://vault.kitezh.online:443" >> ~/.bashrc
Теперь, при следующем входе, эта переменная уже будет определена в системе. Также хотелось бы отметить, как можно добавить автодополнение для команд Vault. Сперва необходимо выполнить вот такую команду:
vault -autocomplete-install
Это установит автодополнение в систему. После чего нужно будет это самое автодополнение включить с помощью уже следующей команды:
complete -C /usr/bin/vault vault
Теперь, если начать использовать TAB после команды vault, то слова автоматически будут подставляться, в зависимости от введенных вами слов. Забыл добавить, что Web-версия также доступна по ссылке и всё это работает в режиме TLS:
В заключении хотелось бы вернуться к конфигурационному файлу Vault. Если вы всё же хотите запустить Vault в нормальном режиме, но у вас нет возможности использовать TLS, то в таком случае удалите строки с сертификатами и ключами, а в параметре tls_disable поставьте значение true:
ui = true
storage "file" {
path = "/etc/vault/data"
}
listener "tcp" {
address = "0.0.0.0:8200"
tls_disable = "true"
}
Послесловие: К слову, вы также можете использовать любой другой порт или вообще запустить Vault на локальном узле (127.0.0.1), а после, в качестве прокси-сервера, настроить Nginx. Я от данного варианта отказался потому, что эта статья, в первую очередь, направлена на ознакомление с самим Vault. Без каких-либо привязок к сторонним инструментам. Хотя на практике использование того же Nginx, Traefik или любого другого балансировщика нагрузки является предпочтительным вариантом. Но всё это тема для будущих статей. Сюда же можно добавить и случай с местом хранения данных. В этой статье мною был использован вариант file, поскольку он является самым простым и доступным, но когда речь пойдет HA, мы затронем и протокол Raft, и Consul. И как уже было сказано ранее, это первая статья из ещё одного цикла, который будет посвящен работе с Vault. Уже в следующей части мы более подробно рассмотрим то, как взаимодействовать с секретами. На этом всё.