AWS Lambda
Developer Guide

Identity-based IAM Policies for AWS Lambda

You can use identity-based policies in AWS Identity and Access Management (IAM) to grant users in your account access to Lambda. Identity-based policies can apply to users directly, or to groups and roles that are associated with a user. You can also grant users in another account permission to assume a role in your account and access your Lambda resources.

Lambda provides managed policies that grant access to Lambda API actions and, in some cases, access to other services used to develop and manage Lambda resources. Lambda updates the managed policies as needed, to ensure that your users have access to new features when they're released.

  • AWSLambdaFullAccess – Grants full access to AWS Lambda actions and other services used to develop and maintain Lambda resources.

  • AWSLambdaReadOnlyAccess – Grants read-only access to AWS Lambda resources.

  • AWSLambdaRole – Grants permissions to invoke Lambda functions.

Managed policies grant permission to API actions without restricting the functions or layers that a user can modify. For finer-grained control, you can create your own policies that limit the scope of a user's permissions.

Function Development

The following shows an example of a permissions policy with limited scope. It allows a user to create and manage Lambda functions named with a designated prefix (intern-), and configured with a designated execution role.

Example Function Development Policy

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ReadOnlyPermissions", "Effect": "Allow", "Action": [ "lambda:GetAccountSettings", "lambda:ListFunctions", "lambda:ListTags", "lambda:GetEventSourceMapping", "lambda:ListEventSourceMappings", "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": { "StringLike": { "lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*" } } }, { "Sid": "PassExecutionRole", "Effect": "Allow", "Action": [ "iam:ListRolePolicies", "iam:ListAttachedRolePolicies", "iam:GetRole", "iam:PassRole" ], "Resource": "arn:aws:iam::*:role/intern-lambda-execution-role" }, { "Sid": "ViewExecutionRolePolicies", "Effect": "Allow", "Action": [ "iam:GetPolicy", "iam:GetPolicyVersion" ], "Resource": "arn:aws:iam::aws:policy/*" }, { "Sid": "ViewLogs", "Effect": "Allow", "Action": [ "logs:*" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*" } ] }

The permissions in the policy are organized into statements based on the resources and conditions that they support.

  • ReadOnlyPermissions – The Lambda console uses these permissions when you browse and view functions. They don't support resource patterns or conditions.

    "Action": [ "lambda:GetAccountSettings", "lambda:ListFunctions", "lambda:ListTags", "lambda:GetEventSourceMapping", "lambda:ListEventSourceMappings", "iam:ListRoles" ], "Resource": "*"
  • DevelopFunctions – Use any Lambda action that operates on functions prefixed with intern-, except AddPermission and PutFunctionConcurrency. AddPermission modifies the resource-based policy on the function and can have security implications. PutFunctionConcurrency reserves scaling capacity for a function and can take capacity away from other functions.

    "NotAction": [ "lambda:AddPermission", "lambda:PutFunctionConcurrency" ], "Resource": "arn:aws:lambda:*:*:function:intern-*"
  • DevelopEventSourceMappings – Manage event source mappings on functions that are prefixed with intern-. These actions operate on event source mappings, but you can restrict them by function with a condition.

    "Action": [ "lambda:DeleteEventSourceMapping", "lambda:UpdateEventSourceMapping", "lambda:CreateEventSourceMapping" ], "Resource": "*", "Condition": { "StringLike": { "lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*" } }
  • PassExecutionRole – View and pass only a role named intern-lambda-execution-role, which must be created and managed by a user with IAM permissions. PassRole is used when you assign an execution role to a function.

    "Action": [ "iam:ListRolePolicies", "iam:ListAttachedRolePolicies", "iam:GetRole", "iam:PassRole" ], "Resource": "arn:aws:iam::*:role/intern-lambda-execution-role"
  • ViewExecutionRolePolicies – View the AWS-provided managed policies that are attached to the execution role. This lets you view the function's permissions in the console, but doesn't include permission to view policies that were created by other users in the account.

    "Action": [ "iam:GetPolicy", "iam:GetPolicyVersion" ], "Resource": "arn:aws:iam::aws:policy/*"
  • ViewLogs – Use CloudWatch Logs to view logs for functions that are prefixed with intern-.

    "Action": [ "logs:*" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*"

This policy allows a user to get started with Lambda, without putting other users' resources at risk. It doesn't allow a user to configure a function to be triggered by or call other AWS services, which requires broader IAM permissions. It also doesn't include permission to services that don't support limited-scope policies, like CloudWatch and X-Ray. Use the read-only policies for these services to give the user access to metrics and trace data.

When you configure triggers for your function, you need access to use the AWS service that invokes your function. For example, to configure an Amazon S3 trigger, you need permission to Amazon S3 actions to manage bucket notifications. Many of these permissions are included in the AWSLambdaFullAccess managed policy. Example policies are available in this guide's GitHub repository.

Layer Development and Use

The following policy grants a user permission to create layers and use them with functions. The resource patterns allow the user to work in any AWS Region and with any layer version, as long as the name of the layer starts with test-.

Example Layer Development Policy

{ "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-*:*" } ] }

You can also enforce layer use during function creation and configuration with the lambda:Layer condition. For example, you can prevent users from using layers published by other accounts. The following policy adds a condition to the CreateFunction and UpdateFunctionConfiguration actions to require that any layers specified come from account 123456789012.

{ "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:*:*" ] } } } ] }

To ensure that the condition applies, verify that no other statements grant the user permission to these actions.

Cross-Account Roles

You can apply any of the preceding policies and statements to a role, which you can then share with another account to give it access to your Lambda resources. Unlike an IAM user, a role doesn't have credentials for authentication. Instead, it has a trust policy that specifies who can assume the role and use its permissions.

You can use cross-account roles to give accounts that you trust access to Lambda actions and resources. If you just want to grant permission to invoke a function or use a layer, use resource-based policies instead.

For more information, see IAM Roles in the IAM User Guide.