Действия после обновления

Действия после обновления#

На этой стадии происходит восстановление данных, которые не могли быть автоматически перенесены и были сохранены на этапе Действия перед обновлением.

../../../_images/infra-prep-green.svg ../../../_images/copy-green.svg ../../../_images/pre-upgrade-green.svg ../../../_images/upgrade-green.svg ../../../_images/post-upgrade-blue.svg ../../../_images/verification-white.svg

Проверка миграции методов аутентификации#

После обновления до версии 2.0 все методы аутентификации из версии 1.2 автоматически мигрируют в шлюз как унаследованные (legacy) методы (доступны только в для чтения). Проверьте их наличие:

  1. Экспортируйте все методы аутентификации

    curl -sk -u admin:<password> https://gateway.com/api/gateway/v1/authenticators/ > /tmp/authenticators_after_upgrade.json

  2. Проверьте активность методов:

    jq '.results[] | {id, name, type, enabled}' /tmp/authenticators_after_upgrade.json

  3. Изучите список унаследованных методов:

    jq '.results[] | select(.type | contains("legacy")) | {name, type}' /tmp/authenticators_after_upgrade.json

    Унаследованные методы создаются автоматически с префиксом legacy_.

Настройка новых методов аутентификации описана в следующих разделах.

Связывание учетных записей#

В версии 2.0 шлюз является единой точкой аутентификации. Пользователи больше не подключаются напрямую к Automation Controller, Private Automation Hub или Event-Driven Automation. Для сохранения доступа к их прежним объектам (проектам, инвентарям, заданиям) требуется связать старые учетные записи с новыми. Для этого выполните следующие действия:

  1. Перейдите в веб-интерфейс шлюза.

  2. В окне аутентификации выберите один из предложенных вариантов:

    • I have an automation controller account – выберите этот вариант, если у вас есть учётные данные пользователя Automation Controller.

    • I have an automation hub account – выберите этот вариант, если у вас есть учётные данные пользователя Private Automation Hub.

  3. Введите учётные данные пользователя выбранного на предыдущем шаге компонента Astra Automation и нажмите кнопку Log in.

  4. После связывания учетных записей на экране отобразится информация с названием учетной записи текущего пользователя.

  5. Если у вас есть учётная запись второго компонента Astra Automation (учётная запись Private Automation Hub, если ранее был выбран Automation Controller, и наоборот), можно также связать ее в открытом окне Link your |AA| accounts.

  6. Нажмите кнопку Submit.

Для проверка статуса связывания:

  1. На панели навигации выберите Access Management ‣ Users.

  2. Выберите пользователя.

  3. Проверьте значение поля Last login.

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

Управление ролями#

После связывания учетных записей выполняется автоматическая миграция ролевых назначений (RBAC) на шлюз. Однако из-за изменений в модели RBAC может потребоваться ручная корректировка прав доступа.

Проверка наличия системного администратора#

В платформе Astra Automation должен быть системный администратор. Для проверки его наличия выполните следующие действия:

  1. Перейдите в веб-интерфейс шлюза.

  2. Выберите на панели навигации Access Management ‣ Users.

  3. Найдите учетную запись, у которой в значении поля столбца User type будет System administrator.

Если системный администратор отсутствует, создайте его с помощью команды, подключившись по SSH к узлу шлюза:

awx-manage create_superuser --username=admin

Проверка команд и назначение ролей в организациях#

Проверьте, что роли мигрировали и назначены на команды внутри организаций:

  1. Выберите на панели навигации Access Management ‣ Organizations ‣ <Organization> ‣ Users.

  2. Перейдите во вкладку Astra Automation и проверьте наличие всех пользователей.

    Если пользователя нет, добавьте их, используя кнопку Add users.

  3. Выберите на панели навигации Access Management ‣ Organizations ‣ <Organization> ‣ Teams и проверьте список команд организации.

  4. Выберите на панели навигации Access Management ‣ Teams ‣ <Team> ‣ Roles и проверьте какие роли назначены команде.

  5. Выберите на панели навигации Access Management ‣ Teams ‣ <Team> ‣ Users и проверьте состав команды.

Проверка прямых ролей пользователей#

Проверьте, что роли, назначенные на пользователей, мигрировали корректно. Для этого выберите на панели навигации Access Management ‣ Users ‣ <User> ‣ Roles и проверьте установленные роли.

Внимание

При миграции с Astra Automation версии 1.2 на версию 2.0 не все пользователи могут быть перенесены в организации для Astra Automation.

Для решения ситуации:

  1. Выберите на панели навигации Organizations ‣ <Organization> ‣ Users и перейдите во вкладку Astra Automation.

  2. Нажмите кнопку Add users и выберите пользователей из списка.

  3. Проверьте, что пользователи добавлены.

