Работа c Системой управления секретами#
В Platform V SOWA реализована интеграция с Системой управления секретами.
Система управления секретами - это инструмент для централизованного и безопасного хранения и распространения секретов.
Интеграция Platform V SOWA с Системой управления секретами дает возможность указания в прикладной конфигурации для секретов параметров загрузки из Системы управления секретами, как альтернативы кастомным ресурсам.
Platform V SOWA поддерживает использование движка KV Secrets Engine.
Параметры, используемые для интеграции с Системой управления секретами, описаны в разделе «Параметр vault» Руководства прикладного разработчика.
Для взаимодействия с Системой управления секретами используется аутентификация пользователя по токену. Для этого рекомендуется использовать внешние инструменты управления конфигурациями (jenkins/ansible/etc). Используется токен из переменной окружения $VAULT_TOKEN (переменная автоматически задается, например, в шаге jenkins при использовании функциональности плагина HashiCorp Vault) - с примером можно ознакомиться в конце документа.
Обновление секретов выполняется в момент выполнения операций с профилем - конфигурирование, запуск/перезапуск/перезагрузка (опционально, см. параметр runtime_update).
Ниже приведен пример конфигурации для использования секретов из Системы управления секретами:
system:
optional:
vault:
url: https://examplehost:8200
ssl:
ca: trusted_certs.pem
runtime_update: true
storages:
- path: DEV/SOWA/CF/KV
secrets:
- name: server
key: certificate
alias: cert_from_vault
- name: server
key: certificate_key
alias: key_from_vault
...
service:
service_main_proxy:
...
listen:
- port: 8443
ssl:
certificate: cert_from_vault
certificate_key: key_from_vault
...
Директива runtime_update позволяет включить обновление секретов профиля, хранимых в Системе управления секретами, при операциях запуска/перезапуска/перезагрузки. По умолчанию директива отключена - секреты подтягиваются только в момент конфигурирования профиля.
Пример использования плагина HashiCorp Vault в jenkins с аутентификацией по AppRole:
node {
// vaultCredAppRole - credentials типа VaultAppRoleCredential
withCredentials([[$class: 'VaultTokenCredentialBinding', credentialsId: 'vaultCredAppRole', vaultAddr: 'https://examplehost:8200']]) {
// теперь переменная окружения $VAULT_TOKEN заполнена - далее можно выполнять любые операции с профилем, использующим секреты из SecMan
...
}
}
Кроме того, возможно использовать аутентификацию по approle. Для этого пользователю необходимо два артефакта: файл, содержащий role_id, и файл, содержащий wrapped secret_id.
В таком случае конфигурация будет выглядеть следующим образом:
system:
optional:
vault:
url: https://examplehost:8200
ssl:
ca: trusted_certs.pem
runtime_update: true
storages:
- path: DEV/SOWA/CF/KV
approle_role_id_file: role.data
approle_wrapped_token_file: wrapped-secret.data
approle_namespace: NAMESPACE
secrets:
- name: server
key: certificate
alias: cert_from_vault
- name: server
key: certificate_key
alias: key_from_vault
...
service:
service_main_proxy:
...
listen:
- port: 8443
ssl:
certificate: cert_from_vault
certificate_key: key_from_vault
...
Также доступно автоматическое обновление секретов. При конфигурировании, если в профиле указан ключ с автоматическим обновлением, то для профиля добавляется зависимость на сервис, стартующий процесс. Т.е. при развертывании любого профиля с автоматическим обновлением секретов будет запущен процесс из юнита. Подразумевается, что на сервере такой процесс один. Допустим, ему соответствует еще какой-то профиль и процесс автоматического обновления уже работает. Если будут остановлены все профили с автоматическим обновлением секретов, то процесс при очередной итерации закроется и будет ждать запуска любого профиля с автоматическим обновлением снова.
Важно
При использовании автоматического обновления секретов происходит автоматический hotreload профиля для применения новых секретов. Обратите внимание, что hotreload не предусмотрен для плагинов, поэтому необходим ручной перезапуск профиля для применения изменений.
Для настройки расписания выполнения авторотации, возможно использовать директиву для настройки ротации vault_auto_update_schedule в файле /sowa/profile_storage/storage/settings.yml, которая на вход принимает строку в формате cron-расписания.
Например:
vault_auto_update_schedule: "*/1 * * * *"
При получении секретов JKS из SBERCA, если требуется использовать пароль от JKS, пользователь может указать плейсхолдер {{vaultSecret("<alias сертификата>")}}.
Пример заполнения для файла паролей плагина IPA: kafka-usock/from/*/rq/ssl-password={{vaultSecret("b64decoded_jks")}}.
Также рекомендуется ознакомиться с сопроводительной документацией Системы управления секретами: FAQ, Руководство пользователя, Инструкции по переходу на Secret Management.