垣見です。
Temporary elevated access management (TEAM) for AWS IAM Identity Center （以下、TEAM）で、GitHubを使わないでCodeCommitを使う実用的なデプロイ方法をご紹介します。
- 初めに
- 前提条件
- 概要
- 手順
- おわりに
初めに
以前、こんな記事を投稿しました。
AWS IAM Identity Center（以下、IdC）の運用を楽にするTEAMのデプロイ方法の記事です。
TEAMのデプロイはdeploy.shというスクリプトファイルを実行することで簡単に進みます。しかし、もともとの手順はリポジトリとしてCodeCommitを使う手順となっていました。 この当時はAWS CodeCommitが使えなくなったことでTEAMのIssue上で大騒ぎしていましたが、CodeCommitは奇跡の復活を遂げました。
しかしこの騒動を経て、公式でのTEAMデプロイ手順はGitHubを使った応急対応に変更されて、そのままになっています。
GitHubを使った方法は、Classicのトークンを必要とするなどセキュリティ的に微妙な点があります。
需要があるであろうCodeCommitを使うデプロイ方法が現状わかりにくいので、今回はそれをご紹介します。
また手順内では、実運用に役立つ以下のポイントもお伝えします。
- 外部の開発環境の準備が必要ない、AWS CloudShell上からデプロイを完結させられる手順をご紹介します。
- OSSであるTEAMのどの時点のデプロイかを開発者サイドでも管理でき、かつ開発環境と本番環境で絶対に同じソースコードを使えるように、
git cloneではなくzipファイルを用いたデプロイ方法を使います。
前提条件
- AWS Organizationsが存在する
- AWS IAM Identity Centerが有効化されている
- AWS IAM Identity CenterのログインURLをメモしておく（IdCコンソール→設定→アイデンティティソース→AWS accsess portal URLのデュアルスタックまたはデフォルトIPv4のみ）
- 構築に必要な権限を持っている
- デプロイしたいバージョンのTEAMをzipファイル化してローカル（AWS環境と接続するPC端末）に保管しておく（初回はこのリリースノートから最新バージョンをとるのがおすすめです）
概要
管理アカウントでやること：
- TEAMをデプロイするアカウントに対し、各種委任を行う
- IAM Identity Centerの委任
- Cloudtrailの委任
- Account Managementの信頼されたアクセスを有効化
IdC委任アカウントでやること：
- CloudTrail Lake EventDataStoreを作成する
- IdCで、TEAM用のAdministrator・Auditorペルソナ用のグループを作る
TEAMのデプロイ
- デプロイ用ファイルの準備
- defaultクレデンシャル設定
- parameter.shの用意
- deploy.shの実行（= デプロイ）
TEAMとIdC, Cognitoを連携する
- 統合用情報取得
- SAML2.0アプリケーションの作成
- 属性マッピングの編集
- ユーザーとグループの割り当て
- Cognito連携
- ログイン確認
- 【おまけ】CloudWatch Logsの保持期間設定
deploy.shの挙動
TEAMリソースのデプロイ自体はdeploy.sh実行により簡単にできますが、裏ではCodeCommit→Amplify周り→CloudFormation、のように結構複雑に動いていました。
ファイル実行による挙動を以下に簡単にまとめておきます。（バージョン1.4.2時点）
解説（折り畳み）
前提：parameter.shとデプロイスクリプト（deploy.shおよびTEAM用のコード）を用意
- parameter.shに記載した任意のロールを使ってdeploy.sh実行。それにより以下が同時に起きる
- TEAM用のコードがCodeCommitに送られる。
- TEAM-IDC-APPスタック経由
- Amplify用Adminロール
TEAM-IDC-APP-AmplifyRole-<ランダム値>作成 - Lambda用ロール
TEAM-IDC-APP-AmplifyLambdaRole-<ランダム値>作成 - 上記ロールとCodeCommitとparameter.shの値を参照するAmplifyのApp、Branch作成
- 上記ロールを使うLambda関数
TEAM-IDC-APP-TriggerBuildLambda-<ランダム値>を作成 - →LambdaによりAmplifyのBuildトリガー
- Amplify用Adminロール
- BuildトリガーによってAmplifyが
amplify-teamidcapp-main-<ランダム値>（親スタック）を立て、以下リソースを作る- 子スタック参照用S3バケット
amplify-teamidcapp-main-<ランダム値>-deploymentとそのポリシー - CloudFormationのデプロイに合わせて、Cognito IDプールの認証済み/未認証ロールの『信頼関係』を自動で書き換えるLambda関数（CFnからInvokeされる）：
amplify-teamidcapp-main-<ランダム値>-UpdateRolesWithIDPFuncti-<ランダム値>- cognitoがappsync:GraphQLアクションを使うための承認用IAMロール：
amplify-teamidcapp-main-<ランダム値>-authRole - cognito用の何も権限を持たない未承認用IAMロール：
amplify-teamidcapp-main-<ランダム値>-unauthRole - このLambda用のIAMロール：
amplify-teamidcapp-main-<ランダム値>-authRole-idp - ※「CognitoのIDプールID」が決まらないと、IAMロールの「信頼関係」を完璧に書けず、IAMロールがないとIDプールを設定できない、という問題を解決するための仕組み。仮で作ったロールをもとにIDプールを作り、その後ロールのポリシーを実際のIDプールのIDに書き換える。
- cognitoがappsync:GraphQLアクションを使うための承認用IAMロール：
- 子スタック参照用S3バケット
- ネストされた子スタックごとにリソースが作成される。その時に、リソース用のIAMロールも順次できていく
手順
1. 管理アカウントで各種委任を行う
しかし今回の手順の場合、コンソール上で作業したほうがシンプルに早く終わるので、ここは手作業で行います。
（init.shを利用したい方は、後続の手順4を見ながら管理アカウント上でもCloudShell上での設定を行ってください）
1-1. デプロイアカウントにIAM Identity Centerを委任する
1.Organizations管理AWSアカウントのAWSコンソールへログイン・アクセスする
AWS IAM Identity Centerコンソールの画面に遷移する
設定に移動
「管理」→「委任された管理者」→「アカウントを登録」をクリック
1-2. デプロイアカウントにCloudtrailを委任する
1.Organizations管理AWSアカウントのAWSコンソールへログイン・アクセスする
CloudTrailコンソールの画面に遷移する
設定に移動
組織の委任された管理者 → 「管理者を登録」をクリック
- IAM Identity Center委任アカウントの12桁のアカウントIDを入力し、「管理者を登録」をクリック
1-3. Account Managementの信頼されたアクセスを有効化する
Organizationコンソール → サービス → AWS Account Management へ移動
信頼されたアクセスを有効にする → 「有効化」を入力 →信頼されたアクセスを有効にする
2. IdC委任アカウントでCloudTrail Lake イベントデータストアを作成する
ただし、イベントデータストアは通常のCloudTrailに加えて別で設定するもので、かつ2026年3月現在「組織全体」または「そのアカウントだけ」の2択しか選べないため、有効活用するための組織全体のオンにはかなりコストがかかります。（AアカウントやB OUのみ、という指定ができない）
こちらはデプロイ時にARNを指定する必要があるため、この機能を使いたくない・コストをかけたくないという場合は、「無効化の状態で作ってARNのみ取得する」ことを推奨します。
IAM Identity Centerを委任したAWSアカウントのAWSコンソールへログイン・アクセスする
CloudTrailコンソールの画面に遷移する
Lake → イベントデータストア に移動 「イベントデータストアの作成」をクリック
以下の通り入力し、「次へ」をクリック ※以下の項目はすべて任意です。要件に合わせて設定してください。
イベントデータストア名：team-log（任意の名前で良いです）
- 料金オプション：1 年間の延長可能な保持料金
- 保存期間：1 年 (追加料金なしで取り込み料金に含まれています)
- 暗号化：自分の AWS KMS キーを使用にチェックを入れない
- Lake クエリーフェデレーション：有効にしない
タグ：任意
以下の通り入力し、「次へ」をクリック
イベントタイプ
- イベントタイプを選択：AWS イベント
- AWS イベントのタイプを指定します：CloudTrail イベント
- CloudTrail イベント
- 「管理イベント」のみにチェックを入れる
- オプション
- 組織内のすべてのアカウントについて有効化：チェックを入れる（※取得したアカウントのみの監査ログをTEAM監査ペルソナが確認することが出来ます）
- イベントデータストアに現在のリージョン (ap-northeast-1) のみを含める：チェックを入れない
- イベントを取り込む：チェックを入れない（※ここでチェックを入れるとデータストア作成時点からCloudTrailログの取り込みが開始します。料金がかかりますのでに注意して下さい。）
- 管理イベント
- Simple event collectionを選択
- Choose events to log：Only write events
- Event exclusions - オプション：
- AWS KMS イベントの除外：チェックを入れない
- Amazon RDS のデータ API イベントを除外：チェックを入れない
- Enable Insights events capture：有効にしない
- イベントタイプを選択：AWS イベント
確認画面を見て、問題が無ければ「イベントデータストアの作成」をクリックする
作成したイベントデータストアのステータスが作成中から停止済み（または有効）になるまで画面を更新する
作成したイベントデータストアのARNをコピーしておく
3. IdCで、TEAM用のAdministrator・Auditorペルソナ用のグループを作る
承認ペルソナ、申請ペルソナは後からでも作れますが、この二つは最初から指定する必要があります。監査ペルソナは以下のようなセッションごとの行動ログを見ることが出来ます。
管理者ペルソナはアカウントへの承認者、申請者の権限をユーザーに割り当てたり、TEAMアプリそのものの設定（通知など）を変更できます。アプリ上での見える範囲も異なります。
※Microsoft Entra IDと統合・自動プロビジョニングしている場合はそちらから操作してください
AWS IAM Identity Centerコンソール→ グループ →グループを作成
gグループ名を入力（例：TEAM Admins、TEAM Auditors）、各ペルソナにしたいユーザーを割り当てる
「グループを作成」
4. TEAMのデプロイ
4-1. デプロイ用ファイルの準備
（CloudShell上でgit cloneも可能ですが、Tag付けされていない微妙なバージョンや一部書き換えしたバージョンを使っていたり、検証環境と本番環境で「変更されていないこと」を担保したりしたい場合などのために、一度使うソースコードをzipで保存しておくことをお勧めします）
なお、リリースノートから過去の主要アップデートを追うことができます。zipもここにあります。
OSSであるTEAMはブランチ管理がちょっと微妙で、mainに数日おきにマージが走っていったりするときがありました。ですので、このリリースノートにあるタグ付けされた最新バージョンを使うのが、後からも振り返りやすくいいのではないかと思います。
- Cloudshellを開く →アクション→ファイルのアップロード→ ローカルに保存したzipファイルを開く（今回は現時点での最新のiam-identity-center-team-1.4.2.zipとします。）
- 以下を順に実行する。（
iam-identity-center-team-1.4.2.zipはzipファイル名に置き換えてください）
unzip iam-identity-center-team-1.4.2.zip cd iam-identity-center-team-1.4.2
- 以下を順に実行する。
git init git branch -m main git add . git config --global user.email "<任意のメールアドレス>" git config --global user.name "<任意の名前>" git commit -m "initial commit" cat ~/.gitconfig
cat実行後、以下のように出ていたら問題ないです。
[user] email = <任意のメールアドレス> name = <任意の名前>
- 以下を実行する。
git remote add origin https://example.com/dummy.git
4-2. defaultクレデンシャル設定
- 以下を1行ずつ順に実行
mkdir -p ~/.aws echo "[default] region = ap-northeast-1" > ~/.aws/config chmod 600 ~/.aws/config cat ~/.aws/config
catの実行後、以下のようになればOK
$ cat ~/.aws/config [default] region = ap-northeast-1
4-3. parameter.shの用意
- 以下を順番に実行する。
cd deployment/ cp -n parameters-template.sh parameters.sh vi parameters.sh
vimなどで、paremeter.shを自環境に合わせて編集します。
必須：
- IDC_LOGIN_URL - AWS IAM Identity Center ログインURL
- REGION - デプロイするリージョン。AWS IAM Identity Centerのあるリージョンでもある。（※マルチリージョンIdCは使えない）
- TEAM_ACCOUNT - TEAMデプロイアカウント。IdC委任アカウント。
- ORG_MASTER_PROFILE - Organizationsの管理アカウントだが、これは手作業で先ほど実施したのでコメントアウトしても問題ない。
- TEAM_ACCOUNT_PROFILE - プロファイル。今回は上で設定したdefaultを入力。
- TEAM_ADMIN_GROUP - TEAM上で管理ペルソナとして動くグループ
- TEAM_AUDITOR_GROUP - TEAM上で監査ペルソナとして動くグループ
- CLOUDTRAIL_AUDIT_LOGS - 先ほど作ったCloudTrail Lake イベントデータストアのARN
- SECRET_NAME - GitHubを使う場合はSecrets Managerの名前を入れるが、今回はコメントアウトでよい。これが設定されているとGitHubを使うやり方に移行してしまう。
オプション：
- TAGS - 任意でタグを付けられる。コスト配分タグなどをつけるのがよさそう。
- UI_DOMAIN - Amplify がホストするTEAMアプリにカスタムドメインを付けたい場合入力
こんな感じ：
IDC_LOGIN_URL=https://d-12345678.awsapps.com/start REGION=us-east-1 TEAM_ACCOUNT=123456789101 # ORG_MASTER_PROFILE=OrgMAsterProfileName TEAM_ACCOUNT_PROFILE=default TEAM_ADMIN_GROUP="TEAM Admins" TEAM_AUDITOR_GROUP="TEAM Auditors" TAGS="tag1=value1 tag2=value2" CLOUDTRAIL_AUDIT_LOGS=arn:aws:cloudtrail:us-east-1:123456789101:eventdatastore/e646f20d-7959-4682-be84-6c5b8a37cf15 # UI_DOMAIN=portal.teamtest.online # SECRET_NAME=TEAM-IDC-APP
- 以下のようなコマンドで確認しておく
cat parameters.sh
4-4. deploy.shの実行（= デプロイ）
- CloudShell上で、まだ自分がiam-identity-center-team-1.4.2/deploymentディレクトリにいることを確認する
- 以下を実行する。この実行により、parameter.shを参照した各種デプロイが始まる
./deploy.sh
- Cloudformationコンソールを開く
- スタック作成が進んでいることをコンソールで参照し、30分ほどのデプロイを待つ。 Amplify コンソールを開く。AmplifyコンソールでTEAM-IDC-APPアプリを選択し、mainブランチが「デプロイ済み」に完了表示になっていたら次に進んでOK
- Cloudformationコンソールでteamとつくスタック群のデプロイが成功していることを確認する
5. TEAMとIdC, Cognitoを連携する
5-1. 統合用情報取得
- CloudShell上で、まだ自分がiam-identity-center-team-1.4.2/deploymentディレクトリにいることを確認する
- 以下を実行する。
./integration.sh
この実行により、以下3点データが返ってくるのでメモしておく。
- applicationStartURL - AWS IAM Identity Center アプリケーションプロパティの構成設定
- applicationACSURL - AWS IAM Identity Center アプリケーションメタデータ構成設定
- applicationSAMLAudience - TEAM アプリケーションの AWS Cognito ユーザープール ID の URN
5-2. SAML2.0アプリケーションの作成
1.AWSのIAM Identity Centerコンソール→アプリケーションの割り当て→アプリケーション→アプリケーションの追加 に移動、以下のように設定する
- 設定するアプリケーションがある → SAML 2.0を選択し、次へをクリック
- 表示名：TEAM IDC APP
- アプリケーションの構成セクション：TEAM アプリケーションの説明として「TEAM for IAM Identity Center (<GitHubのURL>)」等を追加
AWS IAM Identity Center SAML メタデータファイル URLの URL をコピーして保存しておいてください。
2.続けて以下のように入力する
- アプリケーション プロパティセクションのアプリケーション開始 URL：先ほどメモしたapplicationStartURLパラメータの値を入力
- アプリケーション メタデータセクション：「メタデータ値をマニュアルで入力する」を選択
- アプリケーション ACS URL：先ほどメモしたapplicationACSURLパラメータの値を入力
- アプリケーション SAML オーディエンス：先ほどメモしたapplicationSAMLAudienceパラメータの値を入力
[送信]をクリックして設定を保存してください。
5-3. 属性マッピングの編集
1.「アクション」のドロップダウンをクリックし、属性マッピングの編集を選択して、次の値を追加する
- Subject - ${user:subject} - persistent
- Email - ${user:email} - basic
変更の保存をクリックしてください。
5-4. ユーザーとグループの割り当て
1.[割り当てられたユーザーとグループ]の下で、 [ユーザーとグループを割り当てる]をクリックしてユーザーを追加する**
これにより、割り当てられたユーザーとグループに TEAM アプリケーションにログインするアクセス権が付与されるので、以下を検索窓に入れて追加してください。
- デプロイ時の
parameter.shでTEAM_ADMIN_GROUPに指定したグループ - デプロイ時の
parameter.shでTEAM_AUDITOR_GROUPに指定したグループ - その他TEAMの承認ペルソナ、申請ペルソナとして使いたいグループ・ユーザー
5-5. Cognito連携
1.CloudShellを開き、iam-identity-center-team-1.4.2/deploymentに移動する
2.TEAM Cognito ユーザープールの設定を更新する
# details-template.jsonファイルの内容をdetails.jsonという名前の新しいファイルにコピー $ cp details-template.json ./details.json
- details.jsonファイル内のMetadataURL を、先ほどコピーしたAWS IAM Identity Center SAML メタデータファイル URLの値に置き換える
vi details.json
{ "MetadataURL": "<AWS IAM Identity Center SAML メタデータファイル URL>" }
4.自身が/deploymentにいることを確認し、以下のコマンドを実行する
# CognitoのMetadataURLの設定を反映
$ ./cognito.sh
6. ログイン確認
これでデプロイは完了です！おめでとうございます！
TEAM管理者としてログインできるか確認してみましょう。
自分のIAM Identity CenterユーザーをTEAM Admins（デプロイ時のparameter.shでTEAM_ADMIN_GROUPに指定したグループ）に所属させ、IAM Identity Centerアクセスポータルにログインします。
「Application」をクリックするとTEAM IDC APPが追加されています。
クリックすると……ログインできました！おめでとうございます！
※Entra IDを使っていてここでエラーが出る場合は以下も参考にしてください blog.serverworks.co.jp
こちらのブログではこれ以降の設定も進めることができます。 blog.serverworks.co.jp
7. 【おまけ】CloudWatch Logsの保持期間設定
むしろ、デプロイ時にはCloudWatch Logsを明示的に作っておらず、後からLambdaが動くことでその名前のLogsができる、といったものが多いようです。
しかし、TEAMを本格的に使うなら、CloudWatch Logsの保持期間を永続的にしていると、コストへの影響はそれなりに大きくなっていくでしょう。大きい組織ほどその影響は大きいです。
ですから、TEAM上でのセッティングなどを終え、一通りTEAMを動かした段階で、CloudWatch Logsの保持期間を組織の要件に従って変更することをお勧めします。
※この際、関係のないCloudWatch Logsの保持期間を変更しないように注意してください。大半は名前に「TEAM」が入っておりますが、appsync用のロググループなどはTEAMの名が入っていません。
- CloudWatchコンソール（東京リージョン）へ移動し、左ペインでログ →ログ管理 を選択
- 保持期間が「失効しない」になっているロググループが並んでいるので、下記のロググループに対して 該当ロググループを選択→ アクション→保持期間の設定→「任意の期間」を選択→ 保存を実施し、チェックを入れる
- 終わるまで繰り返す
なお、TEAMのアップデートを行うとLambdaが増えたりする可能性もあるので、アップデートのタイミングで追加されたロググループを確認いただくのがいいかもしれません。
おわりに
うまくできましたでしょうか？もし気づいた点等ございましたらお気軽にご連絡ください。
このブログが皆様のお役に立てば幸いです。
垣見(かきみ)(執筆記事の一覧)
2023年新卒入社 エンタープライズクラウド部所属 2025 Japan AWS Jr.Champions
図解するのが好き。「サバワク」のアイキャッチ作成も担当しています
