Введение в Убежище

Архитектура Убежища обманчиво проста. Его основными компонентами являются:

секреты ** Количество __secret движков, __one для каждого типа поддерживаемого секрета

тип

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

когда нужно и откажитесь ** Мы можем использовать недолговечные секреты, тем самым ограничивая «окно

возможность », где злоумышленник может использовать украденный секрет

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

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

Позже мы рассмотрим шаги, необходимые для генерации мастер-ключа и распечатывания экземпляра Vault.

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

При первоначальной установке Vault автоматически генерирует «корневой токен».

Этот токен эквивалентен суперпользователю root в системах Linux, поэтому его использование должно быть ограничено до минимума. Рекомендуется использовать этот корневой токен только для того, чтобы создавать другие токены с меньшими привилегиями, а затем отзывать их. Однако это не проблема, поскольку позже мы можем сгенерировать еще один корневой токен, используя незапечатанные ключи.

Vault также поддерживает другие механизмы аутентификации, такие как LDAP, JWT, TLS Certificates и другие. Все эти механизмы основаны на базовом механизме токенов: после того, как Vault проверит наш клиент, он предоставит токен, который мы затем сможем использовать для доступа к другим API.

Токены имеют несколько свойств, связанных с ними. Основными свойствами являются:

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

Обратное неверно: мы можем - и обычно делаем - создаем дочерний токен с ограничительной политикой. Еще один ключевой момент в этих отношениях:

Здесь мы использовали синтаксис HCL (язык конфигурации Hashicorp) для определения нашей политики. Vault также поддерживает JSON для этой цели, но мы будем придерживаться HCL в наших примерах, поскольку его легче читать.

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

Политики, описанные до сих пор, также называются политиками списка контроля доступа или политиками ACL. Vault также поддерживает два дополнительных типа политик: политики EGP и RGP. Они доступны только в платных версиях и расширяют основной синтаксис политики с поддержкой Sentinel .

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

Более подробную информацию о синтаксисе политики можно найти в документации Vault .

Позже мы используем один и тот же путь для извлечения одной и той же пары или пар - несколько пар могут храниться по одному и тому же пути.

Хранилище поддерживает три вида секретов Key-Value:

версии ** Cubbyhole , специальный тип не версионных пар ключей, значения которых

ограничены данным токеном access (подробнее об этом позже).

Секреты Key-Value статичны по своей природе, поэтому с ними не связано понятие истечения срока действия. Основным вариантом использования этого типа секрета является хранение учетных данных для доступа к внешним системам, таким как ключи API.

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

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

Затем мы определяем одну или несколько ролей, которые описывают фактическое создание секрета.

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

Затем мы создаем одну или несколько ролей (роли Vault, а не роли базы данных), содержащие фактические операторы SQL, используемые для создания нового пользователя. Они обычно включают не только оператор создания пользователя, но также все необходимые операторы grant , необходимые для доступа к объектам схемы (таблицам, представлениям и т. Д.).

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

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

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

В настоящее время существует только один движок этого типа: движок Transit .

Этот механизм поддерживает популярные типы ключей, такие как RSA и ECDSA, а также поддерживает Convergent Encryption. При использовании этого режима заданное значение открытого текста всегда приводит к одному и тому же результату шифрованного текста, что очень полезно в некоторых приложениях.

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

Vault использует файл конфигурации в формате HCL или JSON. Следующий файл определяет всю конфигурацию, необходимую для запуска нашего сервера с использованием файлового хранилища и самозаверяющего сертификата:

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

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

Наш сервер Vault сейчас работает, но поскольку это его первый запуск, нам нужно его инициализировать.

Для этого откроем новую оболочку и выполним следующие команды:

Здесь мы определили несколько переменных среды, поэтому нам не нужно каждый раз передавать их в Vault в качестве параметров:

В нашем случае мы используем VAULT CACERT__, чтобы мы могли использовать HTTPS для доступа к API Vault. Нам это нужно, потому что мы используем самозаверяющие сертификаты.

