Назад к обновлениям
New releaseSep 2, 2026

vault v2.1.0

Инструмент для управления секретами, шифрования как услуги и управления привилегированным доступом

Поделиться

Vault build ci vault enterprise

Пожалуйста, обратите внимание: Мы очень серьезно относимся к безопасности Vault и доверию наших пользователей. Если вы считаете, что нашли уязвимость в Vault, пожалуйста, сообщите о ней ответственно, связавшись с нами по адресу [email protected].

Логотип Vault

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

Современная система требует доступа к множеству секретов: учетные данные базы данных, ключи API для внешних сервисов, учетные данные для взаимодействия в сервис-ориентированной архитектуре и т.д. Понимание того, кто и к каким секретам получает доступ, уже само по себе очень сложно и зависит от платформы. Добавление ротации ключей, безопасного хранения и подробных журналов аудита практически невозможно без специального решения. Здесь на помощь приходит Vault.

Ключевые особенности Vault:

  • Безопасное хранение секретов: Vault может хранить произвольные пары ключ/значение. Vault шифрует данные перед записью в постоянное хранилище, поэтому доступа к сырому хранилищу недостаточно для получения ваших секретов. Vault может записывать данные на диск, в Consul и т.д.

  • Динамические секреты: Vault может генерировать секреты по требованию для некоторых систем, таких как AWS или базы данных SQL. Например, когда приложению требуется доступ к S3-корзине, оно запрашивает у Vault учетные данные, и Vault генерирует пару ключей AWS с действительными разрешениями по требованию. После создания этих динамических секретов Vault также автоматически отзывает их по истечении срока аренды.

  • Шифрование данных: Vault может шифровать и расшифровывать данные без их хранения. Это позволяет командам безопасности определять параметры шифрования, а разработчикам — хранить зашифрованные данные в таком месте, как база данных SQL, без необходимости разрабатывать собственные методы шифрования.

  • Аренда и продление: Vault связывает с каждым секретом аренду. По окончании аренды Vault автоматически отзывает секрет. Клиенты могут продлевать аренду с помощью встроенных API продления.

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

Документация, начало работы и сертификационные экзамены

Документация доступна на сайте Vault.

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

Примеры взаимодействия с Vault из вашего приложения на разных языках программирования можно найти в репозитории vault-examples. Также доступно готовое примерное приложение.

Продемонстрируйте свои знания Vault, сдав сертификационный экзамен. Посетите страницу сертификации для получения информации об экзаменах и найдите учебные материалы на обучающей платформе HashiCorp.

Разработка Vault

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

Для локальной разработки сначала убедитесь, что Go правильно установлен, включая настройку GOPATH, а затем установите переменную GOBIN в $GOPATH/bin. Убедитесь, что $GOPATH/bin находится в вашем PATH, так как некоторые дистрибутивы поставляются со старой версией инструментов сборки.

Затем клонируйте этот репозиторий. Vault использует Go Modules, поэтому рекомендуется клонировать репозиторий за пределами GOPATH. После этого вы можете загрузить все необходимые инструменты сборки, выполнив начальную настройку окружения:

$ make bootstrap
...

Чтобы скомпилировать версию Vault для разработки, выполните make или make dev. Это поместит бинарный файл Vault в папки bin и $GOPATH/bin:

$ make dev
...
$ bin/vault
...

Чтобы скомпилировать версию Vault для разработки с пользовательским интерфейсом, выполните make static-dist dev-ui. Это поместит бинарный файл Vault в папки bin и $GOPATH/bin:

$ make static-dist dev-ui
...
$ bin/vault
...

Для запуска тестов введите make test. Примечание: для этого требуется установленный Docker. Если команда завершится с кодом выхода 0, значит всё работает!

$ make test
...

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

$ make test TEST=./vault
...

Устранение неполадок

Если вы столкнулись с ошибкой вроде could not read Username for 'https://github.com', вам может потребоваться изменить настройки git следующим образом:

$ git config --global --add url."[email protected]:".insteadOf "https://github.com/"

Импорт Vault

Этот репозиторий публикует две библиотеки, которые могут быть импортированы другими проектами: github.com/hashicorp/vault/api и github.com/hashicorp/vault/sdk.

Обратите внимание, что этот репозиторий также содержит Vault (продукт), и, как и в большинстве проектов на Go, Vault использует Go modules для управления зависимостями. Механизм для этого — файл go.mod. Как оказалось, наличие этого файла также делает теоретически возможным импорт Vault в качестве зависимости в другие проекты. Некоторые другие проекты практикуют это, чтобы воспользоваться инструментарием тестирования, разработанным для тестирования самого Vault. Это не является и никогда не было поддерживаемым способом использования проекта Vault. Мы вряд ли будем исправлять ошибки, связанные с неудачным импортом github.com/hashicorp/vault в ваш проект.

См. также раздел «Docker-based tests» ниже.

Приёмочные тесты

Vault имеет обширные приёмочные тесты, охватывающие большинство функций методов секретов и аутентификации.