Восстановление команд и их ролей#

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

  • члены команд;

  • роли, назначенные на команды.

Восстановление через графический интерфейс (рекомендуется)#

Используйте графический интерфейс для восстановления пользователей и ролей:

  1. Выберите на панели навигации Access Management ‣ Teams -> <Team> ‣ Users.

  2. Нажмите кнопку Add users.

  3. Добавьте пользователей из /tmp/rbac_backup/team_*_users.json.

  4. Выберите конкретный ресурс в разделах Projects/Templates/Inventories.

  5. Перейдите во вкладку User Access, выберите команду и добавьте роли с помощью кнопки Add roles.

Пример восстановления через API#

Для восстановления пользователей и команд пользователей через API воспользуйтесь следующими вызовами HTTP:

# Получить ID команды в новой системе
TEAM_NAME="Operators"
TEAM_ID=$(curl -sk -u admin:<password> \
  "https://gateway.com/api/gateway/v1/teams/?name=$TEAM_NAME" | jq -r '.results[0].id')

# Получить список пользователей из бэкапа (замените 7 на ваш team_id из 1.2)
OLD_TEAM_ID=7
jq -r '.results[].username' /tmp/rbac_backup/team_${OLD_TEAM_ID}_users.json | \
while read username; do
  echo "Добавление $username в команду $TEAM_NAME"

  USER_ID=$(curl -sk -u admin:<password> \
    "https://gateway.com/api/gateway/v1/users/?username=$username" | jq -r '.results[0].id')

  curl -sk -u admin:<password> -X POST \
    -H "Content-Type: application/json" \
    "https://gateway.com/api/gateway/v1/teams/$TEAM_ID/users/" \
    -d "{\"id\": $USER_ID}"
done

Восстановление ролей команды#

Пример запроса для JSON, который содержит выгрузку из legacy API#
jq '.results[] | {
  role: .name,
  resource_type: .summary_fields.resource_type,
  resource_name: .summary_fields.resource_name,
  resource_id: .summary_fields.resource_id
}' /tmp/rbac_backup/team_${OLD_TEAM_ID}_roles.json
Пример запроса для JSON, который содержит выгрузку из нового API#
jq '.results[] | {
  role: .summary_fields.role_definition.name,
  object: .summary_fields.content_object.name
}' /tmp/rbac_backup/team_${OLD_TEAM_ID}_roles.json

Примечание

Формат JSON различается в унаследованном (legacy) и новом API:

  • Унаследованный формат (Astra Automation 1.2):

    • Роль в .name.

    • Объект в .summary_fields.resource_name.

  • Новый формат (Astra Automation 2.0):

    • Роль в .summary_fields.role_definition.name.

    • Объект в .summary_fields.content_object.name.

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

  1. Выберите на панели навигации Automation Execution ‣ Projects/Templates/Inventories

  2. Выбрать нужный ресурс и перейдите во вкладку Team Access.

  3. Нажмите кнопку Add.

  4. Выберите необходимую команду и добавьте ей роли.

Примечание

Если используется Private Automation Hub с мигрированными namespaces, роли назначаются в разделе Automation Content ‣ Namespaces ‣ Permissions.

Настройка внешней аутентификации#

При создании нового метода SAML или LDAP обязательно включите автоматическую миграцию. Для этого выполните следующие действия:

  1. Выберите на панели навигации Access Management ‣ Authentication Methods.

  2. Нажмите кнопку Create authentication.

  3. Перейдите во вкладку Authentication details и выберите все унаследованные методы в поле Auto migrate users from:

  • controller: legacy_password;

  • hub: legacy_password;

  • eda: legacy_password;

  • legacy_sso-saml-* (если эти методы были в Astra Automation версии 1.2).

Это предотвратит создание дублей пользователей при первом входе.

Настройка SAML#

Предварительные требования:

  • настроенный IdP;

  • ключи и сертификат SP (saml.crt, saml.key);

  • данные от IdP: Entity ID, SSO URL, публичный сертификат.

Для настройки SAML на сервере KeyCloak выполните следующие действия:

  1. Перейдите в Keycloak.

  2. Выберите необходимый Realm.

  3. Создайте клиента SAML (Create client ‣ SAML), указав для поля Client ID в качестве значения URL-адрес шлюза, например: https://gateway.com/.

  4. Настройте клиента SAML в соответствии со следующими данными:

    • General Settings

    • Keys

      • Signing keys config: OFF

      • Encryption keys config: ON

      • Encrypt assertions: ON

      После включения нажмите кнопку Generate и сохраните private.key.

    • Advanced Settings

  5. Получите сертификат IdP, для этого:

    1. Выберите на панели навигации Realm Settings ‣ Endpoints ‣ SAML 2.0 Identity Provider Metadata.

    2. Скопируйте <ds:X509Certificate>.

Настройте SAML на шлюзе Astra Automation, для этого:

  1. Выберите на панели навигации шлюза Access Management ‣ Authentication Methods ‣ Create authentication.

  2. Заполните форму следующими данными:

    Маппинг атрибутов:

    • User Email: email

    • Username: username

    • User Last Name: last_name

    • User First Name: first_name

    • User Permanent ID: email

  3. Сохраните настройки SAML.

  4. Скопируйте ACS URL.

  5. Добавьте ACS URL в Valid redirect URIs в Keycloak.

  6. Включить метод (Enabled = ON).

Проверьте корректность настройки SAML, для этого:

  1. Выйдите из Keycloak.

  2. Откройте браузер в режиме инкогнито.

  3. Перейдите в веб-интерфейс шлюза.

  4. Нажмите кнопку SSO.

  5. Авторизуйтесь в Keycloak.

  6. Вернитесь в шлюз.

Настройка OIDC#

Для настройки OIDC выполните следующие действия на сервере KeyCloak:

  1. Перейдите в Keycloak.

  2. Выберите необходимый Realm.

  3. Создайте клиента OIDC (Create client ‣ OIDC), указав:

    • для поля Client type значение OpenID Connect.

    • для поля Client ID значение aa-gateway-oidc.

  4. Настройте клиента OIDC в соответствии со следующими данными:

  5. Получите Client Secret, выбрав на панели навигации Clients ‣ Credentials ‣ Client Secret.

  6. Настройте Mappers в соответствии со следующими данными:

    Для scope [aa-gateway-oidc]-dedicated:

    Claim

    Property

    Token Claim Name

    username

    username

    preferred_username

    email

    email

    email

    first name

    firstName

    given_name

    last name

    lastName

    family_name

Настройте OIDC на шлюзе Astra Automation, для этого:

  1. Выберите на панели навигации шлюза Access Management ‣ Authentication Methods ‣ Create authentication.

  2. Заполните форму следующими данными:

    • Authentication type: OIDC

    • Name: Keycloak OIDC

    • Auto migrate users from: выбрать все legacy_password

    • OIDC Provider URL: http://keycloak.com:8080/realms/master

    • Client ID: aa-gateway-oidc

    • Client Secret: полученный секрет

    • JWT Algorithms: RS256

    • Username Key: preferred_username

    • ID Key: sub

    • Create objects: ON

    • Enabled: ON

Проверьте корректность настройки OIDC, для этого:

  1. Выйдите из Keycloak.

  2. Откройте браузер в режиме инкогнито.

  3. Перейдите в веб-интерфейс шлюза.

  4. Нажмите кнопку OIDC.

  5. Пройдите авторизацию.

  6. Вернитесь в шлюз.

Возможные проблемы OIDC#

Ошибка

Возможная причина

Решение

Ошибка 500 при нажатии кнопки «мыши»

Используется /.well-known

Убрать этот суффикс

/auth_failed

Нет RS256

Добавить

/auth_failed

Нет claims

Настроить mappers

/auth_failed

Пробелы в значении поля Web origins

Удалить пробелы

Группы пользователей OIDC#

Для настроек групп пользователей OIDC выполните следующие действия:

  1. Перейдите в Keycloak.

  2. На панели навигации выберите Groups.

  3. Нажмите кнопку Create group и создайте группу с названием aa-admins.

  4. На панели навигации выберите Clients ‣ [aa-gateway-oidc] ‣ Mappers.

  5. Нажмите кнопку Add mapper и добавьте маппер типа Group Membership со следующими параметрами:

    • Token Claim Name: groups

    • Full path: OFF

    • Add to all tokens: ON

  6. Перейдите в веб-интерфейс шлюза Astra Automation.

  7. В методе OIDC установите для параметра Groups Claim значение groups.

  8. На панели навигации выберите Teams.

  9. Нажмите кнопку Create team и создайте команду с названием aa-admins.

  10. Назначьте роли команде.

Группы пользователей SAML#

Для настроек групп пользователей SAML выполните следующие действия:

  1. Перейдите в Keycloak.

  2. На панели навигации выберите Client Scopes.

  3. Нажмите кнопку Create и создайте группу group_list.

  4. Нажмите кнопку Add mapper и добавьте маппер типа Group list со следующими параметрами:

    • Name: memberOf

    • Group attribute name: memberOf

    • Full group path: OFF

  5. Перейдите в веб-интерфейс шлюза Astra Automation.

  6. Добавьте scope в клиент SAML шлюза.

  7. На панели навигации выберите Teams.

  8. Нажмите кнопку Create team и создайте команду с названием aa-core-team.

  9. Назначьте роли команде.

Восстановление Event-Driven Automation#

В Astra Automation версии 2.0 объекты Event-Driven Automation не переносятся автоматически. После обновления необходимо вручную восстановить все конфигурации.

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

Для продолжения работы с Event-Driven Automation заново создайте полномочия для Automation Controller и Git:

  1. Получите токен аутентификации Controller с помощью следующего запроса:

    curl -sk -X POST https://controller.example.com/api/v2/tokens/ \
  -u testadmin:<password> \
  -H "Content-Type: application/json" \
  -d '{"description":"EDA Integration","scope":"write"}' | jq -r '.token'

  2. На панели навигации выберите Infrastructure ‣ Credentials.

  3. Нажмите кнопку Create credential и создайте полномочие со следующими параметрами:

    • Name: Controller API Token

    • Credential type: Astra Automation Platform

    • Host: адрес контроллера

    • OAuth Token: полученный токен

    • Verify SSL

  4. Нажмите кнопку Create credential и создайте полномочие типа Source Control со следующими параметрами:

    • Name: GitFlic SSH Key

    • Username

    • SSH Private Key

Создание среды принятия решений#

Для продолжения работы с Event-Driven Automation заново создайте среду принятия решений:

  1. На панели навигации выберите Automation Decisions ‣ Decision Environments.

  2. Нажмите кнопку Create и создайте среду принятия решений.

Создание проектов#

Для продолжения работы с Event-Driven Automation заново создайте проекты:

  1. На панели навигации выберите Automation Decisions ‣ Projects.

  2. Нажмите кнопку Create и создайте проект.

Создание потоков событий#

Для продолжения работы с Event-Driven Automation заново создайте потоки событий:

  1. На панели навигации выберите Automation Decisions ‣ Event Streams.

  2. Нажмите кнопку Create и создайте поток событий.

  3. Скопируйте Event Stream URL.

  4. Настройте внешний источник.

Создание активации сводов правил#

Для продолжения работы с Event-Driven Automation заново создайте активации сводов правил:

  1. На панели навигации выберите Automation Decisions ‣ Rulebook Activations.

  2. Нажмите кнопку Create и создайте активации сводов правил.

Проверка и замена URL в шаблонах и интеграциях#

После обновления до версии 2.0 изменяется архитектура сетевого доступа: все сервисы теперь доступны через шлюз, а прямой доступ к балансировщикам (ac.example.com, hub.example.com) может быть ограничен.

Необходимо проверить и обновить все URL (hardcoded FQDN) в шаблонах, webhook, интеграциях и внешних системах.

Матрица замены адресов#

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

  • Extra vars templates;

  • динамические инвентари;

  • webhooks GitHub/GitLab;

  • внешние системы: Zabbix, Prometheus, Jenkins, GitLab CI, ServiceNow;

  • скрипты (curl, requests, Ansible uri).

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

Компонент

Пример старого адреса

Новый адрес

Назначение

API Automation Controller

https://controller.aa.example.com/api/v2/

https://aa.example.com/api/controller/v2/

Доступ через API шлюза

UI Automation Controller

https://controller.aa.example.com/

https://aa.example.com/ (адрес шлюза)

Все компоненты доступны в едином графическом интерфейсе

API Private Automation Hub

https://hub.aa.example.com/api/galaxy/

https://aa.example.com/api/galaxy/

Доступ через API шлюза

UI Private Automation Hub

https://hub.aa.example.com/

https://aa.example.com/ (адрес шлюза)

Все компоненты доступны в едином графическом интерфейсе

API Event-Driven Automation

https://eda.aa.example.com/api/eda/v1/

https://aa.example.com/api/eda/v1/

Доступ через API шлюза

UI Event-Driven Automation

https://eda.aa.example.com/

https://aa.example.com/ (адрес шлюза)

Все компоненты доступны в едином графическом интерфейсе

API шлюза

(отсутствует)

https://aa.example.com/api/gateway/v1/

API шлюза

UI шлюза

(отсутствует)

https://aa.example.com/

Единая точка входа для всех сервисов

Примечание

Остальные точки доступа к API Automation Controller и API Private Automation Hub временно сохраняются для обратной совместимости с интеграциями и сценариями версии 1.2. Они будут отключены в будущих релизах.

Рекомендуется планировать постепенный перевод всех интеграций на API шлюза.