Безопасное хранение паролей с HashiCorp Vault: пошаговая инструкция

Содержание

Куда девать пароли, чтобы не забыть и не потерять? Ответ — Vault. Объяснили, как настроить это хранилище на сервере, защитить доступ и подключить приложение. Вы запускаете новый сервис, тестируете приложение или настраиваете VPS — и рано или поздно встаёт вопрос: как безопасно сохранить пароли. Не временно и не для одного разработчика, а надёжно, централизованно и с возможностью контроля.

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

Аренда VPS/VDS от 219 руб/месяц

Преимущества VPS в AdminVPS:

✓ Бесплатное администрирование

✓ Только быстрые NVMe-диски

✓ Защита от DDoS-атак

✓ Быстрая техподдержка

Аренда VPS/VDS виртуального сервера от AdminVPS — это прозрачная и честная услуга с доступной ценой

Установка и настройка Vault на сервере

Vault можно запускать по-разному: как бинарный файл, контейнер или systemd-сервис. Самый прозрачный и понятный путь — установка напрямую на сервер с Ubuntu 22.04. Такой способ упрощает отладку, настройку автозапуска и подключение к внешним сервисам.

Для начала стоит обновить список пакетов и установить curl и gnupg. Эти утилиты понадобятся для добавления репозитория HashiCorp:

sudo apt update
sudo apt install curl gnupg lsb-release

Далее подключается публичный ключ и сам репозиторий:

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
sudo tee /etc/apt/sources.list.d/hashicorp.list

После этого нужно обновить пакеты и установить Vault:

sudo apt update
sudo apt install vault

Проверьте, всё ли встало как надо:

vault --version

Если команда вернула версию, Vault установлен корректно. Далее настраивается базовая конфигурация. По умолчанию Vault не запускается. Требуется задать параметры, где он будет слушать подключения и хранить данные.

Создайте каталог под конфигурационные файлы:

sudo mkdir /etc/vault.d

Теперь нужно положить туда минимальный конфиг. Например, чтобы Vault слушал локальный порт 8200 и хранил данные в файловой системе:

# /etc/vault.d/vault.hcl
storage "file" {
  path = "/var/lib/vault/data"
}

listener "tcp" {
  address     = "127.0.0.1:8200"
  tls_disable = 1
}

ui = true

Создайте папку под данные и проверьте права доступа:

sudo mkdir -p /var/lib/vault/data
sudo chown -R vault:vault /var/lib/vault

Теперь Vault можно зарегистрировать как systemd-сервис и включить автозапуск:

sudo systemctl enable vault
sudo systemctl start vault

Если всё прошло успешно, можно проверить статус:

sudo systemctl status vault

Если вы используете VPS от AdminVPS, всё встанет без проблем: свежие версии Ubuntu, нужные порты открыты, systemd работает стабильно — можно спокойно настраивать и тестировать Vault.

Инициализация и базовая конфигурация Vault

Установленный Vault — это как сейф с кнопкой включения, но без замка. Пока он не инициализирован, ключи не созданы и хранилище не работает. Один и тот же экземпляр нельзя инициализировать дважды, поэтому этот шаг выполняется строго один раз для каждого сервера.

Перед инициализацией задайте переменную окружения с адресом сервиса. Vault работает через HTTP API и по умолчанию слушает 127.0.0.1:8200. Команда для экспорта:

export VAULT_ADDR=http://127.0.0.1:8200

Запустите инициализацию:

vault operator init

Команда сгенерирует несколько строк — это ключи разблокировки (unseal keys) и один токен root-доступа. По умолчанию создаётся пять ключей, из которых нужны любые три для разблокировки. Такая схема называется пороговой. Даже если часть ключей потеряется, доступ останется.

Сохраните эти значения в надёжном и безопасном месте. Не отправляйте в Telegram и не оставляйте в открытом файле. Лучше использовать менеджер паролей или зашифровать содержимое с помощью gpg. Без этих данных доступ к хранилищу восстановить не получится.

Чтобы начать работу, разблокируйте Vault. Он не активен, пока не получит нужное количество ключей. Введите ключи по одному:

vault operator unseal

Повторите команду трижды с разными ключами. После третьего ввода Vault разблокируется. Статус можно проверить командой:

vault status

В статусе будет указано, что Vault разблокирован, назначен leader и хранилище активно.

Следующий шаг — авторизация с помощью root-токена:

