AWS IAM Identity Center が使えない環境があるって知らなかった！

こんにちは、Okta好きの imr です。

本投稿は以下の続きになります。

前編のあらすじ

• AWS請求代行サービス(リセールサービス) のリセラーにおいて割引率が高いプランではルートアカウントをリセラーが管理するため、AWS Organization や AWS Control Tower の利用に制限がかかっていることが多い。
• 割引率が高いプランでもマルチアカウント管理やマルチアカウントログインを行いたい。
• Okta で SAML連携しよう！

ユーザーの利用イメージ

Okta のユーザーメニューから AWS Account Federation アプリを選択するとロールを選択する画面が開き、選択したロールにログインすることができます。

やってみた

Okta で AWSアカウントフェデレーションを使用して複数の AWSインスタンスに接続する統合ガイドがあります。
グループを使用してOktaを複数のAmazon Web Servicesインスタンスに接続する|Okta

準備

Administrator 権限とReadOnly 権限のロールを使用可能な「AWS_admin_role」グループと ReadOnly 権限のロールだけ使用可能な「AWS_RO_role」グループを作成します。
※ Okta が公開しているドキュメントでは AD や LDAPなどの外部ディレクトリサービスを使用して管理する手順が記載されていますが今回は Okta 内でグループを作成しています。

管理者メニューから「ディレクトリ」→「グループ」→「グループを追加」で「AWS_admin_role」と「AWS_RO_role」グループを作成します。

Okta で AWS アカウントフェデレーションアプリを作成

管理者メニューから「アプリケーション」→「アプリケーション」→「アプリカタログを参照」→検索で「AWS」と入力→「AWSアカウントフェデレーション」をクリック→「統合を追加」をクリック

「次へ」をクリック

サインオンオプションで 「SAML2.0」 を選択

メタデータURLをコピー

コピーしたURLへアクセス、開いたページを名前を付けて保存で metadata.xml をローカルに保存。

Oktaの管理画面操作はいったんここまで。

AWS IAM での作業

登録するAWSアカウントに対して同じ内容を繰り返します。
AWS のコンソール画面で IAM を開き、「IDプロバイダ」をクリック、「プロバイダを追加」をクリック

AWS「AWS IAM Identity Center の使用を検討しましたか？」
imr「AWS IAM Identity Center が使えない環境です。」

「プロバイダのタイプ」に「SAML」を選択する
任意のプロバイダ名(本記事では okta_sso)をつけて「メタデータドキュメント」で「ファイルを選択」をクリック保存した metadata.xml を選択、必要に応じてタグを追加して「プロバイダを追加」をクリック

SAML2.0フェデレーション用に以下のロールを作成します。
AdministratorAccess ポリシーを付与したロール「SAML_admin」

ReadOnlyAccess ポリシーを付与したロール「SAML_RO」

管理したいAWSアカウントが複数ある場合は IDプロバイダーの追加とロールの作成をすべてのアカウントで実施します。

Okta で AWS アカウントフェデレーションアプリを作成(つづき)

「グループマッピングの使用」にチェックを入れると「アプリフィルター」「グループフィルター」「ロールバリューパターン」の項目が追加されるので設定します。

本記事では以下のとおり設定します。
「アプリフィルター」Okta
「グループフィルター」^aws#\S+#(?{{role}}[\w-]+)#(?{{accountid}}\d+)$
「ロールバリューパターン」arn:aws:iam::${accountid}:saml-provider/IAM で設定したプロバイダ名,arn:aws:iam::${accountid}:role/${role}

「完了」をクリック

作成したアプリに「AWS_Admin_Role」と「AWS_RO_Role」を割り当てます。

ロールグループの作成
AWS側で作成した「SAML_admin」ロールと「SAML_RO」ロールを識別するために Okta 側でロールグループを作成します。
管理者メニューから「ディレクトリ」→「グループ」→「グループを追加」をクリック、グループ名は「グループフィルター」に合うように以下の命名規則に合わせます。

aws#アカウントエイリアス名#ロール名#アカウントID

各ロールグループと管理用グループの紐づけを実施します。
管理グループ「AWS_Admin_Role」は「SAML_admin」と「SAML_RO」のロールグループに対して
管理グループ「AWS_RO_Role」は「SAML_RO」のロールグループに対して紐づけを行います。
グループの画面で「ルール」を選択「ルールを追加」からルールを作成します。
本記事では Okta のグループ機能を利用しています、Okta のライフサイクル機能のルール設定にて管理グループの権限に合わせてロールグループに所属するように割り当てを行っています。
Active Directory を用いる場合は、アクセス権を付与するAWSロールグループの［Members Of（次のメンバー：）］として管理グループを割り当ててください。

作成したルールは非アクティブになっているため「アクション」から「アクティブ化」します。

設定は以上です。

動作確認

管理グループの権限ごとに表示されるロールが異なることを確認します。
テスト次郎 が AWS_admin_role グループに所属、テスト太郎 が AWS_RO_role グループに所属しています。

テスト次郎がユーザーページにアクセス、AWS Account Federation のアプリをクリックします。

ロール選択画面が表示されます。

SAML_admin を選択した場合は SAML_admin のロールで接続できます。

SAML_RO を選択した場合は SAML_RO のロールで接続できます。

テスト太郎がユーザーページにアクセス、AWS Account Federation アプリをクリックします。

テスト太郎は AWS_RO_roleグループに所属しているためアカウント選択画面は表示されず、SAML_ROのロールで接続しました。

もう少し楽にできない？

AWS IAM で実施する IDプロバイダの登録、ロール作成については AWS CloudFormation でも行えます。
Okta側で同一アプリケーション上で管理するため IDプロバイダのプロバイダ名、メタデータは同一のものを使用します。
SAML2.0 フェデレーション用のロールも決まったポリシーを設定するのであれば気軽にテンプレートを用意できると思います。

スイッチロールとの違い

ユーザーはアカウント情報やロール情報を入力せずに対象のシングルサインオンできます。
アカウント情報や権限を管理者が一括で管理できます。
AWSへ接続する各個人にアカウント情報を管理させないようになるため、スイッチロールより安全に管理できるのではないでしょうか。

まとめ

• Okta に SMAL 連携アプリのテンプレートと統合ガイドがあるため連携は難しくない。
• AWS側の設定は CloudFormation で実行可能。
• 管理グループとロールグループを外部ディレクトリサービスかOktaのグループにて作成して管理する必要がある。
• 個人によるアカウント情報管理がなくなる。

おまけ

AWS CLI を使用する場合でも IdPとして Okta を使用できます。
以下の統合ガイドを参考にしてください。

OktaをAWS CLIのIdPとして構成する – Okta