Как использовать AppRole Hashicorp Vault в продакшене?

Без дополнительной поддержки со стороны вашей среды вам придется написать некоторую логику в вашем установщике и иметь своего рода диспетчер служб для запуска ваших служб. Во многих облачных средах у вас могут уже быть эквивалентные сущности (Terraform, Cloud Formation и т. Д.), И вам следует при необходимости использовать их возможности управления секретами.

Для пользовательских установок вот рабочий процесс, который я использовал.

1. Имейте процесс диспетчера установки, который можно вызвать для выполнения установки / обновления. Убедитесь, что установка / обновление служб всегда выполняется через этот процесс.
2. Имейте процесс диспетчера служб, который отвечает за запуск отдельных служб и их мониторинг / перезапуск. Убедитесь, что запуск службы всегда осуществляется через этого диспетчера службы.
3. Во время установки сгенерируйте самозаверяющие сертификаты для Vault, диспетчера установки и диспетчера служб. Сертификаты хранилища должны доверять сертификатам диспетчера установки и диспетчера служб. Храните их с ограниченным разрешением (600) в каталогах, принадлежащих пользователю установки или пользователю диспетчера служб, в зависимости от обстоятельств. Настройте аутентификацию на основе сертификатов в Vault с помощью этих сертификатов.
4. Эти учетные данные должны иметь ограниченные возможности, связанные с ними. Менеджер установки должен иметь возможность только создавать новые роли и ничего не удалять. Диспетчер служб должен иметь возможность создавать секреты только для названных ролей, созданных диспетчером установки, и ничего не удалять.
5. Во время установки / обновления менеджер установки должен подключиться к Vault и создать все необходимые роли для конкретных служб. Он также должен иметь возможность устанавливать идентификаторы ролей для отдельных служб в файлах конфигурации для каждой службы, которые службы могут читать при запуске.
6. Во время запуска каждой службы диспетчер служб должен подключиться к Vault и создать секретные идентификаторы, соответствующие роли каждой службы. Он должен установить секретный идентификатор в переменной среды и запустить службу. Секретный идентификатор должен иметь ограниченный по времени срок действия (путем установки TTL), чтобы их нельзя было использовать для чего-либо, кроме создания токена аутентификации (см. №7).
7. Каждая служба должна считывать идентификатор роли из файла конфигурации и секретный идентификатор из переменной среды. Затем он должен сгенерировать токен аутентификации, используя эти два, и использовать токен для аутентификации в хранилище в течение всего срока его службы.

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

Согласно AppRole Hashicorp Vault: идентификатор роли и идентификатор секрета < / а>:

• Сертификаты TLS могут хорошо работать в Windows, не знаю о Linux.
• GitHub Personal Access Tokens, но это не org. дружелюбный.
• Просмотрите другие доступные методы аутентификации, чтобы узнать, подходит ли тот, который соответствует вашим требованиям ( например, AWS).

Можно создать приложение Vault AppRole с secret_id, срок действия которого практически не истекает. Однако это должно быть ограничено использованием на сервере разработки Vault, который не содержит никаких производственных учетных данных, и для использования в среде разработки.

При этом вот процедура, которую я использовал на основе нескольких статей в документации Vault, но в первую очередь AppRole Pull Аутентификация.

Это предполагает, что метод аутентификации Vault approle уже установлен в approle/ и что вы вошли в Vault, имеете root или admin привилегии на сервере Vault и имеете действующий токен с неограниченным сроком действия.

Примечание. Для значений, указанных в полях ниже, максимальное значение, которое может принимать vault, составляет 999 999 999. Для полей TTL это количество секунд, которое превышает 31 год. Это не навсегда, но достаточно долго, чтобы обновление secret_id, вероятно, было чьей-то проблемой (SEP).

# Vault server address to be used by the Vault CLI.

export VAULT_ADDR="https://vault-dev.example.com:8200/"

# Vault namespace to be used by the CLI. 
#   Required for Cloud and Enterprise editions
#   Not applicable for Open Source edition

export VAULT_NAMESPACE="admin"

# The name of the Vault AppRole

export VAULT_ROLE=my-approle

# Override defaults on the approle authentication method

#   NOTE: In this command, the field names, default-lease-ttl
#         and max-lease-ttl contain dashes ('-'), NOT 
#         underscores ('_'), and are preceded by a single
#         dash ('-').

vault auth tune \
  -default-lease-ttl=999999999 \
  -max-lease-ttl=999999999 approle/

# Override defaults on the approle

#   NOTE: In this command, the field names, secret_id_ttl and 
#         secret_id_num contain underscores ('_'), NOT
#         dashes ('-'), and are NOT preceded by a single
#         dash ('-'). 

vault write auth/approle/role/my-approle \
  secret_id_ttl=999999999 \
  secret_id_num_uses=999999999

# Create a new secret_id for the approle which uses the new defaults

vault write -f auth/approle/role/my-approle/secret-id

Обновите файл конфигурации сервера, чтобы использовать новый secret_id, и все готово.