IAM Roleとは？assume可能なAWSアイデンティティ

IAM roleは、パスワードでloginする人ではなく、信頼された者なら誰でもassumeして一時的なクレデンシャルを得られる、パーミッションを持つAWSアイデンティティです。

IAM userと異なり、roleは恒久的なクレデンシャルを持ちません。代わりに、信頼されたprincipalがroleをassumeし、そのパーミッションにスコープされた短命のクレデンシャルを受け取ります。roleは、誰も長期のキーを保存することなく、AWSサービス、EC2インスタンス、CI pipelineがあなたのアカウント上で動作する方法です。

permission policy対trust policy

roleは2つのpolicyを持ちます。permission policyはroleが何をできるかを述べます。trust policyは誰がそれをassumeすることを許されるかを述べます。両方が揃う必要があります: 呼び出し元は信頼されている必要があり、roleは呼び出し元が必要とするパーミッションを持つ必要があります。

roleをassumeする

principalがroleをassumeすると、AWS STSが設定された期間後に期限切れになる一時的なクレデンシャル (access key、secret、session token) を発行します。呼び出し元はそれらを使ってAPI呼び出しを行い、セッションが終わると消えます。

roleの一般的な用途

サーバー上のアプリが自動的にクレデンシャルを得るためのEC2 instance profiles。
LambdaやECSがあなたの代わりに動作できるようにするservice roles。
AWSアカウント間のアクセスのためのcross-account roles。
GitHub ActionsのようなCIシステムのためのOIDC roles。

なぜroleがキーに勝るか

静的なaccess keyは漏洩し残り続ける可能性があります。roleは自動的に期限切れになるクレデンシャルを発行し、きつくスコープでき、誰がいつ何をassumeしたかの明確な監査証跡を残します。自動化にとって、これはより安全かつ運用しやすくもあります。

CI/CDでの役割

deploy jobがroleをassumeしてjust-in-timeなクレデンシャルを得て、deployを実行し、クレデンシャルは期限切れになります。GitHub Actions OIDCでは、workflowがtrust policyが受け入れるトークンを提示してroleをassumeするので、保存されるAWS secretsはゼロで、アクセスは特定のrepoやbranchに限定されます。

重要なポイント

IAM roleは、一時的で期限切れになるクレデンシャルを付与するassume可能なアイデンティティです。
そのtrust policyが誰がassumeできるかを制御し; permission policyが何ができるかを制御します。
pipelineは、長期のAWSキーを保存する代わりに (多くの場合OIDC経由で) roleをassumeします。