Trust Policy
誰がそのRoleを引き受けられるかを定義します。
例えばLambda Execution Roleなら、
Lambda
↓
sts:AssumeRole
↓
IAM Role
となるため、RoleのTrust PolicyではLambda Serviceを信頼します。
Principal
→ lambda.amazonaws.com
Action
→ sts:AssumeRole
重要なのは、RoleへPermissions Policyを追加しただけでは不十分という点です。
Permissions Policy
→ DynamoDBへのAccessをAllow
しかし
Trust Policy
→ LambdaをTrustしていない
結果
→ LambdaはRoleを利用できない
Lambda Execution Roleなら、
Trust Policy
→ lambda.amazonaws.com
Permissions Policy
→ Lambda実行中に必要なAWS Permission
の両方を考えます。
Permissions Policy
Roleを引き受けたあと、そのRoleで何ができるかを定義します。
Lambda
↓
Execution Role
↓
Permissions Policy
↓
DynamoDB PutItem
覚え方は、
Trust Policy
→ 誰がRoleを使える？
Permissions Policy
→ Roleを使ったら何ができる？
です。
AWS STS / AssumeRole
AWS Security Token Service（STS）は、一時的なSecurity Credentialsを発行します。
User / Application
↓
sts:AssumeRole
↓
IAM Role
↓
Temporary Credentials
↓
AWS Resource
取得する一時認証情報には、
AccessKeyId
SecretAccessKey
SessionToken
などが含まれます。
Cross-Account AssumeRole
Cross-Account AssumeRoleでは基本的に、
Account A
呼び出し側Principal
↓
Identity-based Policy
sts:AssumeRoleをAllow
↓
STS
↓
Account B
Role Trust Policy
Account A側PrincipalをTrust
↓
IAM Role
と考えます。
つまり、
呼び出し側
→ sts:AssumeRoleを実行できる
+
引き受けられる側Role
→ 呼び出し側PrincipalをTrustする
の両方を確認します。
External ID
第三者企業などへCross-Account Roleを委任する場合に登場するのがExternal IDです。
自社AWS Account
↓
監視サービス会社へ
Cross-Account Roleを提供
Lambda Execution Role
Lambdaが他のAWS Serviceへアクセスするときに利用するRoleです。
Lambda
↓
Execution Role
├→ DynamoDB
├→ S3
├→ SQS
└→ CloudWatch Logs
例えばLambdaからDynamoDBへ書き込むなら、
Action
→ dynamodb:PutItem
Resource
→ 対象Table
などをExecution Roleへ許可します。
EC2 IAM Role / Instance Profile
EC2からAWS Serviceへアクセスする場合も、Access KeyをEC2へ保存するのではなくIAM Roleを利用します。
EC2
↓
Instance Profile
↓
IAM Role
↓
S3
EC2ではIAM RoleをInstance Profileを通してInstanceへ関連付けます。
AWS SDKなどはEC2のInstance Metadata Service（IMDS） から一時Credentialsを取得できます。
Application
↓
AWS SDK
↓
IMDS
↓
Temporary Credentials
↓
AWS API
IMDSではIMDSv2の利用が推奨されます。
iam:PassRole
例えばDeveloperがLambda Functionを作成するとき、
Developer
↓
Lambda Function作成
↓
Execution Roleを指定
します。
DeveloperがそのRoleをLambdaへ渡すには、
iam:PassRole
が必要です。
PassRoleで渡せるRoleを制限する
例えば、
Action
→ iam:PassRole
Resource
→ *
としてしまうと、強力なRoleをServiceへ渡せる可能性があります。
そのため、
Resource
→ 渡してよいRole ARN
のように対象Roleを限定することが重要です。
さらに、
iam:PassedToService
Condition Keyを利用して、Roleを渡せるServiceを制限できます。
Permissions Boundary
Permissions Boundaryは、IAM UserやRoleが持てるPermissionの最大範囲を制限します。
Identity Policy
→ S3 + DynamoDBをAllow
Permissions Boundary
→ S3のみAllow
なら、
実際に利用できる範囲
→ S3
です。
Explicit Deny
IAMのPermission評価は大まかに、
Default
→ Deny
Allowが存在
→ 許可候補
Explicit Denyが存在
→ Deny
と考えます。
つまり、
Allow
+
Explicit Deny
↓
Deny
です。
Resource-based Policy
Resource側へ直接設定するPolicyがあります。
例えば、
API Gateway
↓
Lambda Resource-based Policy
↓
Lambda
という関係があります。
一方、
Lambda
↓
DynamoDB
でLambda自身がDynamoDBへアクセスするPermissionはExecution Role側です。
Cognito User PoolのToken
User Poolでは代表的に、
ID Token
Access Token
Refresh Token
を扱います。
ID Token
User情報・属性を含みます。
ID Token
→ User情報
→ email / usernameなどのClaim
Access Token
APIなどへのAuthorizationに利用します。
Access Token
→ API Access
→ Scope
Refresh Token
新しいID Token / Access Tokenを取得するために利用します。
Refresh Token
↓
新しいTokenを取得
ID Token / Access Tokenには有効期限があり、Refresh Tokenはより長期間のSession維持に利用します。
API Gateway + Cognito
Web ApplicationからAPI Gatewayへアクセスする場合、
User
↓
Cognito User Pool
↓
JWT
↓
API Gateway
↓
Lambda
という構成を作れます。
API Gatewayでは、
REST API
→ Cognito User Pool Authorizer
HTTP API
→ JWT Authorizer
という形で利用できます。
Cognito Identity Pool
Identity PoolはUserへAWSの一時認証情報を提供するために利用します。
User
↓
Identity Pool
↓
Temporary AWS Credentials
↓
IAM Role
↓
S3 / DynamoDB
ここがUser Poolとの最大の違いです。
User Pool
→ Userを認証してTokenを発行
Identity Pool
→ AWS Temporary Credentialsを取得
です。
Identity Pool自体はUser Directoryではありません。
Authenticated / Guest
Identity Poolでは、
Authenticated Identity
→ 認証済みUser用Role
Unauthenticated Identity
→ Guest User用Role
のようにRoleを分けることができます。
例えば、
Login済みUser
→ Upload可能
Guest User
→ Read Only
といった制御ができます。
外部Identity Provider
Identity PoolではUser Poolだけでなく、外部Identity Providerと連携する構成もあります。
例えば、
Cognito User Pool
Google
Facebook
SAML
OIDC
などです。
Identity PoolはこれらのIdentityをAWSのTemporary Credentialsへ橋渡しします。
User Pool + Identity Pool
両方を組み合わせることもできます。
User
↓
Cognito User Pool
↓
Sign In
↓
JWT
↓
Cognito Identity Pool
↓
IAM Role
↓
Temporary AWS Credentials
↓
S3
例えば、
UserをLogin
↓
認証済みUserへ一時AWS Credentials
↓
ClientからS3へ直接Upload
という構成を作れます。
Identity Poolで利用するIAM Roleでは、Trust Policyも重要です。
概念的には、
Principal
→ cognito-identity.amazonaws.com
を信頼し、Identity Pool IDなどをConditionで制限します。
cognito-identity.amazonaws.com:aud
→ 対象Identity Poolを制限
といった形です。
User Pool vs Identity Pool
| 機能 | User Pool | Identity Pool |
|---|---|---|
| 主目的 | User認証 | AWS Credentials取得 |
| Sign Up / Sign In | ○ | ×（主目的ではない） |
| User Directory | ○ | × |
| ID Token / Access Token | JWTを発行 | 発行元ではない |
| API認証・認可用Token | ○ | 主目的ではない |
| IAM Roleとの連携 | 主目的ではない | ○ |
| Temporary AWS Credentials | × | ○ |
| Guest Access | 主目的ではない | ○ |
| S3へ直接Access | JWTだけでは不可 | ○（IAM Role経由） |
Presigned URL
Client
↓
Application Server
↓
Presigned URL発行
↓
Client
↓
S3
一時的な特定操作を許可するのに向いています。
Identity Pool
User
↓
Cognito
↓
Temporary AWS Credentials
↓
IAM Role
↓
S3
AWS Credentialsを取得して、許可されたAWS APIを利用します。
特定Objectへ一時Access
→ Presigned URL
Userへ一時AWS Credentials
→ Cognito Identity Pool
と区別します。
CognitoとSTS
Identity PoolからAWS Resourceへアクセスする場合、一時CredentialsとIAM Roleが関係します。
概念的には、
User
↓
Identity Provider
↓
Identity Pool
↓
STS
↓
Temporary Credentials
↓
IAM Role
↓
AWS Resource
となります。