Полномочия#

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

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

Поддерживаемые типы полномочий#

В Astra Automation Controller поддерживаются следующие типы полномочий:

API-токен Ansible Galaxy/Automation Hub (Ansible Galaxy/Automation Hub API Token);
Centrify Vault Credential Provider Lookup;
CyberArk Central Credential Provider Lookup;
CyberArk Conjur Secrets Manager Lookup;
Google Compute Engine;
GPG Public Key;
HashiCorp Vault Secret Lookup;
HashiCorp Vault Signed SSH;
Insights;
Microsoft Azure Key Vault;
OpenStack;
Red Hat Satellite 6;
Thycotic DevOps Secrets Vault;
Thycotic Secret Server;
Vault;
VMware vCenter;
Web-сервисы Amazon (Amazon Web Services);
Виртуализация Red Hat (Red Hat Virtualization);
Диспетчер ресурсов Microsoft Azure (Microsoft Azure Resource Manager);
Личный токен доступа к GitHub (GitHub Personal Access Token);
Машина (Machine);
Платформа автоматизации Red Hat Ansbile (Red Hat Ansible Automation Platform);
Реестр контейнеров (Container Registry);
Сеть (Network);
Токен персонального доступа GitLab (GitLab Personal Access Token);
Токен доступа OpenShift или Kubernetes API (OpenShift or Kubernetes API Bearer Token);
Управление версиями (Source Control).

Примечание

По умолчанию при развертывании контроллера в нем создаются полномочия для доступа к Ansible Galaxy типа «Ansible Galaxy/Automation Hub». Контроллер позволяет добавлять собственные типы полномочий.

Также Astra Automation Controller позволяет создавать собственные типы полномочий.

API-токен Ansible Galaxy/Automation Hub#

Полномочия этого типа используются для доступа к Ansbile Galaxy или коллекциям, опубликованным в частном Automation Hub.

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

токен доступа, создаваемый пользователем на сервере Galaxy;
адрес сервера Keykcloak для выдачи токена (при использовании SSO).

Centrify Vault Credential Provider Lookup#

Полномочия этого типа используются для доступа к системе управления секретами Centrify Vault Credential Provider.

CyberArk Central Credential Provider Lookup#

Полномочия этого типа используются для доступа к системе управления секретами CyberArk Central Credential Provider. Для использования данной интеграции требуется запущенный веб-сервис хранения секретов CyberArk Central Credential Provider.

Поддерживается защита подключения с помощью SSL.

CyberArk Conjur Secrets Manager Lookup#

Полномочия этого типа используются для доступа к системе управления секретами CyberArk Conjur Secrets Manager.

Google Compute Engine#

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

Для создания полномочий этого типа необходимо предоставить следующие данные о сервисной учетной записи Google Compute Cloud:

адрес электронной почты;
закрытый ключ RSA, связанный с указанным адресом электронной почты.

Совет

Для автоматического заполнения реквизитов сервисной учетной записи Google Compute Cloud можно использовать файл в формате JSON. Пошаговые инструкции по созданию такого файла см. в документации Google Compute Cloud.

GPG Public Key#

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

HashiCorp Vault Secret Lookup#

Полномочия этого типа используются для доступа к системе управления секретами HashiCorp Vault.

HashiCorp Vault Signed SSH#

Полномочия этого типа используются для доступа к подписанным сертификатам HashiCorp Vault SSH.

Insights#

Полномочия этого типа используются для доступа к списку управляемых узлов в Red Hat Insights.

Microsoft Azure Key Vault#

Полномочия этого типа используются для доступа к списку управляемых узлов в Microsoft Azure Key Vault.

OpenStack#

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

Поддерживается защита подключения с помощью SSL.

Red Hat Satellite 6#

Полномочия этого типа используются для доступа к списку управляемых узлов в Red Hat Satellite 6.

Thycotic DevOps Secrets Vault#

Полномочия этого типа используются для доступа к системе управления секретами Thycotic DevOps Secrets Vault.

Thycotic Secret Server#

Полномочия этого типа используются для доступа к серверу секретов Thycotic Secret Server.

Vault#

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

Если необходим доступ к нескольким хранилищам, необходимо предоставить соответствующие им идентификаторы Vault.

VMware vCenter#

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

Web-сервисы Amazon#

Полномочия этого типа используются для доступа к списку управляемых узлов в Web-сервисах Amazon.

Для создания полномочий этого типа необходимо предоставить следующие данные Web-сервисов Amazon:

публичный ключ доступа;
секретный ключ.

Виртуализация Red Hat#

Полномочия этого типа используются для доступа к расширению (plug-in) инвентаря oVirt4.py, которым управляют с помощью Виртуализации Red Hat.

Диспетчер ресурсов Microsoft Azure#

Полномочия этого типа используются для доступа к списку управляемых узлов в Диспетчере ресурсов Microsoft Azure.

Личный токен доступа к GitHub#

Полномочия этого типа используются для доступа к GitHub с помощью личного токена доступа. Данный тип полномочий позволяет устанавливать API-соединение с GitHub для использования в заданиях и публикации обновлений состояния.

Пошаговые инструкции по созданию токена см. в документации GitHub.

Машина#

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

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

sudo;
su;
pbrun;
pfexec;
dzdo;
pmrun;
runas;
enable;
doas;
ksu;
machinectl;
sesu.

Использование этой настройки эквивалентно выполнению команды ansible-playbook с параметром --become-method=<method>.

Платформа автоматизации Red Hat Ansbile#

Полномочия этого типа используются для доступа к Платформе автоматизации Red Hat Ansbile.

