LoginSignup
5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ma333inKaoエンジニアコミュニティβ

Microsoft Entra IDとGoogle Cloud, AWS, GitHubのユーザー連携やってみる③

Posted at

はじめに

本記事では、Microsoft Entra ID（旧Azure AD）がメインのID基盤である場合に、AWSとのアカウント連携を構築する手順の概要を解説します。

AWS Organizationsは利用しない方式になります。

※会社公式ではなく、2025年9月24日時点でのma333の見解となります。

本記事のゴール

ゲストユーザーのアドレスがuser@guest.comで、MyAppsから起動、Microsoft Entra ID側で認証を実施し、AWSの踏み台アカウントを通じて各アカウントにアクセスできることを目指します。

ログインイメージ

AWSの中でユーザーを発行し管理することもできますが、Microsoft Entra IDをメイン利用されている会社であれば、マルチクラウドの運用負荷が低減できるようになります。

また、各アカウントの権限をロールで分かりやすく管理することが可能です。

Microsoft Entra IDとAWSの連携構成

本構成については、以下の2記事の内容を掛け合わせています。

つまり、Microsoft Entra IDとIAMユーザー管理用の踏み台AWSアカウントを1対1連携方式で接続し、そこから分離する環境分のAWSアカウントへアクセスする構成になります。

構成イメージ

前提

  • Microsoft Entra IDを利用していること
    • 条件付きアクセス - 使用条件の確認(利用規約の設定)についてはP1以上のライセンスが必要です
  • AWSアカウント(少なくとも2つ)を持っていること

ざっくり手順

AWSアカウントとMicrosoft Entra IDの連携について、以下の順で追っていきます。

  1. AWSの各アカウントの設定
  2. Microsoft Entra IDでSSOを構成する
  3. AWSの踏み台アカウントの設定
  4. Microsoft Entra IDでユーザープロビジョニングを構成する

1. AWSの各アカウントの設定

分離する環境分のAWSアカウントを用意し、ロールを作成していきます。

各AWSアカウント構成イメージ

  1. ロールを作成
  2. 信頼されたエンティティを選択
    • 信頼されたエンティティのタイプ: AWSアカウント
    • AWSアカウント
      • ☑別のAWSアカウント
      • アカウントID: AWS踏み台アカウントID
  3. AWSアカウントID: IAMユーザー管理用AWSアカウントID
  4. 許可を追加
    • 許可ポリシー：ex. 管理者ならAdministratorAccess等
  5. ロール名：ex. 管理者ならadmin等
  6. 作成されたARNを控えておく
    • ex. arn:aws:iam::123456789012:role/admin

ここまでで、各アカウントのIAMロールが構築できました。

2. Microsoft Entra IDでSSOを構成する

Microsoft Entra ID構成イメージ

  1. Azureポータルにて、Microsoft Entra ID > エンタープライズアプリケーションを選択
  2. 新しいアプリケーション > AWS Single-Account Accessを検索し、任意の名前を入力して、「作成」を選択
    • ex. AWS-Single-Account-Access
  3. シングル サインオンを選択し、以下の設定を行います
  4. SAMLを選択し、「はい」で設定を保存

ゲストユーザーを活用する場合は、追加で以下の設定が必要です。

  • シングル サインオン > 属性とクレームの「編集」を選択
  • 一意のユーザー識別子 (名前 ID)を選択し、「変換」を選択
    • 変換の管理にて、以下の設定
      • 変換: Contains()
      • パラメータ1(入力): 属性
      • 属性名: user.userprincipalname
      • ソースを複数値として扱います: □ (チェック入れない)
      • 値: #EXT#
      • パラメータ2(出力): 属性
      • 属性名: user.mail
      • 一致しない場合は出力を指定する：☑（チェック入れる）
      • パラメータ3(一致しない場合は出力)：属性
      • 属性名：user.userprincipalname
    • 追加を選択し、保存
  • 同様の処理をRoleSessionNameにも設定

Microsoft Entra ID_nameidentifier

  1. 最後にシングルサインオンのSAML署名証明書からフェデレーションメタデータXMLをダウンロード

詳しい手順：非Organizations環境のAWSアカウントにAzure ADのユーザーからSSOしてみた
ゲスト用の設定：Azure Guest accounts can't sign in using AWS SSO with Azure SAML

3. AWSの踏み台アカウントの設定

次に踏み台アカウントから各アカウントへアクセスできるように設定を進めていきます。

踏み台AWSアカウント構成イメージ

Microsoft Entra IDと連携するためのIDプロバイダの作成

  1. AWSマネジメントコンソールにて、IAM > IDプロバイダー > プロバイダーの追加を選択
  2. プロバイダーの種類: SAMLを選択
  3. プロバイダー名: 任意の名前を入力
    • ex. MicrosoftEntraID
  4. Microsoft Entra IDでダウンロードしていたフェデレーションメタデータXMLをアップロード
  5. プロバイダーを追加を選択し、IDプロバイダーを作成

各アカウントへAssumeRoleするためのポリシーの作成

admin, developer等の各アカウントのロールへAssumeRoleできるようにするポリシーを作成します。

adminの場合

  1. AWSマネジメントコンソールにて、IAM > ポリシー > ポリシーの作成を選択
  2. JSONタブを選択し、以下のように設定
    • Resourceに各アカウントのロールARNを指定すること
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
              "sts:AssumeRole"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:iam::123456789012:role/admin",
                "arn:aws:iam::234567890123:role/admin",
                "arn:aws:iam::345678901234:role/admin"
            ]
        }
    ]
}
  1. ポリシー名を入力し、ポリシーを作成
    • ex. AssumeAdminRoleToAccounts

developerも同様に作成します

ロールの作成

作成したポリシーと1:1で紐づくロールを作成します。この作業で、踏み台アカウントにログインしたユーザーが、各アカウントのロールへAssumeRoleできるようになります。

adminの場合

  1. AWSマネジメントコンソールにて、IAM > ロール > ロールの作成を選択
  2. 信頼されたエンティティ
    • 信頼されたエンティティのタイプ: SAML2.0 フェデレーションを選択
    • SAML2.0ベースのプロバイダー: 先ほど作成したIDプロバイダーを選択
      • ex. MicrosoftEntraID
    • 各種選択肢を選択し、次へ
  3. 許可ポリシーで、先ほど作成したポリシーを選択
    • ex. AssumeAdminRoleToAccounts
  4. ロール名、タグ等を入力し、作成
    • ex. MicrosoftEntraID-Admin

developerも同様に作成します

AWS側でのプロビジョニング用IAMユーザー作成

Microsoft Entra IDからAWSへユーザーをプロビジョニングするためのIAMユーザーを作成します。

ポリシーを作成

  1. AWSマネジメントコンソールにて、IAM > ポリシー > ポリシーの作成を選択
  2. JSONタブを選択し、以下のように設定
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:ListRoles"
            ],
            "Resource": "*"
        }
    ]
}
  1. ポリシー名を入力し、ポリシーを作成
    • ex. ListRolesForProvisioning

ユーザーを作成

  1. AWSマネジメントコンソールにて、IAM > ユーザー > ユーザーを追加を選択
  2. ユーザー名を入力
    • ex. MicrosoftEntraIdProvisioningUser
    • アクセスの種類で、プログラムによるアクセスを選択
    • 次のステップ: アクセス権限を選択
  3. 既存のポリシーを直接アタッチを選択し、先ほど作成したポリシーを選択
    • ex. ListRolesForProvisioning
  4. 次のステップ: タグを選択し、必要に応じてタグを追加
  5. 次のステップ: 確認を選択し、内容を確認
  6. ユーザーの作成を選択
  7. 作成されたユーザーのアクセスキーIDとシークレットアクセスキーを控えておく

4. Microsoft Entra IDでユーザープロビジョニングを構成する

Microsoft Entra IDからAWSへユーザーをプロビジョニングする設定を行います。

Microsoft Entra IDプロビジョニング構成イメージ

プロビジョニング設定

  1. Azureポータルにて、Microsoft Entra ID > エンタープライズアプリケーションを選択
  2. 先ほど作成したAWS-Single-Account-Accessを選択
  3. プロビジョニングを選択し、作業の開始を選択
  4. プロビジョニングモードで、自動を選択
  5. 管理者資格情報で、以下の情報を入力
    • clientSecret: 先ほど作成したIAMユーザーのアクセスキーID
    • シークレットトークン：先ほど作成したIAMユーザーのシークレットアクセスキー
    • テスト接続を選択し、成功することを確認
  6. 保存を選択

プロビジョニング開始

  1. プロビジョニングで、プロビジョニングの開始を選択
  2. プロビジョニングの編集で、状態をオンに変更し、保存

ユーザーとグループの設定

  1. ユーザーとグループを選択し、ユーザーまたはグループの追加を選択
  2. ユーザーとグループ > 選択されていませんを選択
  3. ユーザーとグループを選択し、選択を選択
    • ex. aws-admin
  4. ロールを選択してください > 選択されていませんを選択
  5. どれか1つロールを選択し、選択を選択
    • ex. MicrosoftEntraID-Admin
  6. 割り当てを選択

ユーザーで管理してもよいですが、マルチクラウドでAzure, AWS, Google Cloud等に同一のadmin, developer等の権限を利用する場合は、グループで管理した方が運用負荷が低減できるのでおススメです

動作確認

Microsoft Entra IDのエンタープライズアプリケーションで、AWS-Single-Account-Accessを選択し、プロパティを開きます。

そちらにあるユーザーのアクセスURLにて起動し、アクセスすることが可能です。

なお、このプロパティにてユーザーに表示しますかをはいにしておくと、MyAppsのアプリ一覧に表示され、そこから起動することも可能です。

(再掲)
ログインイメージ

まとめ

Microsoft Entra IDとAWSのアカウント連携を構築する手順の概要を解説しました。

Microsoft Entra IDにて

  • プロジェクトA管理者グループ
  • プロジェクトA開発者グループ
  • プロジェクトB管理者グループ
  • プロジェクトB開発者グループ

等のグループを作成すれば、同一のグループにAzure, AWSのプロジェクト・ロール権限を付与しておくことで、ユーザーをそれぞれのクラウドで管理する必要がなくなります。

次回はGitHubとMicrosoft Entra IDの連携、ライセンス周りについて書いてみたいと思います！

関連記事

5
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?