第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 プラットフォームサービスは起動時に、次の表のとおり、サービス固有のロールの名前をプラットフォーム全体のロールの名前に変更します。

Expand
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 の権限を継承できます (ユーザー チーム A チーム B)。2.4 のユーザーインターフェイスではこの機能は公開されておらず、API とコレクションを使用した場合にのみ可能でした。

Ansible Automation Platform 2.4 から 2.6 へのアップグレード中に、ネストされたチームはユーザーとチームの直接のマッピングに変換されます。つまり、ネスト構造を通じて権限を継承するのではなく、ユーザーは権限を持つ各チームに直接割り当てられます。たとえば、ユーザーが以前に "ユーザー チーム A チーム B" の権限を持っていた場合、アップグレード後は "ユーザー チーム A とユーザー チーム B" になります。

影響と計画

  • ユーザーは引き続き 1 つ以上のチームに所属し、それらのチームから同時に権限を継承することができます。
  • 2.4 デプロイメントでネストされたチームに統合または自動化を使用する組織は、この構造をユーザーからチームへの直接マッピングに変更することを計画する必要があります。
重要

Ansible Automation Platform 2.4 からアップグレードする前に、ネストされたチームを実装する統合または自動化を、ユーザーとチームの直接マッピングに変更して、2.5 以降での予期しない動作を回避してください。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat