Интересный факт: включение шифрования на компонентах Zabbix не требует открытия дополнительных портов на фаерволлах, демоны Zabbiх поддерживают шифрованные и нешифрованные соединения одновременно.

• Пользователь (web-браузер) <-> Zabbix web-сервер. Управление конфигурацией Zabbix, представление метрик. Шифрование настраивается средствами web-сервера.
• Zabbix web-сервер <-> Zabbix-сервер. Web-сервер проверяет запущен ли Zabbix-сервер, запрашивает текущее состояние очереди, выполняет тест элементов данных и некоторые другие операции. Единственный поток, который в соответствии с архитектурой Zabbix нельзя зашифровать. Мы даже пытаться не будем.
• Zabbix web-сервер <-> База данных Zabbix. Web-сервер обновляет конфигурацию в БД, извлекает данные для визуализации, удаляет исторические данные (по нажатию на Очистить историю) и запускает задания Выполнить сейчас (Execute now). Можно настроить при установке или позже в файле конфигурации zabbix.conf.php. Поддерживается TLS-шифрование при помощи ключей. Для хранения логина и пароля для БД можно использовать Vault. Важный факт: сертификаты, защищённые паролем не поддерживаются.
• Zabbix-сервер <-> База данных Zabbix. Zabbix-сервер через configuration syncer загружает в свой кэш конфигурацию, через history syncer записывает собранные данные в БД, очищает историю (housekeeping) и выполняет некоторые другие операции. Настройки шифрования выполняются через присваивание значений специальным ключам в конфигурационном файле zabbix_server.conf.
• Zabbix-сервер <-> Zabbix-агент. Поддерживаются общий ключ PSK и сертификаты. Взаимодействие этих компонентов делится на две части: к узлу сети (TLSAccept для пассивных проверок) и от узла сети (TLSConnect для активных проверок).
• Zabbix-сервер <-> Zabbix-прокси. Поддерживаются общий ключ PSK и сертификаты. Настройки выполняются через присваивание значений специальным ключам в конфигурационном файле zabbix_proxy.conf.
• Zabbix-прокси <-> Zabbix-агент. Поддерживаются общий ключ PSK и сертификаты. Взаимодействие этих компонентов делится на две части: к узлу сети (TLSAccept для пассивных проверок) и от узла сети (TLSConnect для активных проверок).
• Zabbix-прокси <-> БД Zabbix-прокси. Настройки выполняются через присваивание значений специальным ключам в конфигурационном файле zabbix_proxy.conf.
• Zabbix sender -> Zabbix-прокси. Поддерживаются общий ключ PSK и сертификаты в качестве параметров при вызове через командную строку.
• Zabbix-агент -> Zabbix get. Поддерживаются общий ключ PSK и сертификаты в качестве параметров при вызове через командную строку.

Пользователь (web-браузер) <-> Zabbix web-сервер

Zabbix web-сервер <-> База данных Zabbix

mysql> CREATE USER    'zabbix_srv'@'%' IDENTIFIED WITH mysql_native_password BY '<strong_password>',    'zabbix_web'@'%' IDENTIFIED WITH mysql_native_password BY '<strong_password>' REQUIRE SSL    PASSWORD HISTORY 5; mysql> CREATE ROLE 'zabbix_srv_role', 'zabbix_web_role'; mysql> GRANT SELECT, UPDATE, DELETE, INSERT, CREATE, DROP, ALTER, INDEX, REFERENCES ON zabbix.* TO 'zabbix_srv_role'; mysql> GRANT SELECT, UPDATE, DELETE, INSERT ON zabbix.* TO 'zabbix_web_role'; mysql> GRANT 'zabbix_srv_role' TO 'zabbix_srv'@'%'; mysql> GRANT 'zabbix_web_role' TO 'zabbix_web'@'%'; mysql> SET DEFAULT ROLE 'zabbix_srv_role' TO 'zabbix_srv'@'%'; mysql> SET DEFAULT ROLE 'zabbix_web_role' TO 'zabbix_web'@'%';

Zabbix-сервер <-> База данных Zabbix

Zabbix-сервер <-> Zabbix-прокси

Zabbix-сервер <-> Zabbix-агент и Zabbix-прокси <-> Zabbix-агент

Zabbix-прокси <-> БД Zabbix-прокси

Zabbix sender -> Zabbix-прокси и Zabbix-агент -> Zabbix get

Авторегистрация с шифрованием

Хранение чувствительной информации в Vault

Заключение

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

Согласно недавнему исследованию ученых из Университета штата Северная Каролина, более 100 000 общедоступных репозиториев GitHub содержат открытые секреты приложений непосредственно в исходном коде. Это исследование от частных токенов API до криптографических ключей просканировало только около 13% общедоступных репозиториев GitHub показывает, что надлежащая защита секретов приложений является одним из наиболее часто игнорируемых методов защиты информации в программном обеспечении.

Хотя масштабы воздействия удивительны, важно отметить, что эта проблема затрагивает не только проекты с открытым исходным кодом. Даже частные репозитории исходного кода могут раскрывать секреты, если они не защищены должным образом. Возьмем, к примеру, нарушение безопасности в Buffer Inc. в 2013 году. То, что начиналось как незаконный доступ к собственному исходному коду Buffer, привело к утечке учетных данных Twitter API компании, что в конечном итоге привело к рассылке спама в учетных записях Twitter бесчисленных клиентов.

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

Введение в HashiCorp Vault

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

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

Установка Vault

Скачать Vault Vault от HashiCorp

Прежде чем мы сможем начать работу с Vault, нам сначала нужно его установить. Как и все продукты HashiCorp, Vault кроссплатформенный, с поддержкой macOS, Windows, Linux, Solaris и даже BSD. Вы даже можете запустить его на Raspberry Pi.

Запуск сервера

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

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

Чтобы запустить сервер разработки, просто запустите команду vault server -dev (-dev указывает, что мы должны запускать сервер разработки, а не рабочий сервер):

$ vault server -dev==> Vault server configuration:        Api Address: http://127.0.0.1:8200                Cgo: disabled    Cluster Address: https://127.0.0.1:8201        Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")        Log Level: info            Mlock: supported: false, enabled: false            Storage: inmem            Version: Vault v1.2.1WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memoryand starts unsealed with a single unseal key. The root token is alreadyauthenticated to the CLI, so you can immediately begin using Vault.You may need to set the following environment variable:    $ export VAULT_ADDR='http://127.0.0.1:8200'The unseal key and root token are displayed below in case you want to seal/unseal the Vault or re-authenticate.Unseal Key: p8MumXfy57bh2T1FxdvZSmHhxqr7aQAByPpfE4PLujk=Root Token: s.aSQmpEYEi5MKelf5TDLPC6r9Development mode should NOT be used in production installations!==> Vault server started! Log data will stream in below:

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

Также важно отметить значения Unseal Key и Root Token. Хотя мы коснемся того, что делать с Root Token в следующем разделе, понимание запечатывания / распечатывания Vault имеет решающее значение для правильного развертывания Vault в производственной среде.

Расшифровка и аутентификация

В производственной среде сервер Vault запускается в закрытом состоянии. Это означает, что Vault знает, где находятся данные, но не знает, как их расшифровать. На сервере разработки Vault по умолчанию не запечатан (unsealed). Однако, если вы решите запечатать его, вы получите ключ распечатки (Unseal Key), чтобы распечатать (unseal) его. Незапечатанный Vault остается в этом состоянии до тех пор, пока оно не будет повторно запечатано или сам сервер не будет перезапущен.

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

$ vault operator initUnseal Key 1: 4jYbl2CBIv6SpkKj6Hos9iD32k5RfGkLzlosrrq/JgOmUnseal Key 2: B05G1DRtfYckFV5BbdBvXq0wkK5HFqB9g2jcDmNfTQiSUnseal Key 3: Arig0N9rN9ezkTRo7qTB7gsIZDaonOcc53EHo83F5chAUnseal Key 4: 0cZE0C/gEk3YHaKjIWxhyyfs8REhqkRW/CSXTnmTilv+Unseal Key 5: fYhZOseRgzxmJCmIqUdxEm9C3jB5Q27AowER9w4FC2CkInitial Root Token: s.KkNJYWF5g0pomcCLEmDdOVCWVault initialized with 5 key shares and a key threshold of 3. Please securely distribute the key shares printed above. When the Vault is re-sealed, restarted, or stopped, you must supply at least 3 of these keys to unseal it before it can start servicing requests.Vault does not store the generated master key. Without at least 3 keys to reconstruct the master key, Vault will remain permanently sealed!It is possible to generate new unseal keys, provided you have a quorum of existing unseal keys shares. See "vault operator rekey" for more information.

Вход в систему

Когда сервер запущен, следующее, что нам нужно сделать, это войти в него. Это можно сделать с помощью команды vault login, которая запросит токен аутентификации. При первоначальной настройке вы можете пройти аутентификацию с помощью Root Token (см. Выше). Однако в производственной среде базовые методы аутентификации можно изменить, чтобы обеспечить более точный контроль над тем, кто имеет доступ и почему:

$ vault loginToken (will be hidden):Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token.Key                 Value---                 -----token               s.aSQmpEYEi5MKelf5TDLPC6r9token_accessor      MaJhao2R54EdV9fDq7sL11d4token_duration      token_renewable     falsetoken_policies      ["root"]identity_policies   []policies            ["root"] 

Хранение секретов

В то время как Vault HashiCorp можно использовать для безопасного хранения практически любых данных, наиболее распространенным вариантом использования Vault является хранилище ключей и значений для секретов приложений. После проверки подлинности хранение секретов становится невероятно простым благодаря команде vault kv put:

$ vault kv put secret/foo bar=bazKey             Value---             -----created_time    2019-08-09T16:43:10.604124Zdeletion_time   n/adestroyed       falseversion         1

Чтобы немного разобрать приведенную выше команду и ответ, мы создали новый секрет с именем foo в пространстве имен secret со значением bar=baz, ответ дает нам некоторые базовые метаданные о нашем новом секрете. Хотя ключи created_time, deletion_time и destroyed не требуют пояснений, вам следует обратить особое внимание на ключ version, потому что это подразумевает, что секреты могут быть версированы.

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

$ vault kv put secret/foo bat=ballKey             Value---             -----created_time    2019-08-09T16:43:32.638788Zdeletion_time   n/adestroyed       falseversion         2

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

Извлечение секретов

$ vault kv list secretKeys----foo

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

Как видите, хотя технически мы помещаем два секрета, отслеживается только один ключ, потому что эти два секрета на самом деле являются всего лишь двумя версиями одного секрета. Чтобы получить его, выполните команду vault kv get с секретным пространством имен и ключом:

$ vault kv get secret/foo====== Metadata ======Key             Value---             -----created_time    2019-08-09T16:43:32.638788Zdeletion_time   n/adestroyed       falseversion         2=== Data ===Key Value--- -----bat ball

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

$ vault kv get -version=1 secret/foo====== Metadata ======Key             Value---             -----created_time    2019-08-09T16:43:10.604124Zdeletion_time   n/adestroyed       false   version         1=== Data ===Key Value--- -----bar baz

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

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

Несмотря на преимущества контроля секретами, нам может понадобится фактическое удаление секрета (или его версии). Это можно сделать двумя способами, в зависимости от того, насколько удаленным вы хотите, чтобы секрет был: удалить delete и уничтожить destroy. Чтобы проиллюстрировать это, давайте сначала рассмотрим удаление версии нашего секрета foo:

$ vault kv delete -versions=1 secret/fooSuccess! Data deleted (if it existed) at: secret/foo

Это помечает данные как удаленные (deleted) и предотвращает их извлечение в обычных запросах GET, но фактически не удаляет данные:

$ vault kv get -version=1 secret/foo====== Metadata ======Key             Value---             -----created_time    2019-08-09T16:43:10.604124Zdeletion_time   2019-08-09T16:45:39.664577Zdestroyed       falseversion         1

Чтобы данные действительно были удалены без возможности восстановления, необходимо использовать команду destroy:

$ vault kv destroy -versions=1 secret/fooSuccess! Data written to: secret/destroy/foo

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

$ vault kv get -version=1 secret/foo====== Metadata ======Key             Value---             -----created_time    2019-08-09T16:43:10.604124Zdeletion_time   2019-08-09T16:45:39.664577Zdestroyed       trueversion         1

Копаем глубже в HashiCorp Vault

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

Secrets engines