Поддерживается защита подключения с помощью SSL.

Реестр контейнеров#

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

Поддерживается защита подключения с помощью SSL.

Сеть#

Полномочия этого типа используются для управления сетевым оборудованием. К настоящему времени, согласно документации Ansible, он устарел и не рекомендован к использованию. Вместо него рекомендуется использовать тип «Машина».

Токен персонального доступа GitLab#

Полномочия этого типа используются для доступа к GitLab с помощью личного токена доступа. Данный тип полномочий позволяет устанавливать API-соединение с GitLab для использования в заданиях и публикации обновлений состояния с помощью webhook.

Пошаговые инструкции по созданию токена см. в документации GitLab.

Токен доступа для OpenShift или Kubernetes API#

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

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

адрес точки доступа OpenShift или Kubernetes API для аутентификации;
токен.

Поддерживается защита подключения с помощью SSL.

Управление источниками кода#

Полномочия этого типа используются для доступа к системам контроля версий на основе Git и Subversion.

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

Создание типа полномочий#

Astra Automation Controller поддерживает создание дополнительных типов полномочий, которые можно использовать в заданиях на основе шаблонов и заданиях обновления инвентаря.

Поддерживаются следующие способы передачи данных идентификации в среду исполнения:

переменные окружения;
дополнительные переменные Ansible;
шаблонизация на основе файлов (генерация файлов в форматах CONF и INI).

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

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

Настройка входных данных#

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

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

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

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

Поддерживаются следующие значения:
- string – строка;
- boolean – логическое.
default – значение по умолчанию.
format – дополнительная проверка корректности значения, указанного в поле.

Поддерживаются следующие значения:
- ssh_private_key – приватный ключ SSH;
- url – URI.
label – название поля при заполнении сведений о полномочии через графический интерфейс.
help_text – подсказка, которая выводится рядом с полем при заполнении сведений о полномочии через графический интерфейс.
secret – если равно true, вводимое значение является секретом.

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

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

Конфигурация инжектора#

Настройки инжектора определяют порядок передачи данных полномочия в среду исполнения.

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

---
file:
  template: '[credentials]\nusername={{ username }}\npassword={{ password }}'
env:
  API_URL: '{{ api_url }}'
  AUTH_DATA_FILE: '{{ tower.filename }}'
extra_vars:
  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 и соответствующих им значений.

Подробности о порядке разрешения значений переменных см. в документе Переменные.

Примеры#

Пусть для работы с некоторым сервисом необходимы следующие учетные данные:

имя пользователя;
токен;
уровень доступа (может принимать значения low, medium и high);
приватный ключ SSH для защиты соединения.

Пусть для получения данных используется форма со следующими полями:

Параметр	Идентификатор	Тип	Обязательное
Имя пользователя	`username`	`string`	Да
Токен	`token`	`string`	Да
Уровень доступа	`access_level`	`string`	Да
Ключ SSH	`ssh_key`	`string`	Нет

В этом случае настройки входных данных могут иметь следующий вид:

---
fields:
  - id: username
    type: string
    label: Username

  - id: token
    type: string
    label: Token
    help_text: A string of 32 charactes long.

  - id: access_level
    type: string
    label: Access level
    choices:
      - low
      - medium
      - high
    default: low

required:
  - username
  - token
  - access_level

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

Имя пользователя и токен – в переменных окружения API_USERNAME и API_TOKEN соответственно. При этом строка для передачи токена должна иметь следующий вид:
```
Bearer-Token: <token>
```
Уровень доступа – в дополнительной переменной Ansible api_access_level.
Приватный ключ SSH – в виде файла.

Имя файла формируется автоматически и передается через переменную окружения API_PRIVATE_SSH_KEY, а содержимое формируется на основе входных данных с идентификатором ssh_key.

В этом случае конфигурация инжектора выглядит следующим образом:

---
env:
  API_USERNAME: '{{ username }}'
  API_TOKEN: 'Bearer-Token:: {{ token }}'
  API_PRIVATE_SSH_KEY: '{{ tower.filename.private_ssh_key }}'
extra_vars:
  api_access_level: '{{ access_level }}'
file:
  template.private_ssh_key: '{{ ssh_key }}'

Примечание

Два двоеточия в строке с параметром API_TOKEN необходимы для соблюдения корректности синтаксиса YAML. При передаче данных строка будет преобразована в указанный выше формат с одним двоеточием.

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

../../../_images/credentials-custom-input-form.png

Полномочия

Содержание

Полномочия#

Поддерживаемые типы полномочий#

API-токен Ansible Galaxy/Automation Hub#

Centrify Vault Credential Provider Lookup#

CyberArk Central Credential Provider Lookup#

CyberArk Conjur Secrets Manager Lookup#

Google Compute Engine#

GPG Public Key#

HashiCorp Vault Secret Lookup#

HashiCorp Vault Signed SSH#

Insights#

Microsoft Azure Key Vault#

OpenStack#

Red Hat Satellite 6#

Thycotic DevOps Secrets Vault#

Thycotic Secret Server#

Vault#

VMware vCenter#

Web-сервисы Amazon#

Виртуализация Red Hat#

Диспетчер ресурсов Microsoft Azure#

Личный токен доступа к GitHub#

Машина#

Платформа автоматизации Red Hat Ansbile#

Реестр контейнеров#

Сеть#

Токен персонального доступа GitLab#

Токен доступа для OpenShift или Kubernetes API#

Управление источниками кода#

Создание типа полномочий#

Настройка входных данных#

Конфигурация инжектора#

Примеры#