Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CloudTrail 見ろ、ドキュメントちゃんと読め

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.
Avatar for Kai Kai
March 10, 2026

CloudTrail 見ろ、ドキュメントちゃんと読め

Avatar for Kai

Kai

March 10, 2026
Tweet

More Decks by Kai

Other Decks in Programming

Transcript

  1. やりたかったこと Kiro おなじみ AWS の AI コーディング支援ツール(旧 Q Developer のリブランド)

    AWS からバジェットをもらったので開発メンバー全員につかってもらうぞ IAM Identity Center (IdC ) Kiro のライセンスを「誰に割り当てるか」を管理するため、AWS の SSO 基盤 である IdC を使うぞ 従業員を User として管理し、利用者を Group (グループ) にまとめられるぞ 今回のゴール Kiro 利用希望者のGroup を作成し、そのGroup がKiro をりようできるようにするぞ ( 個人ごとに登録すると人が増えるたびに手業が必要でたいへんだぞ)
  2. Kiro のリソース構造 概念 説明 Profile 1 アカウント × 1 リージョンに1

    つ。 作成時に IdC へマネージドアプリケ ーション( QDevProfile-region ) が紐づく Plan 何を提供するか(Pro / Pro+ ) Subscription 誰にライセンスを割り当てるか ちなみに: 裏側はまだ Q Developer コンソールは Kiro にリブランドされたが、API の内 部名は Q Developer のまま。 Profile (器) ├── Plan (何を提供するか) └── Subscriptions (誰が使うか) ├── Individual: 個人単位 └── Group: グループ単位 ← 今回の対象 ※ 管理者セットアップガイド
  3. グループサブスクリプションに必要なもの management account(親アカウント) us-east-2 IAM Identity Center 管理者グループ(私) 利用者グループ PermissionSet

    member account(子アカウント) us-east-1 Kiro Profile(器) Plan(Kiro Pro+)+ Subscription(Group) 「何を提供するか」と「誰が使うか」を一括で割り当てる 操作権限 ライセンス割当 青: 管理者の操作権限の流れ / 緑: 利用者ライセンスの流れ / 破線: クロスアカウント
  4. Tips: 利用者グループの PermissionSet は不要? IdC がリソースにアクセスする際、2 つのアクセス経路が存在するよ 経路 仕組み 用途

    AWS accounts PermissionSet を割り当て → IAM ロール作成 管理者が AWS コンソールを操作 Applications マネージドアプリケーションを割り当て 利用者が Kiro を利用 管理者 → PermissionSet (AWS accounts 経路) 利用者 → マネージドアプリケーション(Applications 経路) 利用者に PermissionSet は不要。別の経路でアクセスする。 さっきの図を見て「利用者グループには PermissionSet 要らないの?」と思った方向け
  5. セットアップの流れ management account(親アカウント) us-east-2 IAM Identity Center 管理者グループ(私) 利用者グループ PermissionSet

    member account(子アカウント) us-east-1 Kiro Profile(器) Plan(Kiro Pro+)+ Subscription(Group) 「何を提供するか」と「誰が使うか」を一括で割り当てる 1 2 ③ Kiro 公式の IAM ポリシーを設定 ④ member account に割当 5 6 ❌ ここで失敗 ① グループ作成 ② PermissionSet 作成 ③ IAMポリシー設定 ④ account に割当 ⑤ Profile 作成 ⑥ 割当(失敗)
  6. ⚠ Error Your account is not authorized to make this

    call. もっといっぱい喋れ( 調査開始)
  7. 右往左往した エラーメッセージは「権限がない」としか言ってくれない。何が足りないかわからず、思いつく原因を片っ端から潰していった。 リージョン不一致を疑う IdC は us-east-2 、Profile は us-east-1 。このクロスリージョン

    が原因では? ❌️ 他のリージョナルサービスでは問題なく動いている。これが 原因なら他も壊れているはず。 Trusted Access を疑う AWS サービスが Organizations (マルチアカウント管理)配下 の別アカウントで動作するための仕組み。コンソールにこう表 示されていた: Amazon Q Amazon Q generates, tests, and debugs code... ❌️ 既に有効化済み。readonly 権限では参照できず "Not Enabled" に見えていただけ。勘弁してくれ ⊘ Not enabled 自分の権限では検証すらできず、試すたびに管理者への依頼が必要だぞ 一週間くらいふて寝したぞ
  8. ついに!CloudTrail を確認 なんで見なかったの? → 公式ドキュメントの IAM ポリシーをそのままコピペしたので権限不足はないと 思っていたよ、万死万死 管理者に CloudTrail

    (AWS の API 操作ログ)の確認を依頼 AccessDenied → 権限不足やんけ { "eventSource": "q.amazonaws.com", "eventName": "CreateAssignment", "errorCode": "AccessDenied", "errorMessage": "Your account is not authorized to make this call.", "requestParameters": { "principalType": "GROUP", "subscriptionType": "Q_DEVELOPER_STANDALONE_PRO_PLUS" } }
  9. では何が足りなかったのか Kiro 公式のポリシー例で PermissionSet を作ったが、Group 割当に必要な権限が不足していた。 最も疑わしいのは、SLR (Service-Linked Role =

    AWS サービスが自動で使う IAM ロール) の作成権限かも 不足した可能性が高い権限 iam:CreateServiceLinkedRole ( AWSServiceRoleForUserSubscriptions を対象) Kiro 公式のポリシー例 含まれていない Q Developer 公式の管理者ポリシー 含まれている 自分がやったこと: Kiro 公式のポリシーをコピペして PermissionSet を作った。Q Developer 公式に別の管理者ポリシーがあることに気 づかなかった。 Kiro 公式の想定していない状態になっていたんですか?
  10. SLR (Service-Linked Role )とは AWS サービスがリソースにアクセスするために使う専用の IAM ロ ール。 User

    ではなくサービスが assume する。 特徴 説明 誰が作るか 管理者が作成 or サービスが自動作成 誰が使うか AWS サービス 編集 不可 管理者が Group 割当を実行 → Kiro が処理開始 → SLR を assume → IdC 等にアクセス → SLR 未作成なら自動作成 → 管理者に iam:CreateServiceLinkedRole が必要 参考: AWS 公式 - SLR
  11. なぜ SLR の作成権限が必要だったのか(推測) 前提: Subscription 割当時、Kiro は SLR ( AWSServiceRoleForUserSubscriptions

    )を使って 利用者グループに誰がいるかを IdC に問い合わせる。SLR が 未作成の場合、サービスが自動作成を試みる。 (Kiro 公式) 管理者 PermissionSet 1 Subscription 割当 Kiro q.amazonaws.com 2 SLR を使いたい SLR 未作成 IdC 利用者グループ 参照 3 SLR 自動作成を試みる iam:CreateServiceLinkedRole 4 管理者の権限を確認 AccessDenied 赤: 失敗した経路
  12. 教訓 1. CloudTrail は最初に見る エラーメッセージだけで推測せず、CloudTrail で実際の API コールとエラーを確認する。 切り分けの精度が段 違い。

    2. 切り分けの第一歩は「広い権限で試す」 PowerUser で通れば権限の問題、通らなければサービスの問題。最初にやっていれば右往左往せずに済んだ。 3. 関連ドキュメントを横断的に読む Kiro 公式のポリシー例だけで満足した。Q Developer 公式に別の管理者ポリシーがあることに気づかなかっ た。1 つのページで満足せず、関連リンクを辿る習慣が大事。 (4. 私に権限をください)