$ vault secrets enable databaseSuccess! Enabled the database secrets engine at: database/

Хранилище ключей и значений по умолчанию в Vault является примером механизма секретов (в частности, механизма под названием kv). По своей сути алгоритм секретов это абстрактный механизм хранения секретных данных. Это означает, что вместо механизма хранения на основе ключа-значения можно использовать более целевые механизмы хранения. Например, механизм секретов базы данных может использоваться для динамического генерирования учетных данных базы данных (database) на основе настроенных ролей для MySQL и MariaDB, что позволяет производить автоматическую ротацию учетных данных root или даже временные учетные данные для доступа по запросу.

Методы аутентификации

$ vault auth enable githubSuccess! Enabled github auth method at: github/

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

Авторизация

$ vault write auth/userpass/users/test policies="dev-readonly,logs"

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

За пределами Vault

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

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

Предыстория

Предыдущая статья

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

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

Итак, ну а теперь, давайте добавим в наш проектик буквально пару строк кода + я покажу, как со всем этим можно работать, если ваш проект локально запускается в docker-compose.

Готовим код

Для начала, давайте договоримся, что local_mode действует тогда, когда ENV = "local" :) Далее, я предлагаю немного отредактировать наш provider_config.py и создать там класс BaseConfig от которого мы будем наследовать в наших настройках Config классы. Мы сделаем это для того, чтобы не дублировать код, то есть в самих классах настроек будет только то, что специфично для них.

import hvacfrom sitri.providers.contrib.system import SystemConfigProviderfrom sitri.providers.contrib.vault import VaultKVConfigProviderfrom sitri.settings.contrib.vault import VaultKVSettingsconfigurator = SystemConfigProvider(prefix="superapp")ENV = configurator.get("env")is_local_mode = ENV == "local"local_mode_file_path = configurator.get("local_mode_file_path")def vault_client_factory() -> hvac.Client:    client = hvac.Client(url=configurator.get("vault_api"))    client.auth_approle(        role_id=configurator.get("role_id"),        secret_id=configurator.get("secret_id"),    )    return clientprovider = VaultKVConfigProvider(    vault_connector=vault_client_factory,    mount_point=f"{configurator.get('app_name')}/{ENV}",)class BaseConfig(VaultKVSettings.VaultKVSettingsConfig):    provider = provider    local_mode = is_local_mode    local_provider_args = {"json_path": local_mode_file_path}

Немного про local_provider_args в этом поле мы указываем аргументы для создания экземпляра JsonConfigProvider, они будут провалидированы и данный словарь должен соотвествовать схеме, поэтому не волнуйтесь это не какой-то грязный приём. Однако, если вы хотите создать экземпляр локального провайдера сами, то вы просто положить его в опциональное поле local_provider.

Теперь, мы можем спокойно наследовать конфиг классы от базового. Например, класс настроек для соединения с Kafka будет выглядеть так:

from typing import Any, Dictfrom pydantic import Fieldfrom sitri.settings.contrib.vault import VaultKVSettingsfrom superapp.config.provider_config import BaseConfig, configuratorclass KafkaSettings(VaultKVSettings):    mechanism: str = Field(..., vault_secret_key="auth_mechanism")    brokers: str = Field(...)    auth_data: Dict[str, Any] = Field(...)    class Config(BaseConfig):        default_secret_path = "kafka"        default_mount_point = f"{configurator.get('app_name')}/common"        local_mode_path_prefix = "kafka"

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

{    "db":    {        "host": "testhost",        "password": "testpassword",        "port": 1234,        "user": "testuser"    },    "faust":    {        "agents":        {            "X":            {                "concurrency": 2,                "partitions": 5            }        },        "app_name": "superapp-workers",        "default_concurrency": 5,        "default_partitions_count": 10    },    "kafka":    {        "auth_data":        {            "password": "testpassword",            "username": "testuser"        },        "brokers": "kafka://test",        "mechanism": "SASL_PLAINTEXT"    }}

Ну, или просто скопипастим его из конца прошлой статьи. Как видите, тут всё весьма просто. Для наших дальнейших изысканий, переименуем main.py в корне проекта на __main__.py, чтобы можно было запустить пакет командой из docker-compose.

Запихиваем приложение в контейнер и наслаждаемся сборкой

Первое, что мы должны сделать это написать небольшой Dockerfile:

FROM python:3.8.3-busterENV PYTHONUNBUFFERED=1 \    POETRY_VIRTUALENVS_CREATE=false \    POETRY_VIRTUALENVS_IN_PROJECT=false \    POETRY_NO_INTERACTION=1RUN pip install poetryRUN mkdir /superapp/WORKDIR /superapp/COPY ./pyproject.toml ./poetry.lock /superapp/RUN poetry install --no-ansiWORKDIR /

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

Далее, нам понадобиться env-файл с необходимыми для local-mode переменными:

SUPERAPP_ENV=localSUPERAPP_LOCAL_MODE_FILE_PATH=/config.jsonSUPERAPP_APP_NAME=superapp

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

Ну и последнее, что мы должны написать сам docker-compose.yml файл:

# docker-compose config for local developmentversion: '3'services:  superapp:    command: python3 -m superapp    restart: always    build:      context: ./      dockerfile: Dockerfile    volumes:      - ./superapp:/superapp      - ./config.json:/config.json    env_file:      - .env.local

Как видите, тут тоже всё просто. Наш json-файл мы кладём в корень, как и указали выше в переменной окружения для контейнера.

Ну а теперь, запуск:

docker-compose up

Creating article_sitri_vault_pydantic_superapp_1 ... doneAttaching to article_sitri_vault_pydantic_superapp_1superapp_1  | db=DBSettings(user='testuser', password='testpassword', host='testhost', port=1234) faust=FaustSettings(app_name='superapp-workers', default_partitions_count=10, default_concurrency=5, agents={'X': AgentConfig(partitions=5, concurrency=2)}) kafka=KafkaSettings(mechanism='SASL_PLAINTEXT', brokers='kafka://test', auth_data={'password': 'testpassword', 'username': 'testuser'})superapp_1  | {'db': {'user': 'testuser', 'password': 'testpassword', 'host': 'testhost', 'port': 1234}, 'faust': {'app_name': 'superapp-workers', 'default_partitions_count': 10, 'default_concurrency': 5, 'agents': {'X': {'partitions': 5, 'concurrency': 2}}}, 'kafka': {'mechanism': 'SASL_PLAINTEXT', 'brokers': 'kafka://test', 'auth_data': {'password': 'testpassword', 'username': 'testuser'}}}

Как видите, всё успешно запустилось и информация из нашего json-фала успешно прошла все проверки и стала настройками для локальной версии приложения, юхху!

Код этой статьи я положил в отдельную ветку, так что можете зайти, склонить и протестировать всё самолично :)
branch

Предисловие

В данной статье я расскажу о конфигурации для вашей сервисов с помощью связки Vault (KV и пока только первой версии, т.е. без версионирования секретов) и Pydantic (Settings) под патронажем Sitri.

Итак, допустим, что у нас есть приложение superapp с заведёнными конфигами в Vault и аутентификацией с помощью approle, примерно так настроим (настройку policies для доступа к секрет-энжайнам и к самим секретам я оставлю за кадром, так как это достаточно просто и статья не об этом):

Key                        Value---                        -----bind_secret_id             truelocal_secret_ids           falsepolicies                   [superapp_service]secret_id_bound_cidrs      <nil>secret_id_num_uses         0secret_id_ttl              0stoken_bound_cidrs          []token_explicit_max_ttl     0stoken_max_ttl              30mtoken_no_default_policy    falsetoken_num_uses             50token_period               0stoken_policies             [superapp_service]token_ttl                  20mtoken_type                 default

Прим.: естественно, что если у вас есть возможность и приложение выходит в боевой режим, то secret_id_ttl лучше делать не бесконечным, выставляя 0 секунд.

SuperApp требует конфигурации: подключения к базе данных, подключение к kafka и faust конфигурации для работы кластера воркеров.

Подготовим Sitri

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

Итак, для начала сконфигурируем vault-провайдер в условном файле provider_config.py:

