# Lambda のアイデンティティベースの IAM ポリシー
Lambda へのアクセス権をアカウントのユーザーに付与するには、AWS Identity and Access Management (IAM) のアイデンティティベースのポリシーを使用します。アイデンティティベースのポリシーは、ユーザー、ユーザーグループ、またはロールに適用できます。または、アカウントのロールを引き受け、Lambda リソースにアクセスするためのアクセス許可を、別のアカウントのユーザーに付与することもできます。
Lambda は、Lambda API アクションへのアクセスを許可し、場合によっては、Lambda リソースの開発と管理に使用される他の AWS サービスへのアクセスを許可する、AWS マネージドポリシーを提供します。Lambda は、新機能がリリースされたときにユーザーがそれらにアクセスできるよう、これらのマネージドポリシーを必要に応じて更新します。
+ [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) - Lambda リソースの開発および維持に使用する Lambda アクションおよびその他の AWS サービスへのフルアクセス権を付与します。
+ [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) - Lambda リソースへの読み取り専用のアクセス権を付与します。
+ [AWSLambdaRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html) - Lambda 関数を呼び出すアクセス許可を付与します。
AWS マネージドポリシーでは、ユーザーが変更できる Lambda 関数やレイヤーを制限することなく、API アクションへのアクセス許可を付与します。きめ細かな制御では、ユーザーのアクセス許可の範囲を制限する独自のポリシーを作成することができます。
**Topics**
+ [Lambda 関数へのアクセス権をユーザーに付与する](permissions-user-function.md)
+ [Lambda レイヤーへのアクセス権をユーザーに付与する](permissions-user-layer.md)
# Lambda 関数へのアクセス権をユーザーに付与する
[アイデンティティベースのポリシー](access-control-identity-based.md)を使用して、ユーザー、ユーザーグループ、またはロールが Lambda 関数でオペレーションを実行できるようにします。
**注記**
コンテナイメージとして定義された関数の場合、イメージにアクセスするためのユーザーのアクセス許可は、Amazon Elastic Container Registry (Amazon ECR) で設定する必要があります。例については、「[Amazon ECR リポジトリポリシー](images-create.md#configuration-images-permissions)」を参照してください。
範囲を制限したアクセス許可ポリシーの例を以下に示します。このポリシーにより、ユーザーは、指定されたプレフィックス (`intern-`) が名前に付き、指定された実行ロールで設定されている Lambda 関数を作成および管理することができます。
**Example 関数の開発ポリシー**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ReadOnlyPermissions",
"Effect": "Allow",
"Action": [
"lambda:GetAccountSettings",
"lambda:GetEventSourceMapping",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:GetFunctionCodeSigningConfig",
"lambda:GetFunctionConcurrency",
"lambda:ListEventSourceMappings",
"lambda:ListFunctions",
"lambda:ListTags",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Sid": "DevelopFunctions",
"Effect": "Allow",
"NotAction": [
"lambda:AddPermission",
"lambda:PutFunctionConcurrency"
],
"Resource": "arn:aws:lambda:*:*:function:intern-*"
},
{
"Sid": "DevelopEventSourceMappings",
"Effect": "Allow",
"Action": [
"lambda:DeleteEventSourceMapping",
"lambda:UpdateEventSourceMapping",
"lambda:CreateEventSourceMapping"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*"
}
}
},
{
"Sid": "PassExecutionRole",
"Effect": "Allow",
"Action": [
"iam:ListRolePolicies",
"iam:ListAttachedRolePolicies",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:PassRole",
"iam:SimulatePrincipalPolicy"
],
"Resource": "arn:aws:iam::*:role/intern-lambda-execution-role"
},
{
"Sid": "ViewLogs",
"Effect": "Allow",
"Action": [
"logs:*"
],
"Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*"
}
]
}
```
ポリシーのアクセス許可は、アクセス許可でサポートされている[リソースおよび条件](lambda-api-permissions-ref.md)に基づき、ステートメントに整理されます。
+ `ReadOnlyPermissions` - Lambda コンソールでは、関数を参照および表示する場合に次のアクセス許可を使用します。リソースパターンや条件はサポートされていません。
```
"Action": [
"lambda:GetAccountSettings",
"lambda:GetEventSourceMapping",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:GetFunctionCodeSigningConfig",
"lambda:GetFunctionConcurrency",
"lambda:ListEventSourceMappings",
"lambda:ListFunctions",
"lambda:ListTags",
"iam:ListRoles"
],
"Resource": "*"
```
+ `DevelopFunctions` — プレフィックス `intern-` が付いた関数で動作する Lambda アクションを使用します (`AddPermission` および `PutFunctionConcurrency` は除く)。`AddPermission` では、関数の[リソースベースのポリシー](access-control-resource-based.md)が変更されるため、セキュリティへの影響が生じる可能性があります。`PutFunctionConcurrency` では、関数のスケーリングキャパシティーを予約するため、他の関数にキャパシティーが奪われる可能性があります。
```
"NotAction": [
"lambda:AddPermission",
"lambda:PutFunctionConcurrency"
],
"Resource": "arn:aws:lambda:*:*:function:intern-*"
```
+ `DevelopEventSourceMappings` プレフィックス が付いた関数のイベントソースマッピングを管理します。`intern-`これらのアクションは、イベントソースマッピング上で動作しますが、*条件*を指定した関数を使用して制限することができます。
```
"Action": [
"lambda:DeleteEventSourceMapping",
"lambda:UpdateEventSourceMapping",
"lambda:CreateEventSourceMapping"
],
"Resource": "*",
"Condition": {
"StringLike": {
"lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*"
}
}
```
+ `PassExecutionRole` - `intern-lambda-execution-role` という名前のロールのみ表示して渡します。このロールは、ユーザーが IAM アクセス許可を使用して作成および管理する必要があります。`PassRole` は、実行ロールを関数に割り当てる際に使用します。
```
"Action": [
"iam:ListRolePolicies",
"iam:ListAttachedRolePolicies",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:PassRole",
"iam:SimulatePrincipalPolicy"
],
"Resource": "arn:aws:iam::*:role/intern-lambda-execution-role"
```
+ `ViewLogs` - CloudWatch Logs を使用して、プレフィックス `intern-` が付いた関数のログを表示します。
```
"Action": [
"logs:*"
],
"Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*"
```
このポリシーでは、他のユーザーのリソースをリスクにさらすことなく、Lambda の使用を開始することができます。これは、ユーザーが関数を他の AWS のサービスによってトリガーされる、またはそれらのサービスを呼び出すように設定できないようにします。これには、より広範は IAM 許可が必要です。また、範囲が制限されたポリシーをサポートしていないサービス (CloudWatch や X-Ray など) のアクセス許可は含まれません。メトリクスおよびトレースデータへのアクセス権をユーザーに付与するには、このようなサービスの読み取り専用ポリシーを使用します。
関数のトリガーを設定する場合は、関数を呼び出す AWS のサービスを使用するためのアクセス権が必要です。例えば、Amazon S3 トリガーを設定するには、バケット通知を管理する Amazon S3 アクションを使用するアクセス許可が必要です。このようなアクセス許可の多くは、[AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) 管理ポリシーに含まれています。
# Lambda レイヤーへのアクセス権をユーザーに付与する
[アイデンティティベースのポリシー](access-control-identity-based.md)を使用して、ユーザー、ユーザーグループ、またはロールが Lambda レイヤーでオペレーションを実行できるようにします。次のポリシーでは、レイヤーを作成し、それらを関数と共に使用するためのユーザーアクセス許可を付与します。リソースパターンでは、レイヤーの名前が `test-` で開始している限り、ユーザーは、すべての AWS リージョン ですべてのレイヤーバージョンを使用できます。
**Example レイヤーの開発ポリシー**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PublishLayers",
"Effect": "Allow",
"Action": [
"lambda:PublishLayerVersion"
],
"Resource": "arn:aws:lambda:*:*:layer:test-*"
},
{
"Sid": "ManageLayerVersions",
"Effect": "Allow",
"Action": [
"lambda:GetLayerVersion",
"lambda:DeleteLayerVersion"
],
"Resource": "arn:aws:lambda:*:*:layer:test-*:*"
}
]
}
```
また、関数作成時のレイヤーの使用や、`lambda:Layer` 条件を指定した設定を強制することもできます。たとえば、ユーザーが、他のアカウントによって発行されたレイヤーを使用できないようにすることもできます。次のポリシーでは、指定されたすべてのレイヤーをアカウント `CreateFunction` で作成することを求める条件を `UpdateFunctionConfiguration` および `123456789012` に追加します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ConfigureFunctions",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"lambda:UpdateFunctionConfiguration"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringLike": {
"lambda:Layer": [
"arn:aws:lambda:*:123456789012:layer:*:*"
]
}
}
}
]
}
```
------
条件が適用されるように、他のステートメントによって、これらのアクションに対するアクセス許可がユーザーに付与されていないことを確認します。