vault login

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

На этом этапе Vault готов к использованию. Можно сохранять и считывать секреты, обновлять данные и настраивать доступ. Однако прежде чем добавлять содержимое, стоит организовать структуру. Лучше создать отдельную политику доступа и выдать токен с ограниченными правами. Постоянная работа от root-токена не подходит для продакшена.

Управление секретами: создание и доступ

После инициализации Vault готов к работе. Теперь можно создать хранилище, добавить секреты и настроить доступ к ним. Все действия выполняются через CLI или HTTP API. Начнём с key-value движка, подходящего для хранения строковых данных.

Vault использует секретные движки. Это модули, отвечающие за разные типы хранилищ. Движок KV второго поколения включите вручную, указав путь:

vault secrets enable -path=secret kv-v2

Теперь добавьте данные. Пример секрета по пути app/config с логином и паролем:

vault kv put secret/app/config username=admin password=s3cr3t

Vault сохранит данные в виде структуры с версионностью и метаданными. Получите содержимое секрета:

vault kv get secret/app/config

В выводе отобразится имя пользователя, пароль и информация о версии. Чтобы изменить данные, выполните повторную команду put:

vault kv put secret/app/config username=admin password=NEWpass123

Это создаст новую версию секрета. При необходимости откатитесь к предыдущей:

vault kv get -version=1 secret/app/config

Удалите секрет с помощью команды:

vault kv delete secret/app/config

Если нужно полностью убрать все версии, очистите метаданные:

vault kv metadata delete secret/app/config

Теперь настройте доступ. Работать от имени root постоянно не стоит. Подготовьте отдельную политику с нужными правами. Пример для чтения секрета по указанному пути:

# read-only.hcl
path "secret/data/app/config" {
  capabilities = ["read"]
}

Загрузите политику в Vault:

vault policy write read-only read-only.hcl

Создайте токен с этой политикой:

vault token create -policy="read-only"

Vault вернёт токен, который можно использовать в API-запросах или передавать приложению. У него будет только право чтения без доступа к другим данным.

Если приложение работает вне текущего сервера, передавайте токен через переменные среды или используйте его напрямую. Пример с curl:

curl --header "X-Vault-Token: <токен>" http://127.0.0.1:8200/v1/secret/data/app/config

В ответе придёт JSON с нужными значениями. Их можно использовать в коде, прокидывать в переменные окружения или читать напрямую из API.

Интеграция Vault с приложениями и сервисами

Хранить секреты в Vault — это только половина дела. Чтобы всё работало как надо, приложения должны уметь их получать. И тут важно, чтобы этот процесс был не только безопасным, но и простым.

В самом начале можно обойтись токеном. Создаёте его вручную, передаёте в приложение через переменную окружения, и оно вытаскивает нужные данные. Рабочий вариант, особенно если всё ещё на стадии тестов. Но такой подход быстро перестаёт быть удобным: токены нужно обновлять, права ограничивать, а конфигурация начинает расползаться.

Дальше в игру вступает аутентификация. Vault может проверять, кто к нему обращается, и выдавать доступ только тем, кто подтверждён. Есть несколько способов: AppRole для серверов, JWT для веб-приложений, Kubernetes для контейнеров. Настраивается это один раз, а дальше приложение просто спрашивает: можно мне доступ? Vault отвечает, если всё в порядке.

Например, можно подключить Python через библиотеку hvac, Laravel через сторонний клиент, а в Docker-контейнере вообще обойтись curl-запросом в init-скрипте. Vault возвращает секрет, после чего приложение сохраняет его в кеше или передаёт в переменную окружения для последующей работы.

Если нужно, можно настроить временные ключи. Vault сам их выдаёт и сам отзывает, когда срок истекает. Это особенно удобно, когда не хочется думать о ротации. Приложение просто запрашивает новый ключ, когда старый истёк, и всё продолжает работать без остановок.

Заключение

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

С Vault всё становится на свои места. Один источник правды, одна точка доступа, понятные политики и история изменений. Секреты не лежат рядом с кодом, не попадают в логи и не теряются при переносе. Если сервису нужен ключ, он получит его сам. И только тот, что ему положен. В результате все секреты централизованы: больше не нужно вручную отслеживать, где находится пароль от базы или API-ключ внешнего сервиса. Vault обеспечивает контроль, безопасность и возможность восстановления при сбое.

Читайте в блоге: