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

Содержание

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

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

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

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

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

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

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

../../../../_images/custom-credential-type-light1.svg

../../../../_images/custom-credential-type-dark1.svg

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

Возможны следующие способы передачи данных полномочия в среду принятия решений:
- переменная окружения;
- дополнительная переменная (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 форма для создания полномочий этого типа имеет следующий вид:

../../../../_images/credential-types-create-light.png

../../../../_images/credential-types-create-dark.png