AWSの中で、IAM(Identity and Access Management)といえば、マネジメントコンソールにログインする時に使われるサービス、各種AWSのサービスの設定、変更などの権限管理に使われるサービス、という概要は皆さんご存知だと思います。
IAM User, IAM Group, IAM Policy。どれも、分かり易い概念ですね。
では、IAMの中にあるIAM Roleについて、皆さんは一言で説明できるでしょうか？難しいと感じる方が多いでしょう。
このブログでは、IAM Roleについて、解説をしたいと思います。
IAM Roleは、IAM User・IAM Groupとはそもそも異なる存在
IAM Roleを使う一般的なケースは、EC2インスタンスやLambdaに対してIAM Roleを割り当て、EC2インスタンスやLambdaから、DynamoDB、S3などにアクセスするといった使い方です。
IAM Userは、一般的に人一人に対して1アカウント、そしてIAM UserをグルーピングするためにIAM Gruopを使いますから、IAM RoleがIAM User・IAM Groupとは異なる存在であることが分かるかと思います。
IAM Roleの仕組み
EC2で使うケースが分かり易いので、EC2で使うケースをベースに解説しましょう。EC2からS3へアクセスするために、EC2インスタンスにIAM Roleを割り当てているとします。
EC2からアクセスすると、EC2のインスタンスメタデータより、割り当てられているIAM Roleの権限に基づいて、Security Token Service(STS)が働き、一時的に利用可能なアクセスキーとシークレットアクセスキー、トークンが払い出されます。
※EC2のインスタンスメタデータに関しては、こちらを参照してください
図にすると、このような形になっています。
STSが払い出したトークンには期限があります。
しかし、AWS SDKを使うようなケースでは自動的に取得/再取得をする仕組みがあるため、アプリケーションに対して、アクセスキーなどを埋め込む必要がありません。
「EC2からS3へアクセスする時に、IAM Roleを使うことが推奨される」という理由は、ここにあります。
IAM Roleはいつ使うのか？
上段に書いているように、EC2インスタンスやLambdaに割り当てたりするIAM Roleですが、一般的な使い方としては、以下のようなケースが挙げられます。
- EC2やLambdaから、AWSの各種リソース(S3、DynamoDB、SQS、SNSなど)にアクセスするケース
- マネジメントコンソールにフェデレーションアクセスするケース
- Cognitoと組み合わせて、アクセスするAPIを制御するようなケース
ひとつ目のケースは仕組みで説明した内容と同じなので、2つ目と3つ目のケースを見てみましょう。
マネジメントコンソールにフェデレーションアクセスするケース
このケースは、Azure Enter IDのユーザーを使って、Identity Center経由でマネジメントコンソールにアクセスするようなケースです。
このケースを採用すると、マネジメントコンソールへのアクセスに、IAM Userを使わない運用が可能となります。
Cognitoと組み合わせて、アクセスするAPIを制御するようなケース
このケースでは、Cognitoと組み合わせることで、Xにログインが済んでいるユーザーだけAPIのアクセスを許可する、といった制御が可能になります。
まとめ
- IAM Roleは、IAM UserともIAM Groupとも異なる概念
- AWSのサービスに割り当てて使うのが基本
-
- 実際にはSTSというサービスが動いて、一時的なアクセスキーとシークレットアクセスキーが発行されている
IAM Roleを正しく理解することで、AWSをより安全に使うことが可能です。IAM Role、概念は知っているけれど説明は...という方に届いたら幸いです。