Red Hat SummitChapter 5. Identity access management data movement
During the upgrade process to Ansible Automation Platform 2.6, Identity Access Management (IAM) data, including users, teams, organizations, their memberships, and associated roles, is migrated from automation controller and automation hub to platform gateway. This migration establishes automation controller as the primary source of IAM data for platform gateway, ensuring continuity of user memberships and appropriate platform-level role assignments.
We recommend upgrading directly from the latest version of 2.4 to Ansible Automation Platform 2.6, without using 2.5 as an intermediate step, as the upgrade process to 2.6 is less complex.
5.1. Upgrading from Ansible Automation Platform 2.4 to 2.6
It is possible for customers to upgrade directly from the latest 2.4 version to 2.6. On startup, 2.6 platform services rename their service-specific roles to platform-wide roles, as shown in the following table.
| 2.4 role | 2.6 equivalent |
|---|---|
| Automation controller auditor | Platform auditor |
| Automation controller superuser/administrator (flag) | Platform superuser/administrator (flag) |
| Automation controller organization admin | Organization administrator |
| Automation controller organization member | Organization member |
| Automation controller team admin | Team administrator |
| Automation hub administrator | Team member (user) |
| Automation controller team member (user) | Team member (user) |
| Automation hub team member (user) | Team member (user) |
Additionally, note the following behavior when upgrading to 2.6:
- After upgrading, automation controller entity relationships, such as user associations with organizations, teams, or role sets, remain consistent in platform gateway. This applies to both existing entities moved during the upgrade and any new entities (users, teams, organizations) created in automation controller and subsequently moved in a 2.6 environment.
- Automation controller user types (normal, superuser and auditor) are mapped to platform gateway user types during the upgrade process.
- Where team names match between automation hub and platform gateway, for example, "Team A" exists in both, user memberships from automation hub are transferred to the corresponding team in platform gateway. This reduces the need to manually re-create memberships.
- If users exist only in automation hub, they are not moved to [Gateway]. You must manually re-create these users after upgrading. However, if a user has the same username in both automation controller and automation hub, the automation controller account is part of the regular data movement. Users who are not migrated need to have their passwords reset, but should keep the same permissions.
- Data movement also moves private automation hub but excludes Event-Driven Ansible data.
- Event-Driven Ansible users are not moved to platform gateway and must be recreated manually after upgrading.
Automation hub users must be recreated if they cannot be moved as part of the upgrade. A user might not be migrated for the following reasons:
- The user’s account exists only in automation hub and not in automation controller.
- Duplicate usernames exist in both automation hub and automation controller, but they belong to different people.
- A discrepancy in the username, email, or other identifying attributes exists between the two services, which prevents the system from correctly merging the accounts.
- Automation hub admins are converted to normal users if they are able to be merged with automation controller users.
- The automation controller UI is updated to reflect the automation controller data moved as platform-level entities along with their roles.
- The automation controller setting Organization Admins Can Manage Users and Teams applies to organization admins in 2.6.
5.1.1. Nested team behavior changes
Ansible Automation Platform 2.5 and later versions no longer support nested team structures. This affects the UI, API, and collections.
In version 2.4, users could inherit permissions from multiple teams simultaneously through nested team structures created using REST APIs and collections. For example, a user on Team A could inherit permissions for Team B if Team B was nested under Team A (User
During an upgrade from Ansible Automation Platform 2.4 to 2.6, nested teams are converted to a direct user-to-teams mapping. This means that instead of inheriting permissions through a nested structure, users are directly assigned to each team they have permissions for. For instance, if a user previously had permissions through "User
Impact and planning
- Users can still belong to one or more teams and simultaneously inherit permissions from those teams.
- Organizations that use integrations or automations with nested teams in their 2.4 deployment must plan to change this structure to a direct user-to-teams mapping.
Before upgrading from Ansible Automation Platform 2.4, change any integrations or automations that implement nested teams to a direct user-to-teams mapping to avoid unexpected behavior in 2.5 and later.
5.2. Upgrades from Ansible Automation Platform 2.5 to 2.6
When upgrading from Ansible Automation Platform 2.5 to 2.6, existing authenticators and their mappings in platform gateway continue to function as they are, with no changes being imported. This is because the core authentication service in 2.5 is already platform gateway, so a migration of this data is not needed.
5.2.1. Automation controller
Customers upgrading from 2.5 to 2.6 must also begin moving away from using nested teams in automation controller APIs, as future releases will disable direct access to service APIs. After the upgrade, user data is synchronized between automation controller and the platform-wide authentication gateway.
Automation controller users, teams, roles, and organizations should become platform entities upon upgrade without the need to run additional "merge" processes. Customers that first upgraded from 2.4 to 2.5 will have teams that existed in 2.4 merged into platform gateway when they upgrade from 2.5 to 2.6.
Roles should apply the permission model for non-admin access to execution, content, and event services.
5.2.2. Automation hub
The following apply:
- A private automation hub admin (Automation Content Administrator) in 2.5 will be removed in the upgraded version and for this user the permissions must be reassigned manually as part of the data movement process.
If teams with the same name exist in both automation hub and within the platform-wide authentication gateway, users from automation hub will be automatically added to corresponding teams within the platform-wide authentication gateway, and new teams will be created if they do not exist. This approach aims to retain team memberships, but requires careful review of permissions post-upgrade.
- If you rely on automation hub Single Sign-On (SSO) to access the automation hub user interface (UI), automation hub SSO logins will no longer function after the upgrade. However, API tokens will remain active. Therefore, automated processes or systems that use API tokens for authentication will continue to operate without interruption. If your workflows predominantly rely on API access, the impact might be minimal. However, if users primarily access the UI through SSO, they will need to take action post-upgrade.
- To restore UI access for users who previously relied on automation hub SSO, you need to reconfigure SSO within Ansible Automation Platform to be able to login. For further information, see Configuring Ansible Automation Platform Central Authentication Generic OIDC Settings and Red Hat SSO/KEYCLOAK for Red Hat SSO and Ansible Automation Platform.
- Automation controller admins will become platform admins and can administer automation hub.
- If you upgraded from 2.4 to 2.6 with both automation controller and private automation hub, then a dialog appears in the product post upgrade that informs you that there are steps to take in order to reconfigure private automation hub. This dialog can either display information in-product, or link to a product doc or Knowledge Base article. In either case, you will be guided to take action from within the product and not be expected to find that information unprompted.
- If you upgraded from 2.4 to 2.6 from an automation controller-only environment, then the addition of private automation hub and Event-Driven Ansible services involves adding the necessary roles to a normal user account to grant access to those services.
5.2.3. Event-Driven Ansible
The following apply:
- An Event-Driven Ansible administrator (Automation Decisions Administrator) in 2.5 will be removed in the upgraded version and for this user the permissions must be reassigned manually as part of the movement process.
- For Event-Driven Ansible, you must reset your password to log in to Ansible Automation Platform. You can still use your Event-Driven Ansible username but will require new passwords.
- If an Event-Driven Ansible user with SSO exists, then they will not have to reset password and should have their permissions moved over as part of the SSO migration.
5.3. Post upgrade
It is imperative that administrators verify the assigned permissions for all teams in the platform-wide authentication gateway immediately after the upgrade:
- Ensure the transferred team members have the correct access rights in the Ansible Automation Platform environment based on the filesystem.
- Make sure all members that have been merged are, in fact, the same member. Incorrect permissions could lead to access issues or security vulnerabilities.
- When upgrade to Ansible Automation Platform 2.6 is complete, user accounts that exist in both the automation hub and automation controller systems will be unified, and platform gateway IAM will be the source of truth for users after the data movement.
- Automation hub and Event-Driven Ansible users must either be recreated or the users that moved from automation controller given permission to use those services.
After your upgrade to automation controller 2.6 is complete, verify that you can log in to the upgraded platform with your existing automation controller credentials (username and password).
To do this, you have must have a automation controller account on Ansible Automation Platform 2.4 or 2.5 with administrative privileges.
The following table provides next steps for each type of user after they have upgraded.
| If you are this type of user before upgrading: | Then take these actions after the upgrade: |
|---|---|
| An automation controller administrator (no automation hub account) | Log in with your automation controller username and password; you are now a platform gateway administrator. |
| An automation controller normal user (no automation hub account) | Log in with your automation controller username and password; you are now a platform gateway normal user. |
| A automation hub user (no automation controller account) | Request a password reset from your administrator. When you log in with your new password you will be a platform gateway normal user. You will retain your hub-related permissions. |
| An automation controller and automation hub user (with the same username in both services) | Log in with your automation controller username and password; your previous two accounts will be merged and you are now a platform gateway normal user. |
| An automation hub user with SSO (no automation controller account) | Log in with your SSO credentials; you are now a platform gateway normal user. |
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}