import hvac  from sitri.providers.contrib.vault import VaultKVConfigProvider  from sitri.providers.contrib.system import SystemConfigProvider  configurator = SystemConfigProvider(prefix="superapp")  ENV = configurator.get("env")  def vault_client_factory() -> hvac.Client:      client = hvac.Client(url=configurator.get("vault_api"))      client.auth_approle(          role_id=configurator.get("role_id"),    secret_id=configurator.get("secret_id"),    )      return client  provider = VaultKVConfigProvider(      vault_connector=vault_client_factory, mount_point=f"{configurator.get('app_name')}/{ENV}"  )

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

export SUPERAPP_ENV=devexport SUPERAPP_APP_NAME=superappexport SUPERAPP_VAULT_API=https://your-vault-host.domainexport SUPERAPP_ROLE_ID=535b268d-b858-5fb9-1e3e-79068ca77e27 # Примерexport SUPERAPP_SECRET_ID=243ab423-12a2-63dc-3d5d-0b95b1745ccf # Пример

В примере предполагается, что базовый mount_point к вашим секретам для определённой среды будет содержать имя приложения и имя среды, поэтому мы и экспортировали SUPERAPP_ENV. Путь до секретов отдельных частей приложения мы будем определять в settings-классах далее, поэтому в провайдере secret_path мы оставляем пустым.

Классы настроек

Начнём по пунктам и разнесём три класса настроек (БД, Kafka, Faust) по трём разным файлам.

Настройки БД

from pydantic import Field  from sitri.settings.contrib.vault import VaultKVSettings  from superapp.config.provider_config import provider  class DBSettings(VaultKVSettings):      user: str = Field(..., vault_secret_key="username")      password: str = Field(...)      host: str = Field(...)      port: int = Field(...)      class Config:          provider = provider          default_secret_path = "db"

Итак, как видите, конфиг. данные для базы у нас достаточно простые. Этот класс будет по-умолчанию смотреть в секрет superapp/dev/db, так, как мы указали в config классе, в остальном здесь простые pydantic поля, но в одном из них присутствует extra-аргумент vault_secret_key он нужен тогда, когда ключ в секрете не совпадает по имени с pydantic полем в нашем классе, если его не указывать, то провайдер будет искать ключ по имени поля.

Например, в нашем тестовом приложении, предполагается, что в секрете superapp/dev/db, есть ключи password и username, но мы хотим, чтобы последний был помещён в поле user для удобства и краткости.

Поместим в вышеозначенный секрет следующие данные для примера:

{  "host": "testhost",  "password": "testpassword",  "port": "1234",  "username": "testuser"}

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

db_settings = DBSettings()pprint(db_settings.dict())# -> # {#     "host": "testhost",#     "password": "testpassword",#     "port": 1234,#     "user": "testuser"# }

Настройки Kafka

from typing import Dict, Any  from pydantic import Field  from sitri.settings.contrib.vault import VaultKVSettings  from superapp.config.provider_config import provider, configurator  class KafkaSettings(VaultKVSettings):      mechanism: str = Field(..., vault_secret_key="auth_mechanism")      brokers: str = Field(...)      auth_data: Dict[str, Any] = Field(...)      class Config:          provider = provider          default_secret_path = "kafka"          default_mount_point = f"{configurator.get('app_name')}/common"

В данном случае, представим, что инстанс кафки для разных сред нашего сервиса один, поэтому секрет хранится по пути superapp/common/kafka

{  "auth_data": "{\"password\": \"testpassword\", \"username\": \"testuser\"}",  "auth_mechanism": "SASL_PLAINTEXT",  "brokers": "kafka://test"}

Класс настройки поймёт комплексный тип данных Dict[str, Any] и распарсит его в словарь, то есть при заполнении наших настроек будут следующие данные:

{    "auth_data":    {        "password": "testpassword",        "username": "testuser"    },    "brokers": "kafka://test",    "mechanism": "SASL_PLAINTEXT"}

Так же, если секрет будет задан напрямую в json, например так:

{  "auth_data": {    "password": "testpassword",    "username": "testuser"  },  "auth_mechanism": "SASL_PLAINTEXT",  "brokers": "kafka://test"}

То класс настроек тоже сможет правильно разложить данные.

P.S.
Так же, secret_path и mount_point можно задавать на уровне полей, чтобы провайдер запросил конкретные значения из разных секретов (если это требуется). Приведу цитату с приоритезацией пути секрета и точки монтирования из документации:

Secret path prioritization:

1. vault_secret_path (Field arg)
2. default_secret_path (Config class field)
3. secret_path (provider initialization optional arg)

Mount point prioritization:

1. vault_mount_point (Field arg)
2. default_mount_point (Config class field)
3. mount_point (provider initialization optional arg)

Настройки Faust и отдельных воркеров

from typing import Dict  from pydantic import Field, BaseModel  from sitri.settings.contrib.vault import VaultKVSettings  from superapp.config.provider_config import provider  class AgentConfig(BaseModel):      partitions: int = Field(...)      concurrency: int = Field(...)  class FaustSettings(VaultKVSettings):      app_name: str = Field(...)      default_partitions_count: int = Field(..., vault_secret_key="partitions_count")      default_concurrency: int = Field(..., vault_secret_key="agent_concurrency")      agents: Dict[str, AgentConfig] = Field(default=None, vault_secret_key="agents_specification")      class Config:          provider = provider          default_secret_path = "faust"

superapp/dev/faust:

{  "agent_concurrency": "5",  "app_name": "superapp-workers",  "partitions_count": "10"}

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

{  "agents": None,  "app_name": "superapp-workers",  "default_concurrency": 5,  "default_partitions_count": 10}

Например, у нас есть агент X с настройками:

{  "partitions": 5,  "concurrency": 2}

Наш секрет в связи с этим должен выглядеть следующим образом:

{  "agent_concurrency": "5",  "agents_specification": {    "X": {      "concurrency": "2",      "partitions": "5"    }  },  "app_name": "superapp-workers",  "partitions_count": "10"}

Как и ожидалось данные корректно смапились и типы значений были преобразованы так, как указано в модели AgentConfig:

{    "agents":    {        "X":        {            "concurrency": 2,            "partitions": 5        }    },    "app_name": "superapp-workers",    "default_concurrency": 5,    "default_partitions_count": 10}

Совмещаем в единый конфиг класс

from pydantic import BaseModel, Field  from superapp.config.database_settings import DBSettings  from superapp.config.faust_settings import FaustSettings  from superapp.config.kafka_settings import KafkaSettings  class AppSettings(BaseModel):      db: DBSettings = Field(default_factory=DBSettings)      faust: FaustSettings = Field(default_factory=FaustSettings)      kafka: KafkaSettings = Field(default_factory=KafkaSettings)

Совместим наши классы настроек в одну модель, применив default_factory для автоматического сбора при инициализации модели всех наших данных.

Давайте запустим наш код и проверим, как всё сработается вместе:

from superapp.config import AppSettings  config = AppSettings()  print(config)  print(config.dict())

Получаем общий вывод всей конфигурации приложения:

db=DBSettings(user='testuser', password='testpassword', host='testhost', port=1234) faust=FaustSettings(app_name='superapp-workers', default_partitions_count=10, default_concurrency=5, agents={'X': AgentConfig(partitions=5, concurrency=2)}) kafka=KafkaSettings(mechanism='SASL_PLAINTEXT', brokers='kafka://test', auth_data={'password': 'testpassword', 'username': 'testuser'})

{    "db":    {        "host": "testhost",        "password": "testpassword",        "port": 1234,        "user": "testuser"    },    "faust":    {        "agents":        {            "X":            {                "concurrency": 2,                "partitions": 5            }        },        "app_name": "superapp-workers",        "default_concurrency": 5,        "default_partitions_count": 10    },    "kafka":    {        "auth_data":        {            "password": "testpassword",            "username": "testuser"        },        "brokers": "kafka://test",        "mechanism": "SASL_PLAINTEXT"    }}

Счастье, радость, восторг!

У нас получилась такая структура тест-проекта:

superapp config    app_settings.py    database_settings.py    faust_settings.py    __init__.py    kafka_settings.py    provider_config.py __init__.py main.py

Послесловие

Как видите настройка достаточно проста с Sitri, после неё мы получаем чёткую схему конфигурации с нужными нам типами данных у значений, даже если в vault по-умолчанию они хранились строками.

Пишите комментарии по поводу либы, кода или общие впечатления. Буду рад любому отзыву!

P.S. Код из статьи я залил на github https://github.com/Egnod/article_sitri_vault_pydantic