今日やったこと

  • AWS における rootユーザー、IAMユーザー、IAMロールの違いを整理した
  • rootユーザーは AWS アカウント作成時に作られる特別なユーザーであることを確認した
  • IAMユーザーは AWS アカウント内に作成する個別のユーザーであることを確認した
  • IAMロールはユーザーやAWSサービスなどが一時的に引き受けて使う権限であることを確認した
  • 日常的な作業では rootユーザーを使わず、IAMユーザーやIAMロールを使うべきだと整理した

学んだこと

rootユーザーとは

rootユーザーは、AWSアカウントを作成したときに最初に作られる特別なユーザー。

AWSアカウントそのものに近い存在で、アカウント内のすべてのAWSサービスやリソースに対して強い権限を持つ。

rootユーザーは非常に強い権限を持っているため、普段の作業で使うべきではない。

AWSアカウントを作成したら、まず rootユーザーには MFA を設定し、日常作業では使わないようにするのが基本。

rootユーザーは、請求情報やアカウント設定など、rootユーザーでしか実行できない操作が必要なときだけ使う、という位置づけで考える。

IAMユーザーとは

IAMユーザーは、AWSアカウント内に作成する個別のユーザー。

たとえば、人間の利用者ごとに以下のような IAMユーザーを作成できる。

reotech
developer-a
operator-b

IAMユーザーには、必要な権限だけを付与できる。

たとえば、S3 を見るだけのユーザー、EC2 を操作できるユーザー、CloudFormation を操作できるユーザー、というように権限を分けられる。

IAMユーザーは、以下のような認証情報を持つことができる。

- マネジメントコンソールにログインするためのパスワード
- AWS CLI や SDK から使うためのアクセスキー

ただし、IAMユーザーのアクセスキーは長期的な認証情報になりやすい。

そのため、最近は人間が直接 IAMユーザーのアクセスキーを持ち続けるよりも、IAM Identity Center や IAMロールを使った一時的な認証情報の利用が推奨される。

IAMロールとは

IAMロールは、特定の権限をまとめたもの。

IAMユーザーと違って、IAMロール自体は長期的なパスワードやアクセスキーを持たない。

IAMロールは、必要なときに誰かが一時的に引き受けて使う。

たとえば、以下のような使い方がある。

- EC2 インスタンスが S3 にアクセスするために IAMロールを使う
- Lambda 関数が CloudWatch Logs にログを出力するために IAMロールを使う
- 人間の利用者が一時的に管理者用の IAMロールを引き受ける
- 別の AWS アカウントの IAMロールを引き受けて作業する

IAMロールを使うと、長期的なアクセスキーを配布せずに、必要な権限を一時的に渡せる。

そのため、AWS では IAMロールや一時的な認証情報を使う設計が重要になる。

ざっくりした違い

rootユーザー、IAMユーザー、IAMロールの違いをざっくり整理すると、以下のようになる。

種類 何者か 主な用途 普段使いするか
rootユーザー AWSアカウント作成時に作られる最上位のユーザー アカウント全体の重要操作 基本的に使わない
IAMユーザー AWSアカウント内に作成する個別ユーザー 人間やアプリケーションの認証 最近は慎重に使う
IAMロール 一時的に引き受けて使う権限セット AWSサービス、人間、別アカウントへの一時的な権限付与 積極的に使う

rootユーザーは普段使いしない

rootユーザーは、AWSアカウント内で非常に強い権限を持つ。

そのため、普段の開発作業や運用作業で rootユーザーを使うのは危険。

たとえば、以下のような作業を rootユーザーで行うべきではない。

- S3 バケットを作成する
- EC2 インスタンスを起動する
- CloudFormation スタックを作成する
- IAMポリシーを日常的に編集する

これらの作業は、必要な権限を付与した IAMユーザーや IAMロールで行うべき。

rootユーザーは、MFA を有効化して厳重に保護し、必要なときだけ使う。

IAMユーザーは個別の利用者を表す

IAMユーザーは、AWSアカウント内の個別の利用者を表す。

rootユーザーを共有するのではなく、利用者ごとに IAMユーザーを分けることで、誰が何をしたのか追いやすくなる。

また、IAMユーザーごとに権限を分けられるため、最小権限の原則を適用しやすくなる。

ただし、IAMユーザーにアクセスキーを発行すると、そのアクセスキーは長期認証情報として扱われる。

そのため、アクセスキーをローカルPCやサーバーに置きっぱなしにする運用は避けたい。

IAMロールは一時的に権限を渡すための仕組み

IAMロールは、権限そのものに名前を付けたようなもの。

IAMユーザーのように固定のパスワードやアクセスキーを持つのではなく、必要なときに一時的な認証情報として使われる。

たとえば、EC2 インスタンスに IAMロールを付けると、EC2 上のアプリケーションはアクセスキーをファイルに保存しなくても AWS API を呼び出せる。

これは、アクセスキーを直接配布するよりも安全な設計になる。

IAMロールは、以下のような考え方で理解するとよさそう。

IAMユーザー:
  「誰か」を表す

IAMロール:
  「一時的に使える権限セット」を表す

AWS CLI との関係

AWS CLI を使うときも、自分がどのユーザーやロールとして操作しているのかを意識する必要がある。

現在の認証主体は、以下のコマンドで確認できる。

aws sts get-caller-identity \
  --profile reotech-dev

出力される Arn を見ると、IAMユーザーとして操作しているのか、IAMロールとして操作しているのかを確認できる。

IAMユーザーの場合は、以下のような形式になる。

arn:aws:iam::123456789012:user/example-user

IAMロールを引き受けている場合は、以下のような形式になる。

arn:aws:sts::123456789012:assumed-role/example-role/example-session

AWS CLI で作業する前に、aws sts get-caller-identity で現在の認証主体を確認する習慣をつけると、意図しないアカウントや権限で作業する事故を減らせそう。

あいまいなこと

  • IAMロールを「引き受ける」とは具体的にどういう動きなのか
  • IAMロールと IAMポリシーの違い
  • IAM Identity Center を使うと、IAMユーザーやIAMロールとどのように関係するのか
  • aws login や aws sso login の裏側で、どのIAMロールが使われるのか

次にやること

  • IAMロールを引き受けるとはどういうことか確認する
  • IAMロールと IAMポリシーの違いを整理する
  • IAM Identity Center とは何かを確認する
  • aws login と aws sso login の違いを整理する