Собственные типы полномочий

Event-Driven Ansible позволяет создавать собственные типы полномочий.

При создании собственного типа полномочий используются следующие понятия:

• Входная настройка определяет типы параметров, которые вводит пользователь при создании полномочия. Параметрами могут быть названия учетных записей, пароли, приватные ключи SSH и GPG, токены и тому подобное.

• Инжектор – механизм, выполняющий преобразование параметров полномочия в нужный формат.

• Внедрение данных (инжекция) – процесс передачи настроенного полномочия в среду принятия решений при активации свода правил.

Создание собственного типа полномочий имеет следующие особенности:

• Каждый тип полномочий должен содержать описание своих параметров (переменных) и параметры инжектора.

• Контроллер EDA не проверяет наличие коллизий названий переменных окружения, дополнительных переменных Ansible и пространств имен.

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

Работа контроллера EDA с собственными типами полномочий показана на схеме:

1. При создании собственного типа полномочий администратор задает типы параметров и настройку инжектора.

2. Пользователи создают необходимые экземпляры полномочий определенного типа.

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

4. Инжектор передает данные полномочия в среду принятия решений.

   Возможны следующие способы передачи данных полномочия в среду принятия решений:

   • переменная окружения;

   • дополнительная переменная (extra vars) Ansible;

   • текстовый файл, в том числе с возможностью генерации содержимого с использованием шаблонизатора Jinja.

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

Входная настройка

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

Типовые настройки входных параметров состоят из обязательного блока fields и необязательного блока required.

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

• id – идентификатор поля. Значение, указанное в этом поле, используется для передачи данных в инжектор.

  Обязательное поле.

• label – название поля при заполнении сведений о полномочии через графический интерфейс.

  Обязательное поле.

• type – тип поля:

  • string – строка;

  • boolean – логическое.

  Значение по умолчанию – string.

• format – дополнительная проверка корректности значения, указанного в поле типа string.

  Поддерживаются следующие значения:

  • ssh_private_key – приватный ключ SSH;

  • url – URI.

• multiline – логическое значение для полей типа string. При значении true поле позволяет вводить многострочный текст.

• choices – массив доступных значений для полей типа string. Если массив не пуст, при заполнении поля через графический интерфейс значение нужно выбрать из списка, а не вводить вручную.

• default – значение по умолчанию.

• secret – если равно true, вводимое значение является секретом.

  Для защиты секретов в полях ввода используется маскировка символов, а в таблице базы данных контроллера EDA – защитное преобразование.

• help_text – подсказка, которая выводится рядом с полем при заполнении сведений о полномочии через графический интерфейс.

В блоке required содержится список идентификаторов полей, обязательных для заполнения.

Конфигурация внедрения данных

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

---
extra_vars:
  auth_token: '{{ auth_token }}'

Дополнительной переменной Ansible auth_token присваивается значение поля входных данных с идентификатором auth_token.

Конфигурация внедрения данных может содержать следующие блоки:

• file – шаблон, на основе которого генерируется содержимое временного файла.

  Имя файла генерируется случайным образом. Оно хранится в переменной Ansible tower.filename.

  Если используется несколько полей для загрузки файлов, их следует описать в отдельных переменных, названия которых начинаются с префикса template.. Для получения имени файла следует обратиться к соответствующему значению словаря tower.filename, например:

  ---
  file:
    template.cert_file: '{{ tls_cert }}'
    template.key_file: '{{ tls_key }}'
  env:
    TLS_CERT_FILE_NAME: '{{ tower.filename.cert_file }}'
    TLS_KEY_FILE_NAME: '{{ tower.filename.key_file }}'
  

  Здесь для хранения сертификата и соответствующего ему ключа создаются два временных файла, имена которых сохраняются в переменных tower.filename.cert_file и tower.filename.key_file соответственно.

• env – список названий переменных окружения и соответствующих им значений.

• extra_vars – список названий дополнительных переменных Ansible и соответствующих им значений.

  Важно

  • Блок extra_vars обязателен к указанию в конфигурации внедрения данных.

  • При создании extra_vars не используйте eda или ansible в качестве имен ключей, так как это может привести к внутренним конфликтам.

Примеры

Пусть для работы с Kafka (источник событий) и Slack (целевая система для отправки уведомлений) нам потребуются следующие учетные данные:

• URL брокера Kafka.

  Значение передается в среду принятия решений через переменную окружения KAFKA_BROKER_URL.

• Название топика Kafka.

  Значение передается в среду принятия решений через переменную окружения KAFKA_TOPIC.

• Ключ API для Kafka.

  Значение передается в среду принятия решений через файл, название которого хранится в переменной окружения KAFKA_API_KEY_FILE.

• URL веб-обработчика Slack.

  Значение передается в среду принятия решений через файл, название которого хранится в переменной окружения SLACK_WEBHOOK_URL_FILE.

Параметр	Идентификатор	Тип	Обязательное
Адрес Kafka Broker	kafka_broker_url	string	Да
Название Kafka Topic	kafka_topic	string	Да
API Key для Kafka	kafka_api_key	string	Да
Webhook URL для Slack	slack_webhook_url	string	Да

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

Входная настройка

---
fields:
  - id: kafka_broker_url
    type: string
    label: Kafka Broker URL
    help_text: Enter the URL of the Kafka broker.

  - id: kafka_topic
    type: string
    label: Kafka Topic
    help_text: Enter the name of the Kafka topic to consume events from.

  - id: kafka_api_key
    type: string
    label: Kafka API Key
    secret: true
    help_text: Enter the API key for authenticating with Kafka.

  - id: slack_webhook_url
    type: string
    label: Slack Webhook URL
    secret: true
    format: url
    help_text: Enter the Slack webhook URL for sending messages.

required:
  - kafka_broker_url
  - kafka_topic
  - kafka_api_key
  - slack_webhook_url

Конфигурация внедрения данных

---
env:
  KAFKA_BROKER_URL: '{{ kafka_broker_url }}'
  KAFKA_TOPIC: '{{ kafka_topic }}'
  KAFKA_API_KEY_FILE: '{{ tower.filename.kafka_api_key }}'
  SLACK_WEBHOOK_URL_FILE: '{{ tower.filename.slack_webhook_url }}'

file:
  template.kafka_api_key: '{{ kafka_api_key }}'
  template.slack_webhook_url: '{{ slack_webhook_url }}'

extra_vars:
  kafka_broker_url: '{{ kafka_broker_url }}'
  kafka_topic: '{{ kafka_topic }}'
  kafka_api_key: '{{ kafka_api_key }}'
  slack_webhook_url: '{{ slack_webhook_url }}'

В графическом интерфейсе EDA форма для создания полномочий этого типа имеет следующий вид: