Jump アカウント構成で外部 ID プロバイダとして Entra ID を利用する

yhana

2024.02.12

Jump アカウント構成において、外部の ID プロバイダとして Microsoft Entra ID を利用する構成を試してみました。

構成イメージ図は下記の通りです。Jump アカウントに IAM ユーザーを作成するのではなく、IAM ID プロバイダを作成して Entra ID と SAML で連携します。ID プロバイダには他のアカウントにスイッチロールできる権限の IAM ロールを関連付けます。スイッチロール先アカウントの IAM ロールでは Jump アカウントの IAM ロールを信頼します。

Jump アカウントと Entra ID の連携設定

Entra ID (旧 Azure AD) と AWS アカウントを連携する手順は次の Microsoft ドキュメントに記載されています。

チュートリアル: Microsoft Entra SSO と AWS Single-Account Access の統合 - Microsoft Entra ID | Microsoft Learn

手順は下記ブログでも紹介されているため、今回は下記ブログの手順で Jump アカウントと Entra ID の連携設定を実施します。

この設定の際に、Jump アカウントで作成した ID プロバイダに関連付ける IAM ロール名はdemo-assume-roleとして、他の AWS アカウントにスイッチロールできるように下記のポリシーを設定した IAM ポリシーをアタッチしました。

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "*"
    }
}

スイッチロール先アカウントの設定

スイッチロール先アカウントにおいて、Jump アカウントの IAM ロールdemo-assume-roleを信頼する IAM ロールを 2 つ作成します。作成・更新作業が無いときは ReadOnlyAccess を利用し、作成・更新作業が必要なときは AdministratorAccess を利用することを想定しています。

項目	設定内容	設定内容
IAM ロール名	administrator-access-role	read-only-access-role
許可 - AWS 管理ポリシー	AdministratorAccess	ReadOnlyAccess
許可 - カスタマー管理ポリシー	なし	なし
許可 - インラインポリシー	なし	なし
信頼ポリシー	下記参照	下記参照

信頼ポリシーは下記としました。Jump アカウントの IAM ロールを信頼します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:role/demo-assume-role"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

動作確認

Entra ID の「マイアプリ」ページから Jump アカウントにアクセスします。この際に、Jump アカウントの IAM ID プロバイダに複数の IAM ロールを関連付けしている場合は、利用するロールを選択する画面が表示されますが、今回は関連付けしているロールは 1 つのためロール選択画面は表示されずに Jump アカウントに遷移します。

Jump アカウントにアクセス後は、スイッチロールの設定をします。

administrator-access-roleとread-only-access-roleの両方のロールでマネジメントコンソールにアクセスできました。画像右上にスイッチロールの設定で指定した表示名が表示されています。

複数のユーザーと権限の管理

今回のブログではシンプルな例で試しまたが、実際の環境は複数のユーザーやプロジェクトがあります。その場合は主に次の 2 通りの設定ができそうです（他にもあるかもしれません）。

1 つ目は、Jump アカウントに複数のロールを用意して、最終的にアクセスするアカウントにおいて Jump アカウントのロール単位で信頼するパターンです。

2 つ目は、Entra ID からは Jump アカウントの AsuumeRole 用ロールのみにアクセスできるようにして、最終的にアクセスするアカウントの信頼ポリシーで Entra ID ユーザーの一致も条件に指定するパターンです。

Entra ID にユーザーが増えた場合に最終的にアクセスするアカウトでユーザーを追加する手間が発生することになります。一方で、Entra ID 側の設定変更の手間を少なくできる可能性があるため、Entra ID と AWS の管理部署が異なり、Entra ID 側を簡単に設定変更できない場合などには便利かもしれません。

2 つ目のパターンを実現する、最終的にアクセスするアカウント（上図のスイッチロール先アカウント）における IAM ロールの信頼ポリシー例です。Condition でユーザー名の一致を条件としています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:role/demo-assume-role"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringLike": {
                    "aws:userid": "*:[email protected]"
                }
            }
        }
    ]
}

次のブログでも紹介されている方法となります。

両方のパターンにはそれぞれメリットとデメリットがあるため、状況に応じて検討する必要がありそうです。