Working with resource-based policies in Lambda
With resource-based permissions policies, you can grant other AWS accounts, users, organizations, and AWS services access to your Lambda functions. A resource-based policy is a JSON document that contains one or more statements. Each statement defines the following:
-
Principal: The entity you want to grant permissions to (another AWS service, an IAM role or user, or another AWS account) -
Action: A list of the API actions you want to allow or deny for the specified principal -
Effect: Whether you want to allow or deny the principal the ability to use the chosen API actions -
Resource: The Lambda function, version, or alias you want the statement to apply to (you can also use a wildcard character to specify all of your function's versions and aliases)
You can also use optional elements such as Sid (a statement identifier) and Condition (logical conditions for fine-grained access control).
For a full list of supported policy elements, refer to
IAM JSON policy element reference in the
AWS Identity and Access Management User Guide.
Adding resource-based permissions to a Lambda function
You can add resource-based permissions to your Lambda function using two methods:
-
Full JSON policy – Use the Lambda console, AWS CLI, or the PutResourcePolicy API action to add a complete JSON policy document. With a full JSON policy, you can use the complete range of IAM global condition keys, add multiple statements with multiple principals, and create explicit
Denystatements. The maximum size for a JSON resource-based policy is 20 KB. -
Individual permissions – Use the console or AddPermission API action to add single
Allowstatements. Individual permissions support only a limited set of condition keys (aws:SourceArn,aws:SourceAccount, andaws:PrincipalOrgID).
We recommend that you define complete JSON policies to add resource-based permissions to your function. Creating a complete JSON policy gives you more flexibility and fine-grained control over your permissions.
Important
Using put-resource-policy replaces any existing resource-based policy on the resource. If the resource
already has permissions defined with add-permission, put-resource-policy overwrites them.
Use get-resource-policy to retrieve the existing policy before making changes.
Required permissions
To use the PutResourcePolicy, GetResourcePolicy, and DeleteResourcePolicy API actions,
you need the following IAM permissions:
| API action | Required permissions |
|---|---|
| PutResourcePolicy | lambda:PutResourcePolicy, lambda:AddPermission, and lambda:RemovePermission |
| GetResourcePolicy | lambda:GetResourcePolicy and lambda:GetPolicy |
| DeleteResourcePolicy | lambda:DeleteResourcePolicy and lambda:RemovePermission |
Viewing a function's resource-based policy
Deleting a function's resource-based policy
Updating existing policies
When you update a function's existing resource-based permissions, the behavior depends on the method you use:
-
put-resource-policy/ PutResourcePolicy – Replaces the entire existing policy. Any previously added individual permissions are overwritten. -
add-permission/ AddPermission – Adds a statement to the existing policy without overwriting. If you calladd-permissionafterput-resource-policy, the new statement appends to the existing JSON policy.
To avoid unintentionally overwriting existing permissions when using put-resource-policy, retrieve your function's existing policy first.
The get-resource-policy output includes a RevisionId field.
aws lambda get-resource-policy --resource-arn arn:aws:lambda:us-east-2:123456789012:function:my-function
When you attach a new policy, provide the RevisionId value with the --revision-id parameter to ensure that you are updating the latest version.
If you provide an older revision ID, Lambda does not update your function's policy.
aws lambda put-resource-policy \ --resource-arn arn:aws:lambda:us-east-2:123456789012:function:my-function\ --policy file://policy.json \ --revision-ida1b2c3d4-5678-90ab-cdef-EXAMPLE11111
Note
Existing resource-based policies created with AddPermission continue to work without modification.
No changes to your function code are required to use the new PutResourcePolicy API.
Security best practices
With JSON resource-based policies, you can follow least-privilege access patterns. You can also meet regulatory requirements for explicit denials. With full JSON policies, you can:
-
Create explicit
Denystatements to block specific principals or conditions. -
Use organizational conditions (
aws:PrincipalOrgID,aws:PrincipalOrgPaths) to restrict access to your Organizations without enumerating individual accounts. -
Scope permissions to specific source accounts or ARNs using the full range of IAM global condition keys.
Example resource-based policies
Example Granting permission to Amazon S3 with a deny statement
The following policy grants all Amazon S3 buckets in an account permission to invoke a function, except for one bucket that is explicitly denied.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "allow-s3", "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-2:111122223333:function:my-function", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" } } }, { "Sid": "deny-s3-bucket", "Effect": "Deny", "Principal": { "Service": "s3.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": [ "arn:aws:lambda:us-east-2:111122223333:function:my-function", "arn:aws:lambda:us-east-2:111122223333:function:my-function:*" ], "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket" } } } ] }
Example Granting permission to accounts in an organization
The following policy grants invoke access to all AWS accounts in an organization.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "org-access", "Effect": "Allow", "Action": "lambda:InvokeFunction", "Principal": "*", "Resource": "arn:aws:lambda:us-east-2:111122223333:function:my-function", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-a1b2c3d4e5f" } } } ] }
Example Granting permission to multiple IAM roles with conditions
The following policy grants permission to two IAM roles to use the CreateAlias action from a specified IP address.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "allow-roles", "Effect": "Allow", "Action": "lambda:CreateAlias", "Principal": { "AWS": [ "arn:aws:iam::444455556666:role/role-name", "arn:aws:iam::444455556666:role/role-name2" ] }, "Resource": "arn:aws:lambda:us-east-2:111122223333:function:my-function", "Condition": { "IpAddress": { "aws:SourceIp": "192.0.2.0" } } } ] }
Example Denying access unless the caller is part of a specified organization
{ "Version": "2012-10-17", "Statement": [ { "Sid": "deny-access", "Effect": "Deny", "Action": "lambda:InvokeFunction", "Principal": "*", "Resource": "arn:aws:lambda:us-east-2:111122223333:function:my-function", "Condition": { "ForAllValues:StringNotLike": { "aws:PrincipalOrgPaths": [ "o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/*" ] } } }, { "Sid": "allow-access", "Effect": "Allow", "Action": "lambda:InvokeFunction", "Principal": "*", "Resource": "arn:aws:lambda:us-east-2:111122223333:function:my-function", "Condition": { "ForAnyValue:StringLike": { "aws:PrincipalOrgPaths": [ "o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/*" ] } } } ] }
Supported API actions
The following Lambda API actions support resource-based policies:
-
InvokeFunctionUrl (permission only)