Если вы работаете над функцией метода секрета или аутентификации и хотите убедиться, что она работает (а также не сломала ничего другого), мы рекомендуем запустить приёмочные тесты.

Предупреждение: Приёмочные тесты создают/уничтожают/изменяют реальные ресурсы, что в некоторых случаях может повлечь реальные затраты. В случае наличия ошибки технически возможно, что неисправные бэкенды могут оставить после себя висящие данные. Поэтому запускайте приёмочные тесты на свой страх и риск. Как минимум, мы рекомендуем запускать их в отдельном приватном аккаунте для тестируемого бэкенда.

Чтобы запустить приёмочные тесты, выполните make testacc:

$ make testacc TEST=./builtin/logical/consul
...

Переменная TEST обязательна, и вы должны указать папку, где находится бэкенд. Переменная TESTARGS рекомендуется для фильтрации до конкретного ресурса для тестирования, так как тестирование всех сразу может занять очень много времени.

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

Для получения дополнительной информации о функциях Vault Enterprise посетите сайт Vault Enterprise.

Docker-based Tests

Мы создали экспериментальный новый механизм тестирования, вдохновлённый NewTestCluster. Пример использования:

import (
  "testing"
  "github.com/hashicorp/vault/sdk/helper/testcluster/docker"
)

func Test_Something_With_Docker(t *testing.T) {
  opts := &docker.DockerClusterOptions{
    ImageRepo: "hashicorp/vault", // или "hashicorp/vault-enterprise"
    ImageTag:    "latest",
  }
  cluster := docker.NewTestDockerCluster(t, opts)
  
  client := cluster.Nodes()[0].APIClient()
  _, err := client.Logical().Read("sys/storage/raft/configuration")
  if err != nil {
    t.Fatal(err)
  }
}

Или для Enterprise:

import (
  "testing"
  "github.com/hashicorp/vault/sdk/helper/testcluster/docker"
)

func Test_Something_With_Docker(t *testing.T) {
  opts := &docker.DockerClusterOptions{
    ImageRepo: "hashicorp/vault-enterprise",
    ImageTag:  "latest",
	VaultLicense: licenseString, // не путь, а фактические байты лицензии
  }
  cluster := docker.NewTestDockerCluster(t, opts)
}

Вот более реалистичный пример того, как мы используем это на практике. DefaultOptions использует hashicorp/vault:latest в качестве репозитория и тега, но также проверяет переменную окружения VAULT_BINARY. Если она задана, то скопирует локальный файл, на который ссылается VAULT_BINARY, в контейнер. Это полезно для тестирования локальных изменений.

Вместо установки опции VaultLicense вы можете задать переменную окружения VAULT_LICENSE_CI, что лучше, чем сохранять лицензию в систему контроля версий.

При желании можно установить COMMIT_SHA, который будет добавлен к имени образа, который мы собираем, для удобства отладки.

func Test_Custom_Build_With_Docker(t *testing.T) {
  opts := docker.DefaultOptions(t)
  cluster := docker.NewTestDockerCluster(t, opts)
}

В пакете github.com/hashicorp/vault/sdk/helper/testcluster есть множество вспомогательных функций, например, следующие тесты создают пару 3-узловых кластеров и связывают их с помощью репликации PR или DR соответственно, и завершаются ошибкой, если состояние репликации не становится здоровым до истечения переданного контекста.

Опять же, как написано, они зависят от наличия локального бинарного файла Vault Enterprise и переменной окружения VAULT_BINARY, указывающей на него, а также от установленной VAULT_LICENSE_CI.

func TestStandardPerfReplication_Docker(t *testing.T) {
  opts := docker.DefaultOptions(t)
  r, err := docker.NewReplicationSetDocker(t, opts)
  if err != nil {
      t.Fatal(err)
  }
  defer r.Cleanup()

  ctx, cancel := context.WithTimeout(context.Background(), time.Minute)
  defer cancel()
  err = r.StandardPerfReplication(ctx)
  if err != nil {
    t.Fatal(err)
  }
}

func TestStandardDRReplication_Docker(t *testing.T) {
  opts := docker.DefaultOptions(t)
  r, err := docker.NewReplicationSetDocker(t, opts)
  if err != nil {
    t.Fatal(err)
  }
  defer r.Cleanup()

  ctx, cancel := context.WithTimeout(context.Background(), time.Minute)
  defer cancel()
  err = r.StandardDRReplication(ctx)
  if err != nil {
    t.Fatal(err)
  }
}

Наконец, вот пример запуска существующего docker-теста OSS с пользовательским бинарным файлом:

$ GOOS=linux make dev
$ VAULT_BINARY=$(pwd)/bin/vault go test -run 'TestRaft_Configuration_Docker' ./vault/external_tests/raft/raft_binary
ok      github.com/hashicorp/vault/vault/external_tests/raft/raft_binary        20.960s
Читать далее

Категории

Аутентификация и авторизацияИнструменты шифрования/дешифрованияУправление идентификациейБезопасность облачных средDevSecOpsОбнаружение СекретовУправление идентификацией и доступом (IAM)Аутентификация