第5章 アイデンティティーアクセス管理データの移動
Ansible Automation Platform 2.6 へのアップグレードプロセス中に、ユーザー、チーム、組織、それらのメンバーシップ、および関連するロールを含む Identity Access Management (IAM) データが、Automation Controller と Automation Hub からプラットフォームゲートウェイに移行されます。この移行により、Automation Controller がプラットフォームゲートウェイの IAM データのプライマリーソースとして確立され、ユーザーメンバーシップの継続性と適切なプラットフォームレベルのロール割り当てが確保されます。
Ansible Automation Platform 2.6 へのアップグレードプロセスはそれほど複雑ではないため、2.5 を中間ステップとして使用せずに、最新の 2.4 バージョンから 2.6 に直接アップグレードすることが推奨されます。
5.1. Ansible Automation Platform 2.4 から 2.6 へのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
お客様は、最新の 2.4 バージョンから 2.6 に直接アップグレードできます。2.6 プラットフォームサービスは起動時に、次の表のとおり、サービス固有のロールの名前をプラットフォーム全体のロールの名前に変更します。
| 2.4 ロール | 2.6 で相当するロール |
|---|---|
| Automation Controller 監査人 | プラットフォーム監査人 |
| Automation Controller スーパーユーザー/管理者 (フラグ) | プラットフォームスーパーユーザー/管理者 (フラグ) |
| Automation Controller 組織管理者 | 組織管理者 |
| Automation Controller 組織メンバー | 組織メンバー |
| Automation Controller チーム管理者 | チーム管理者 |
| Automation Hub 管理者 | チームメンバー (ユーザー) |
| Automation Controller チームメンバー (ユーザー) | チームメンバー (ユーザー) |
| Automation Hub チームメンバー (ユーザー) | チームメンバー (ユーザー) |
さらに、2.6 にアップグレードする場合は、次の動作に注意してください。
- 組織、チーム、ロールセットとユーザーの関連付けなど、Automation Controller エンティティーの関係の整合性は、アップグレード後もプラットフォームゲートウェイで維持されます。これは、アップグレード中に移動された既存のエンティティーと、Automation Controller で作成され、その後 2.6 環境に移動された新しいエンティティー (ユーザー、チーム、組織) の両方に適用されます。
- Automation Controller のユーザータイプ (通常、スーパーユーザー、監査ユーザー) は、アップグレードプロセス中にプラットフォームゲートウェイのユーザータイプにマッピングされます。
- Automation Hub とプラットフォームゲートウェイ間でチーム名が一致する場合 (たとえば、両方に "Team A" が存在する場合)、Automation Hub のユーザーメンバーシップは、プラットフォームゲートウェイの対応するチームに転送されます。これにより、メンバーシップを手動で再作成する必要性が軽減されます。
- ユーザーが Automation Hub にのみ存在する場合、[ゲートウェイ] には移動されません。そのようなユーザーは、アップグレード後に手動で再作成する必要があります。ただし、ユーザーが Automation Controller と Automation Hub の両方で同じユーザー名を持っている場合、Automation Controller アカウントは通常のデータ移動に含まれます。移行されないユーザーはパスワードをリセットする必要がありますが、権限は変更せずそのままにします。
- データ移動では Private Automation Hub も移動しますが、Event-Driven Ansible データは除外されます。
- Event-Driven Ansible ユーザーはプラットフォームゲートウェイに移動されないため、アップグレード後に手動で再作成する必要があります。
アップグレードの一環として移動できない Automation hub ユーザーは再作成する必要があります。次の理由により、ユーザーが移行されない可能性があります。
- ユーザーのアカウントが Automation Hub にのみ存在し、Automation Controller には存在しない。
- Automation Hub と Automation Controller の両方に重複したユーザー名が存在するが、それぞれ異なるユーザーに属している。
- 2 つのサービス間でユーザー名、メール、またはその他の識別属性が一致しないため、システムがアカウントを正しくマージできない。
- Automation Hub 管理者は、Automation Controller ユーザーと統合できる場合は、通常のユーザーに変換されます。
- Automation Controller UI が更新され、プラットフォームレベルのエンティティーとして移動された Automation Controller データとそのロールが反映されます。
- Automation Controller の Organization Admins Can Manage Users and Teams の設定は、2.6 の組織管理者に適用されます。
5.1.1. ネストされたチームの動作の変更 リンクのコピーリンクがクリップボードにコピーされました!
Ansible Automation Platform 2.5 以降のバージョンでは、チームのネスト構造がサポート対象外になりました。これは、UI、API、およびコレクションに影響します。
バージョン 2.4 では、ユーザーは、REST API とコレクションを使用して作成されたチームのネスト構造を通じて、複数のチームから同時に権限を継承できました。たとえば、チーム B がチーム A の下にネストされている場合、チーム A のユーザーはチーム B の権限を継承できます (ユーザー
Ansible Automation Platform 2.4 から 2.6 へのアップグレード中に、ネストされたチームはユーザーとチームの直接のマッピングに変換されます。つまり、ネスト構造を通じて権限を継承するのではなく、ユーザーは権限を持つ各チームに直接割り当てられます。たとえば、ユーザーが以前に "ユーザー
影響と計画
- ユーザーは引き続き 1 つ以上のチームに所属し、それらのチームから同時に権限を継承することができます。
- 2.4 デプロイメントでネストされたチームに統合または自動化を使用する組織は、この構造をユーザーからチームへの直接マッピングに変更することを計画する必要があります。
Ansible Automation Platform 2.4 からアップグレードする前に、ネストされたチームを実装する統合または自動化を、ユーザーとチームの直接マッピングに変更して、2.5 以降での予期しない動作を回避してください。