CDKで挑むIdentity Centerの運用改善

Transcript

1. 1 Hisashi Ikenogami 2025.7.12 AWS CDK Conference Japan 2025
2. 自己紹介 池ノ上 寿志 / Hisashi Ikenogami • 株式会社エヌデーデー • CCoE支援業務 • 2025 Japan AWS Top Engineers (Services) • 2025 Japan All AWS Certifications Engineers 2
3. 本日お話しすること 1. 背景 1. Identity Center 利用構成 2. 運用方法 3. 規模感 4. 運用上の課題 5. CDK 採用の理由 2. 導入 1. 設計ポイント 2. 既存環境への適用 3. CDK 管理の負荷軽減策 3. まとめ 1. CDK 導入によって得られたこと 2. CDK 管理における課題・考慮点 3
4. 1. 背景 4 1. Identity Center 利用構成 2. 運用方法 3. 規模感 4. 運用上の課題 5. CDK 採用の理由
5. Organizations 背景：Identity Center 利用構成 • AWSログイン管理に Identity Center を利用 • IDソースには外部IDプロバイダーを利用 • Organizations内外のアカウントにログイン 5 外部ID プロバイダー Identity Center Accounts External Accounts
6. 背景：運用方法 ◼設定手段 • 最初はマネコンからぽちぽち • 設定量が多いときは CLI で一括設定 ◼管理方法 • Excel 6
7. 背景：規模感 7 アカウント数（Org内） 30 アカウント数（Org外） 15 グループ数 20 パーミッションセット数 10 ※今後さらに増えていく見込み
8. 背景：運用上の課題 • Excelどおりに設定されている保証は？ • Excel更新漏れはあるある • 実際のところ今どうなっているかがわからない 8
9. 背景：運用上の課題 • Excelどおりに設定されている保証は？ • Excel更新漏れはあるある • 実際のところ今どうなっているかがわからない ⇒ 解決手段として CDK を選択 9
10. 背景：CDK 採用の理由 ✓AWS 謹製 ✓AWS サポートが利用できる ✓日本語の情報発信が豊富 ✓CloudFormation より取り回しが効く 10
11. 2. 導入 11 1. 設計ポイント 2. 既存環境への適用 3. CDK 管理の負荷軽減策
12. Management Identity Center 導入：設計ポイント① CDKの適用範囲 12 外部ID プロバイダー Member External Organizations
13. Management Identity Center 導入：設計ポイント① CDKの適用範囲 13 外部ID プロバイダー Member External Organizations Account Group IDP Role Custom Policy Permission Set Application Group
14. Management Identity Center 導入：設計ポイント① CDKの適用範囲 14 外部ID プロバイダー Member External Organizations Account Group IDP Role Custom Policy Permission Set Application Group Org外アカウントへのアクセス Org内アカウントへのアクセス
15. Management Identity Center 導入：設計ポイント① CDKの適用範囲 15 外部ID プロバイダー Member External Organizations Account Group IDP Role Custom Policy Permission Set Application Group 自動プロビジョニング
16. Management Identity Center 導入：設計ポイント① CDKの適用範囲 16 外部ID プロバイダー Member External Organizations Account Group IDP Role Custom Policy Permission Set Application Group Control Tower の Account Factory から作成
17. Management Identity Center 導入：設計ポイント① CDKの適用範囲 17 外部ID プロバイダー Member External Organizations Account Group IDP Role Custom Policy Permission Set Application Group AWSマネージドアプリケーション「AWS External Account」を利用 ⇒ マネコンからしか作成できない
18. Management Identity Center 導入：設計ポイント① CDKの適用範囲 18 外部ID プロバイダー Member External Organizations Account Group IDP Role Custom Policy Permission Set Application Group アプリケーション数が多い（45個）ため CDKで一括作成する仕組みを別途構築 ※アプリを事前に手動作成する必要あり ※本日の発表では詳細割愛
19. Management Identity Center 導入：設計ポイント① CDKの適用範囲 19 外部ID プロバイダー Member External Organizations Account Group IDP Role Custom Policy Permission Set Application Group メンバーアカウント側で作成したポリシーを利用することも可能 Identity Center側で一元管理できないので、基本的には利用していない
20. Management Identity Center 導入：設計ポイント① CDKの適用範囲 20 外部ID プロバイダー Member External Organizations Account Group IDP Role Custom Policy Permission Set Application Group
21. Management Identity Center 導入：設計ポイント① CDKの適用範囲 21 外部ID プロバイダー Member External Organizations Account Group IDP Role Custom Policy Permission Set Application Group Assignment Assignment CDKの対象
22. Management Identity Center 導入：設計ポイント① CDKの適用範囲 外部ID プロバイダー Member External Organizations Account Group IDP Role Custom Policy Permission Set Application Group Assignment Assignment CDKの対象 コード化できる部分が少ない・・・？ 22
23. 導入：設計ポイント① CDKの適用範囲 ◼シナリオ • AWS全体管理を行うグループ • 全アカウントに対する管理者権限と読取権限を保有 23
24. 導入：設計ポイント① CDKの適用範囲 ◼シナリオ • AWS全体管理を行うグループ • 全アカウントに対する管理者権限と読取権限を保有 ◼シミュレーション 24 Organizations Account Permission Set Application Assignment 内 30 2 60 外 15 2 30
25. 導入：設計ポイント① CDKの適用範囲 ◼シナリオ • AWS全体管理を行うグループ • 全アカウントに対する管理者権限と読取権限を保有 ◼シミュレーション 25 コード化するモチベーション Organizations Account Permission Set Application Assignment 内 30 2 60 外 15 2 30 計 90 Assignment
26. 導入：設計ポイント② スタック構成 26 https://speakerdeck.com/tmokmss/answering-cdk-faqs
27. 導入：設計ポイント② スタック構成 ◼考慮事項 • 先述のシナリオでは 1グループあたりのリソース数 90 • CloudFormationスタックあたりのリソース上限数 500 • 今後グループやアカウント等が更に増える可能性あり 27
28. 導入：設計ポイント② スタック構成 ◼考慮事項 • 先述のシナリオでは 1グループあたりのリソース数 90 • CloudFormationスタックあたりのリソース上限数 500 • 今後グループやアカウント等が更に増える可能性あり ◼上記を踏まえると • ある程度スタック分割しておいた方が良さそう • グループごとにスタックを分けると状態把握し易そう • スタックが多くなるので、Nested Stack が良いかも？ 28
29. 導入：既存環境への適用 ▪状況 • 既に Identity Center の利用は始まっていた • 既存リソースをそのまま活用したい 29
30. 導入：既存環境への適用 ▪状況 • 既に Identity Center の利用は始まっていた • 既存リソースをそのまま活用したい ▪対応 • CDKインポートを活用 • グループID等をCDK内で固定値として付与することで、インタラ クティブ入力を簡略化 30 cdk import <スタックID>
31. 導入：既存環境への適用 ▪状況 • 既に Identity Center の利用は始まっていた • 既存リソースをそのまま活用したい ▪対応 • CDKインポートを活用 • グループID等をCDK内で固定値として付与することで、インタラ クティブ入力を簡略化 ▪制約 • ネストテッドスタックはインポート非対応 ⇒グループごとにスタック分割 31 個別スタックインポート後に ネスト化する手もあった？ cdk import <スタックID>
32. スタックの構成 導入：既存環境への適用 32 CDK App GroupA Stack Assignment 作成 GroupB Stack Assignment - Account ID - Group ID - Permission Set ARN - Application ARN 参照 ID類を固定値としてコード内で保持 ※この時点ではPermission SetはCDK管理外だった
33. 【課題】CDK外で定義されているものが多過ぎる 導入：CDK 管理の負荷軽減策 33 10 20 45 30
34. • Permission Set はCDK対応している • その他をどうするか？ 導入：CDK 管理の負荷軽減策 34 20 45 34 30
35. Assignmentのパラメータ 導入：CDK 管理の負荷軽減策 35 運用の過程で 数量が増減するリソース
36. 導入：CDK 管理の負荷軽減策 36 実態はランダム文字列 コード内に持ちたくない… 123456789012 (アカウントID) arn:aws:sso::<account_id> :application/<instance-id> /apl-abcdefgh12345678 arn:aws:sso:::permissionSet /<instance-id> /ps-12345678abcdefgh 123abcd-12ab-12ab- 12ab-123456abcdef (ユーザID/グループID)
37. SSMパラメータ活用、ID/ARNをCDK外に保持・自動更新 導入：CDK 管理の負荷軽減策 37 SSM パラメータ 名前 値 /ACCOUNT-ID/HOGE 123456789012 /GROUP-ID/HOGE 123abcd-12ab-12ab-12ab-123456abcdef /PERMISSION-SET-ARN/HOGE arn:aws:sso:::permissionSet /<instance-id> /ps-12345678abcdefgh /APPLICATION-ARN/HOGE arn:aws:sso::<account_id> :application/<instance-id> /apl-abcdefgh12345678 aws_ssm.StringParameter.valueForStringParameter( this, /GROUP-ID/${groupKey}` ); Lambda 参照 更新 CDK
38. スタックの構成（Before） 導入：CDK 管理の負荷軽減策 38 CDK App GroupA Stack Assignment 作成 GroupB Stack Assignment - Account ID - Group ID - Permission Set ARN - Application ARN 参照 ID類を固定値としてコード内で保持 ※この時点ではPermission SetはCDK管理外だった
39. スタックの構成（After） 導入：CDK 管理の負荷軽減策 39 CDK App Stack GroupA Stack Permission Set Assignment 作成 作成 GroupB Stack Assignment - Account Key - Group Key - Permission Set Key - Application Key SSM Parameter - Account ID - Group ID - Permission Set ARN - Application ARN Lambda 登録 参照 参照 更新 IDはSSMに保持して 自動更新することにより CDK側で意識させない SSM参照用の Keyのみ コード内に持つ ※更新部分
40. 3. まとめ 40 1. CDK 導入によって得られたこと 2. CDK 管理における課題・考慮点
41. まとめ：CDK 導入によって得られたこと • 今の状態が把握し易くなった • 複雑性は控えつつもロジックを容易に実現 • GitHub Actionsと組み合わせてテスト～レビュー～デプロイを 自動化することで、安定した運用を実現 41
42. まとめ：CDK 管理における課題・考慮点 • アプリケーション利用時は管理アカウントにデプロイが必要 • 通常は委任アカウントで管理すべき • コードからグループスタックを消しても実態は消えない • 頻度は低いため手動削除でも運用負荷はそれほど高くない • そもそも恒久的なアクセス権の付与で良いのか？ • 申請ベースでアクセス権を一時的に付与する『TEAM』ソリューション 42 https://github.com/aws-samples/iam-identity-center-team
43. Thank You ! 43