エージェントのワークフロー権限はどのように機能しますか?実際のリンクで明確にします

権限はスイッチではなく、エージェントの動作境界です。

コードの読み取りと書き込み、PR の送信、AWS CLI の呼び出しを自動的に実行できるエージェントを構築しているとします。 「本番環境にデプロイ」するように指示しましたが、エージェントにはどのような権限が必要ですか?多くの人の最初の反応は、「管理者の資格情報を与えるだけ」です。これが 1 番目の誤解です。

エージェントのワークフロー権限は、アクセス カードのようなバイナリの「はい/いいえ」スイッチではなく、一連のきめ細かいスコープと制約です。各権限は実際に 2 つのことを行います。エージェントが操作できるリソースと、それらのリソースに対して実行できるアクションを定義します。

実際のリンク: 意図から実行まで

私は数年前に CI/CD パイプラインを引き継ぎました。エージェントは、コードのプル → テストの実行 → イメージの構築 → ECR へのプッシュ → ECS サービスの更新を担当していました。このプロセスには、次の 6 つの異なる権限セットが含まれます。

1. コード ウェアハウスの読み取り権限 (プル コード)
2. ビルド環境の書き込み権限（キャッシュ、ログ）
3. ミラーウェアハウス書き込み許可（プッシュイメージ）
4. オーケストレーション サービスの更新権限 (トリガー デプロイメント)
5. キー管理読み取り権限（データベースパスワードの取得）
6. ログ書き込み権限（実行結果の記録）

当時、私はトラブルを避けたかったので、「開発者の完全な権限」ロールをエージェントにバインドしました。最初の週は順調に進んでいた。 3 週目では、誤った操作によりエージェントが未使用の EBS ボリュームを削除してしまいました。そのボリュームには 3 日分のテスト データがまだ含まれていました。チームは修正に 2 日かかりました。

その後、エージェントのワークフロー権限は「何ができるか」ではなく、「間違って実行された場合にどれだけの損害が発生するか」を決めるものであることがよくわかりました。

権限チェックリスト: エージェントに対して確認してください

それ以来私が使用しているチェックリストは次のとおりです。新しいエージェント ワークフローを作成するたびに、それを 1 つずつ確認します。

• 各ステップには、そのタスクを実行するために必要な最小限の権限しかありませんか?たとえば、テスト ステップでは ECR を変更する権限は必要ありません。
• アクセス許可の範囲はリソース ID またはタグですか?たとえば、タグ env=staging が付いたリソースのみが操作できます。
• 機密性の高い操作 (リソースの削除、IAM の変更、キーの読み取りと書き込み) に対する追加の確認メカニズムはありますか?たとえば、二次承認や手動介入のステップなどです。
• ワークフローは別の IAM ロールの下で実行されますか?複数のエージェントを同じ役割に詰め込まないでください。
• アクセス許可ポリシーはバージョン管理されていますか?すべての変更はロールバックして監査できます。
• 実行タイムアウトと頻度制限が設定されていますか?許可の拡大につながる無限の再試行を避けてください。

最も陥りやすい罠

** 落とし穴 1: エージェントの役割をユーザーにバインドします。 ** 多くのプラットフォームでは、現在のユーザー認証情報を使用してエージェントを直接作成できます。利点は高速であることですが、欠点は、エージェントが無関係なリソースを削除する権限を含むユーザーのすべての権限を取得することです。正しいアプローチは、ワークフローごとに専用のロールを作成することです。

** 落とし穴 2: クロスアカウント権限の無視。 ** エージェントが別の AWS アカウントの S3 バケットにアクセスする必要がある場合、このアカウントのロールに AssumeRole アクセス許可が必要なだけでなく、他のアカウントがこのロールを信頼する必要もあります。このリンクは最も忘れられやすく、実行時に「権限が不十分です」エラーが発生します。

** 落とし穴 3: Resource フィールドに対するアクセス許可ポリシーが緩すぎます。 ** たとえば、"Resource": "*" はすべてのリソースを公開します。 Action が s3:GetObject に制限されている場合でも、バケット ポリシーで許可されていれば、エージェントはバケット全体を読み取ることができます。リソースを常に特定のバケット パスまたはリソース ARN に制限することをお勧めします。

失敗した場合の対処法: ダウングレードしてハッチから脱出する

最善のチェ​​ックを行ったとしても、権限エラーが発生する可能性があります。私が遭遇したのは、エージェントが午前 3 時に ECS サービスを更新しようとしたときに、ロール セッションのタイムアウトが原因で失敗したということです。解決策は、より大きな権限を与えることではなく、次のことを行うことです。

1. ワークフローに再試行ロジックを追加し、権限例外をキャッチした後に操作対象を自動的に下げます (たとえば、「更新サービス」から「差分出力のみ」へのダウングレード)。
2. デバッグおよび運用スナップショット用の読み取り専用権限を持つ代替ロールを準備します。
3. 認証失敗ログを別のセキュリティ アカウントに記録して、その後の理由の監査を容易にします。

概要

エージェントのワークフロー権限の中核は、すべてのリスクを防ぐことではなく、リスクを許容範囲内に制御することです。すべての許可ステートメントは防御線です。次回ワークフローにステップを追加するときは、「このステップが悪意を持って使用された場合、最大の損失はいくらですか?」と尋ねるとよいでしょう。その答えは、より安全なアクセス許可ポリシーを作成することにつながります。