Это не было бы необходимо для производственных сред, где мы обычно имеем доступ к сертификатам, подписанным CA.

После выполнения вышеуказанной команды мы должны увидеть сообщение, подобное этому:

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

Также обратите внимание на root токен , так как он понадобится нам позже.

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

Давайте посмотрим состояние нашего сервера теперь, когда мы его инициализировали, с помощью следующей команды:

Мы видим, что Убежище все еще запечатано. Мы также можем следить за прогрессом распечатки: «0/3» означает, что Vault нужны три акции, но пока нет ни одной. Давайте двигаться вперед и обеспечить его нашими акциями.

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

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

В этом случае свойство «Sealed» имеет значение «false», что означает, что Vault готов принимать команды.

Во-первых, давайте сохраним секретные пары ключ-значение и прочитаем их обратно. Предполагая, что командная оболочка, используемая для инициализации Vault, все еще открыта, мы используем следующую команду для сохранения этих пар по пути secret/fakebank :

Теперь мы можем восстановить эти пары в любое время с помощью следующей команды:

Этот простой тест показывает нам, что Vault работает как надо. Теперь мы можем протестировать некоторые дополнительные функции.

До сих пор мы использовали корневой токен для аутентификации наших запросов. Поскольку корневой токен является way слишком мощным, рекомендуется использовать токены с меньшими привилегиями и меньшим временем жизни.

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

$ export VAULT TOKEN=<token value> $ vault kv get secret/fakebank ======= Data ======= Key Value --- ----- api key abc1234 api__secret 1a2b3c4d

$ vault kv get secret/fakebank Error making API request.

URL: GET https://localhost:8200/v1/sys/internal/ui/mounts/secret/fakebank Code: 403. Errors:

$ cat > sample-policy.hcl <<EOF path "secret/fakebank" { capabilities =["read"]} EOF $ export VAULT__TOKEN=<root token> $ vault policy write fakebank-ro ./sample-policy.hcl Success! Uploaded policy: fakebank-ro

$ export VAULT TOKEN=<root token> $ vault token create -policy=fakebank-ro Key Value --- ----- token <token value> token accessor <token accessor value> token duration 768h token renewable true token policies ["default" "fakebank-ro"]identity policies []policies ["default" "fakebank-ro"]----

Как мы делали раньше, давайте прочитаем наши секретные значения, используя этот токен:

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

Поскольку наша политика явно не разрешает запись, Vault возвращает код состояния 403 - Доступ запрещен.

В качестве последнего примера в этой статье давайте используем секретный механизм базы данных Vault для создания динамических учетных данных. Здесь мы предполагаем, что у нас есть сервер MySQL, доступный локально, и что мы можем получить к нему доступ с правами root. Мы также будем использовать очень простую схему, состоящую из одной таблицы - account .

Сценарий SQL, используемый для создания этой схемы и привилегированного пользователя, доступен здесь.

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

$ vault write database/config/mysql-fakebank \ plugin name=mysql-legacy-database-plugin \ connection url="{{username}}:{{password}}@tcp(127.0.0.1:3306)/fakebank" \ allowed__roles="** " \ username="fakebank-admin" \ password="Sup&rSecre7!"

$ vault write database/roles/fakebank-accounts-ro \ db name=mysql-fakebank \ creation statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON fakebank.** TO '{{name}}'@'%';"

$ vault read database/creds/fakebank-accounts-ro Key Value --- ----- lease id database/creds/fakebank-accounts-ro/0c0a8bef-761a-2ef2-2fed-4ee4a4a076e4 lease duration 1h lease__renewable true password <password> username <username>

$ mysql -h 127.0.0.1 -u <username> -p fakebank Enter password: MySQL[fakebank]> select ** from account; …​ omitted for brevity 2 rows in set (0.00 sec) MySQL[fakebank]> delete from account; ERROR 1142 (42000): DELETE command denied to user 'v-fake-9xoSKPkj1'@'localhost' for table 'account'