Principal に指定できる値の種類を整理する

今日やったこと

IAMポリシーにおける Principal の意味を確認した
Principal に指定できる値の種類を整理した
AWSアカウント、IAMユーザー、IAMロール、AWSサービスを指定する例を確認した
arn:aws:iam::123456789012:root が、rootユーザーだけを表すわけではないことを確認した
Principal では、ARNの一部分にワイルドカードを使えないことを確認した

学んだこと

Principalとは

Principal は、ポリシーによってアクセスを許可または拒否する対象の主体を表す。

ざっくり言うと、以下の「誰が」に当たる部分。

誰が
どの操作を
どのリソースに対して実行できるか

IAMロールの信頼ポリシーでは、Principal に「誰がこのロールを引き受けてよいか」を指定する。

なお、IAMユーザーやIAMロールに直接アタッチする権限ポリシーでは、ポリシーの対象がアタッチ先で決まるため、通常は Principal を記述しない。

AWSサービスを指定する

EC2やLambdaなどのAWSサービスを指定する場合は、Service を使用する。

{
  "Principal": {
    "Service": "ec2.amazonaws.com"
  }
}

この例では、EC2サービスをPrincipalとして指定している。

IAMロールの信頼ポリシーで使用すると、EC2がそのロールを引き受けられるようになる。

Lambdaの場合は、次のように指定する。

{
  "Principal": {
    "Service": "lambda.amazonaws.com"
  }
}

AWSアカウントを指定する

AWSアカウント全体を指定する場合は、次のように記述できる。

{
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:root"
  }
}

または、AWSアカウントIDだけでも指定できる。

{
  "Principal": {
    "AWS": "123456789012"
  }
}

この2つは、指定したAWSアカウントへ権限を委譲する。

ここで指定している root は、rootユーザーだけを意味するわけではない。

arn:aws:iam::123456789012:root

を Principal に指定した場合、指定したAWSアカウント全体を信頼するという意味になる。

ただし、別アカウントを信頼ポリシーに書いただけで、そのアカウント内の全ユーザーがすぐにロールを引き受けられるわけではない。

信頼された側のアカウントでも、IAMユーザーやIAMロールに sts:AssumeRole の権限を付与する必要がある。

特定のIAMユーザーを指定する

特定のIAMユーザーを指定する場合は、ユーザーのARNを使用する。

{
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:user/reotech"
  }
}

この例では、reotech というIAMユーザーをPrincipalとして指定している。

特定のIAMロールを指定する

特定のIAMロールをPrincipalとして指定することもできる。

{
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:role/example-role"
  }
}

この例では、example-role をPrincipalとして指定している。

ロールから別のロールを引き受ける構成や、クロスアカウントアクセスなどで使用される。

フェデレーション主体を指定する

外部の認証基盤と連携する場合は、Federated を使用する。

{
  "Principal": {
    "Federated": "arn:aws:iam::123456789012:saml-provider/example-provider"
  }
}

SAMLプロバイダーやOIDCプロバイダーなど、AWS外部の認証基盤を通じてAWSへアクセスする場合に使われる。

すべてのPrincipalを指定する

次のように * を指定すると、すべてのPrincipalを対象にできる。

{
  "Principal": "*"
}

リソースベースポリシーで使用すると、不特定の主体にアクセスを許可する可能性がある。

たとえば、S3バケットポリシーなどで安易に使用すると、リソースが外部へ公開される原因になるため注意が必要。

Principalの一部にワイルドカードは使えない

次のように、PrincipalのARNの一部分だけをワイルドカードにすることはできない。

{
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:role/dev-*"
  }
}

複数のPrincipalを条件でまとめたい場合は、Principal を広く指定したうえで、Condition と aws:PrincipalArn などを組み合わせる方法を検討する。

複数のPrincipalを指定する

複数のPrincipalを指定する場合は、配列で記述できる。

{
  "Principal": {
    "AWS": [
      "arn:aws:iam::123456789012:role/application-role",
      "arn:aws:iam::123456789012:role/operation-role"
    ]
  }
}

Principalの主な種類

種類	キー	例
AWSアカウント	`AWS`	`arn:aws:iam::123456789012:root`
IAMユーザー	`AWS`	`arn:aws:iam::123456789012:user/reotech`
IAMロール	`AWS`	`arn:aws:iam::123456789012:role/example-role`
AWSサービス	`Service`	`ec2.amazonaws.com`
フェデレーション	`Federated`	SAML・OIDCプロバイダーのARN
すべての主体	`*`	`"Principal": "*"`

IAMポリシーを読むときは、Principal を見て次の点を確認する。

- 特定のAWSサービスが指定されているか
- 特定のアカウント全体が指定されているか
- IAMユーザーやIAMロールまで限定されているか
- すべてのPrincipalを表す * が使われていないか
- 必要に応じてConditionで対象が絞られているか

まとめ

Principal は、ポリシーの対象となる「誰が」を表す要素。

IAMロールの信頼ポリシーでは、誰がそのロールを引き受けられるかを定義する。

Service:
  EC2やLambdaなどのAWSサービス

AWS:
  AWSアカウント、IAMユーザー、IAMロール

Federated:
  SAMLやOIDCなどの外部認証主体

*:
  すべてのPrincipal

特に次の2点に注意したい。

arn:aws:iam::123456789012:root:
  rootユーザーだけではなく、指定したAWSアカウントを表す

Principalのワイルドカード:
  ARNの一部分だけを * で一致させることはできない

信頼ポリシーを読むときは、まず Principal を確認して「誰を信頼しているロールなのか」を把握すると理解しやすい。

あいまいなこと

Federated とIAM Identity Centerの具体的な関係
ロールセッションをPrincipalとして指定するケース
Principal と aws:PrincipalArn の使い分け
Principal を広く指定して Condition で絞り込む設計

次にやること

信頼ポリシーの Condition について整理する
aws:PrincipalArn の使い方を確認する
aws:SourceArn と aws:SourceAccount の役割を整理する
IAM Identity Centerとは何かを確認する