Lambda 実行ロール
Lambda 関数の実行ロールは、AWS サービスおよびリソースにアクセスする許可を関数に付与する AWS Identity and Access Management (IAM) ロールです。Amazon CloudWatch にログを送信するアクセス許可を持つ実行ロールを作成し、トレースデータを AWS X-Ray にアップロードすることができます。このページでは、Lambda 関数の実行ロールを作成、表示、および管理する方法について説明します。
関数を作成する際に、実行ロールを提供します。関数を呼び出すと、Lambda はこのロールを引き継いで関数に一時的な認証情報を自動的に渡します。関数コードで sts:AssumeRole を呼び出す必要はありません。
Lambda が実行ロールを適切に引き受けるには、ロールの信頼ポリシーが、Lambda サービスプリンシパル (lambda.amazonaws.com) を信頼できるサービスとして指定する必要があります。
関数の実行ロールを表示するには
Lambda コンソールの [Functions]
(関数) ページを開きます。 -
関数の名前を選択します。
-
[Configuration] (設定)、[Permissions] (アクセス許可) の順に選択します。
-
[Resource summary] (リソースの概要) で、関数からアクセスが可能なサービスとリソースを確認します。
-
ドロップダウンリストからサービスを選択すると、そのサービスに関連するアクセス許可が表示されます。
アクセス許可は、関数の実行ロールからいつでも追加または削除できます。または、別のロールを使用するように関数を設定することもできます。AWS SDK で関数を使用して呼び出すサービスや、オプションの機能を有効にするために Lambda で使用するサービス用のアクセス許可を追加します。
関数にアクセス許可を追加する場合は、そのコードまたは設定も更新します。これにより、(古い認証情報により実行中の) 関数のインスタンスが、強制的に停止され置き換えられます。
トピック
IAM コンソールでの実行ロールの作成
デフォルトでは、Lambda コンソールで関数を作成するときに、Lambda により最小限のアクセス許可で実行ロールが作成されます。IAM コンソールで実行ロールを作成することもできます。
IAM コンソールで実行ロールを作成するには
-
IAM コンソールの [Roles (ロール)] ページ
を開きます。 -
[ロールの作成] を選択します。
-
[ユースケース] で、Lambda を選択します。
-
[Next] (次へ) をクリックします。
-
AWS マネージドポリシーである AWSLambdaBasicExecutionRole および AWSXRayDaemonWriteAccess を選択します。
-
[Next] (次へ) をクリックします。
-
[Role name] ボックスに入力し、[Create role] を選択します。
詳しい手順については、IAM ユーザーガイドの AWS サービスのロールの作成 (コンソール) を参照してください。
Lambda 実行ロールへの最小権限アクセスを付与する
デプロイのフェーズで Lambda 関数の IAM ロールを初めて作成するときに、必要な範囲を超えたアクセス許可を付与することがあります。ベストプラクティスとしては、本番環境に関数を公開する前に、ポリシーを調整して必要なアクセス許可のみを含めるようにします。詳細については、「IAM ユーザーガイド」の「最小特権アクセス許可を適用する」を参照してください。
IAM 実行ロールポリシーに必要なアクセス許可を確認するときは、IAM Access Analyzer を使用します。IAM Access Analyzer は、指定した日付範囲で AWS CloudTrail ログを確認し、その期間中に関数が使用したアクセス許可のみを持つポリシーテンプレートを生成します。このテンプレートを使用することで、きめ細かなアクセス許可で管理ポリシーを作成し、それを IAM ロールにアタッチすることができます。これにより、特定のユースケースでロールが AWS リソースとインタラクションするために必要なアクセス許可のみを付与します。
詳細については、「IAM ユーザーガイド」の「アクセスアクティビティに基づいてポリシーを生成する」を参照してください。
IAM API によるロールの管理
AWS Command Line Interface (AWS CLI) を使用して実行ロールを作成するには、create-role コマンドを使用します。このコマンドを使用するときに、信頼ポリシーインラインを指定することもできます。ロールの信頼ポリシーでは、指定したプリンシパルに、ロールを引き受けるための許可を付与します。次の例では、Lambda サービスプリンシパルに自分の役割を引き受けるアクセス権限を付与します。JSON 文字列で引用符をエスケープするための要件は、シェルに応じて異なることに注意してください。
aws iam create-role --role-name lambda-ex --assume-role-policy-document '{"Version": "2012-10-17","Statement": [{ "Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}'
また、個別の JSON ファイルを使用してロールの信頼ポリシーを定義することもできます。次の例では、trust-policy.json は現在のディレクトリにあるファイルです。
例 trust-policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
aws iam create-role --role-name lambda-ex --assume-role-policy-document file://trust-policy.json
以下の出力が表示されます。
{ "Role": { "Path": "/", "RoleName": "lambda-ex", "RoleId": "AROAQFOXMPL6TZ6ITKWND", "Arn": "arn:aws:iam::123456789012:role/lambda-ex", "CreateDate": "2020-01-17T23:19:12Z", "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } } }
関数を呼び出すと、Lambda が自動的に実行ロールを引き受けます。関数コードで sts:AssumeRole を手動で呼び出すことは避けることが推奨されます。ユースケースでロール自体を引き受ける必要がある場合は、ロール自体を信頼できるプリンシパルとしてロールの信頼ポリシーに含める必要があります。詳細については、「IAM ユーザーガイド」の「ロールの信頼ポリシーの変更 (コンソール)」を参照してください。
ロールにアクセス許可を追加するには、attach-policy-to-role コマンドを使用します。AWSLambdaBasicExecutionRole マネージドポリシーを追加して開始します。
aws iam attach-role-policy --role-name lambda-ex --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
一時的なセキュリティ認証情報のセッション期間
Lambda は、関数に関連付けられた実行ロールを引き受け、一時的なセキュリティ認証情報を取得します。この認証情報は、関数の呼び出し時に環境変数として使用できます。事前に署名された Amazon S3 URL を作成する場合など、これらの一時的な認証情報を Lambda の外部で使用する場合、セッション時間を制御することはできません。IAM 最大セッション時間のセッティングは、Lambdaなどの AWS サービスが引き受けるセッションを制限されません。セッション時間をより制御する必要がある場合、sts:AssumeRole アクションを使用します。
Lambda 機能の AWS マネージドポリシー
次の AWS マネージドポリシーは、Lambda の機能を使うために必要なアクセス許可を付与します。
| 変更 | 説明 | 日付 |
|---|---|---|
|
AWSLambdaMSKExecutionRole |
|
2022 年 6 月 17 日 |
|
AWSLambdaBasicExecutionRole |
|
2022 年 2 月 14 日 |
|
AWSLambdaDynamoDBExecutionRole |
|
2022 年 2 月 14 日 |
|
AWSLambdaKinesisExecutionRole |
|
2022 年 2 月 14 日 |
|
AWSLambdaMSKExecutionRole |
|
2022 年 2 月 14 日 |
|
AWSLambdaSQSQueueExecutionRole |
|
2022 年 2 月 14 日 |
|
AWSLambdaVPCAccessExecutionRole |
|
2022 年 2 月 14 日 |
|
AWSXRayDaemonWriteAccess |
|
2022 年 2 月 14 日 |
|
CloudWatchLambdaInsightsExecutionRolePolicy |
|
2022 年 2 月 14 日 |
|
AmazonS3ObjectLambdaExecutionRolePolicy |
|
2022 年 2 月 14 日 |
一部の機能では、Lambda コンソールは、カスタマーマネージドポリシーの実行ロールに対して、不足しているアクセス許可を追加しようとします。これらのポリシーは数が増える可能性があります。余分なポリシーを作成しないように、機能を有効にする前に関連する AWS 管理ポリシーを実行ロールに追加します。
イベントソースマッピングを使用して関数を呼び出すと、Lambda は実行ロールを使用してイベントデータを読み出します。例えば、Kinesis のイベントソースマッピングでは、データストリームからイベントを読み出し、バッチで関数に送信します。
アカウント内でサービスがロールを引き受ける場合は、ロール信頼ポリシーに aws:SourceAccount または aws:SourceArn のグローバル条件コンテキストキーを含めることで、期待するリソースによって生成されたリクエストのみに、ロールのアクセスを制限できます。詳細については、「AWS Security Token Service のサービス間の混乱した代理の防止」を参照してください。
イベントソースマッピングが使用可能なサービスは、次のとおりです。
Lambda がイベントを読み取るサービス
Lambda コンソールには、AWS マネージドポリシーに加えて、追加のユースケース用のアクセス許可を含むカスタムポリシーを作成するためのテンプレートが用意されています。Lambda コンソールで関数を作成する際、1 つ以上のテンプレートのアクセス許可を使用して新しい実行ロールを作成することを選択できます。これらのテンプレートは、設計図から関数を作成する場合、または他のサービスへのアクセスを必要とするオプションを設定する場合にも自動的に適用されます。サンプルテンプレートは、本ガイドの GitHub リポジトリ
Lambda 実行環境での認証情報の使用
一般的に、Lambda 関数のコードは、他の AWS のサービスに対し API リクエストを送信します。これらのリクエストを行うために、Lambda は関数の実行ロールを引き受けることによって、認証情報のセットを一時的に生成します。これらの認証情報は、関数の呼び出し中に環境変数として利用できます。AWS SDK を使用している場合に、コード内で SDK の認証情報を直接提供する必要はありません。デフォルトで、認証情報プロバイダーチェーンは認証情報を設定できる各場所を順番にチェックし、最初に利用できるものを選択します。これは通常、環境変数 (AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、および AWS_SESSION_TOKEN) です。
Lambda は、リクエストが実行環境内から実行される AWS API リクエストである場合、ソース関数 ARN を認証情報コンテキストに挿入します。Lambda は、Lambda がユーザーに代わって実行環境外で実行する以下の AWS API リクエストにも、ソース関数 ARN を挿入します。
| サービス | アクション | 理由 |
|---|---|---|
| CloudWatch Logs | CreateLogGroup, CreateLogStream, PutLogEvents |
CloudWatch Logs ロググループにログを保存する |
| X-Ray | PutTraceSegments |
X-Ray にトレースデータを送信する |
| Amazon EFS | ClientMount |
関数を Amazon Elastic File System (Amazon EFS) ファイルシステムに接続する |
ソース関数 ARN は、Lambda が同じ実行ロールを使用して、実行環境外でユーザーに代わって実行するその他の AWS API 呼び出しには含まれていません。このように、実行環境外で実行される API 呼び出しの例としては、以下が挙げられます。
-
環境変数を自動的に暗号化および復号化するための AWS Key Management Service (AWS KMS) の呼び出し。
-
VPC 対応関数用の Elastic Network Interfaces (ENI) を作成するための Amazon Elastic Compute Cloud (Amazon EC2) の呼び出し。
-
イベントソースマッピングとしてセットアップされたイベントソースから読み込むための、Amazon Simple Queue Service (Amazon SQS) などの AWS サービスの呼び出し。
認証情報コンテキストに挿入されたソース関数 ARN を使用すると、特定の Lambda 関数のコードからリソースへの呼び出しが行われたのかどうかを確認できます。これを確認するには、IAM ID ベースのポリシーまたはサービス コントロール ポリシー (SCP) で lambda:SourceFunctionArn 条件キーを使用します。
リソースベースのポリシーにある lambda:SourceFunctionArn は使用できませんでした。
ID ベースのポリシーまたは SCP でこの条件キーを使用することで、関数コードが他の AWS のサービスに対し実行する、API アクションのためのセキュリティ制御を実装できます。こういったセキュリティアプリケーションには、認証情報の漏洩の原因を特定する場合など、重要なものがいくつか含まれています。
lambda:SourceFunctionArn 条件キーは、lambda:FunctionArn および aws:SourceArn 条件キーとは異なります。lambda:FunctionArn 条件キーは、イベントソースマッピングにのみ適用され、イベントソースから呼び出しが可能な関数を定義するのに使用されます。aws:SourceArn 条件キーは、Lambda 関数がターゲットリソースであるポリシーにのみ適用され、その機能を呼び出すことができる他の AWS サービスとリソースを定義するのに役立ちます。lambda:SourceFunctionArn 条件キーは任意の ID ベースのポリシーまたは SCP に適用して、他のリソースに対して特定の AWS API 呼び出しを行う許可を持つ特定の Lambda 関数を定義します。
ポリシーで lambda:SourceFunctionArn を使用するには、それを、任意の ARN 条件演算子に条件として含めます。キーの値は有効な ARN にする必要があります。
例えば、Lambda 関数のコードが特定の Amazon S3 バケットをターゲットとして、s3:PutObject 呼び出しを実行したとします。これには、Lambda 関数の 1 つだけに、対象のバケットに対する s3:PutObject アクセスを許可する必要があります。この場合、関数の実行ロールには、次のようなポリシーがアタッチされている必要があります。
例 特定の Lambda 関数に Amazon S3 リソースへのアクセスを許可するポリシー
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ExampleSourceFunctionArn", "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::lambda_bucket/*", "Condition": { "ArnEquals": { "lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda" } } } ] }
このポリシーでは、ARN が arn:aws:lambda:us-east-1:123456789012:function:source_lambda である Lambda 関数がソースの場合にのみ、s3:PutObject アクセスを許可します。このポリシーは、他の呼び出し ID に対して s3:PutObject アクセスを許可することはありません。別の関数またはエンティティが、同じ実行ロールを使用し s3:PutObject 呼び出しを行った場合も同様です。
サービスコントロールポリシーで lambda:SourceFunctionArn を使用することもできます。例えば、バケットへのアクセスを、単一の Lambda 関数のコードまたは特定の Amazon Virtual Private Cloud (VPC) からの呼び出しに制限したいとします。以下の SCP は、これを示したものです。
例 特定の条件下で Amazon S3 へのアクセスを拒否するポリシー
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "s3:*" ], "Resource": "arn:aws:s3:::lambda_bucket/*", "Effect": "Deny", "Condition": { "StringNotEqualsIfExists": { "aws:SourceVpc": [ "vpc-12345678" ] }, "ArnNotEqualsIfExists": { "lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda" } } } ] }
このポリシーは、ARN arn:aws:lambda:*:123456789012:function:source_lambda を持つ特定の Lambda 関数からのものでない限り、または指定された VPC からのものでない限り、すべての S3 アクションを拒否します。StringNotEqualsIfExists 演算子は、aws:SourceVpc キー がリクエストに含まれている場合にのみ、IAM に対し、この条件を処理することを指示します。これと同様に、IAM は lambda:SourceFunctionArn が存在する場合にのみ ArnNotEqualsIfExists を認識します。
