AWS Compute Blog
Scaling AWS Lambda permissions with Attribute-Based Access Control (ABAC)
This blog post is written by Chris McPeek, Principal Solutions Architect.
AWS Lambda now supports attribute-based access control (ABAC), allowing you to control access to Lambda functions within AWS Identity and Access Management (IAM) using tags. With ABAC, you can scale an access control strategy by setting granular permissions with tags without requiring permissions updates for every new user or resource as your organization scales.
This blog post shows how to use tags for conditional access to Lambda resources. You can control access to Lambda resources using ABAC by using one or more tags within IAM policy conditions. This can help you scale permissions in rapidly growing environments. To learn more about ABAC, see What is ABAC for AWS, and AWS Services that work with IAM.
Each tag in AWS is a label comprising a user-defined key and value. Customers often use tags with Lambda functions to define keys such as cost center, environment, project, and teams, along with values that map to these keys. This helps with discovery and cost allocation, especially in accounts that may have many Lambda functions. AWS best practices for tagging are included in Tagging AWS resources.
You can now use these same tags, or create new ones, and use them to grant conditional IAM access to Lambda functions more easily. As projects start and finish, employees move to different teams, and applications grow, maintaining access to resources can become cumbersome. ABAC helps developers and security administrators work together to maintain least privilege access to their resources more effectively by using the same tags on IAM roles and Lambda functions. Security administrators can allow or deny access to Lambda API actions when the IAM role tags match the tags on a Lambda function, ensuring least privilege. As developers add additional Lambda functions to the project, they simply apply the same tag when they create a new Lambda function, which grants the same security credentials.
ABAC in Lambda
Using ABAC with Lambda is similar to developing ABAC policies when working with other services. To illustrate how to use ABAC with Lambda, consider a scenario where two new developers join existing projects called Project Falcon and Project Eagle. Project Falcon uses ABAC for authorization using the tag key project-name and value falcon. Project Eagle uses the tag key project-name and value eagle.
Projects Falcon and Eagle tags
The two new developers need access to the Lambda console. The security administrator creates the following policy to allow the developers to list the existing functions that are available using ListFunction. The GetAccountSettings permission allows them to retrieve Lambda-specific information about their account.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllResourcesLambdaNoTags",
"Effect": "Allow",
"Action": [
"lambda:ListFunctions",
"lambda:GetAccountSettings"
],
"Resource": "*"
}
]
}
Condition key mappings
The developers then need access to Lambda actions that are part of their projects. The Lambda actions are API calls such as InvokeFunction or PutFunctionConcurrency (see the following table). IAM condition keys are then used to refine the conditions under which an IAM policy statement applies.
Lambda supports the existing global context key:
"aws:PrincipalTag/${TagKey}": Control what the IAM principal (the person making the request) is allowed to do based on the tags that are attached to their IAM user or role.
As part of ABAC support, Lambda now supports three additional condition keys:
"aws:ResourceTag/${TagKey}": Control access based on the tags that are attached to Lambda functions."aws:RequestTag/${TagKey}": Require tags to be present in a request, such as when creating a new function."aws:TagKeys": Control whether specific tag keys can be used in a request.
For more details on these condition context keys, see AWS global condition context keys.
When using condition keys in IAM policies, each Lambda API action supports different tagging condition keys. The following table maps each condition key to its Lambda actions.
| Condition keys supported | Description | Lambda actions |
aws:ResourceTag/${TagKey} |
Set this tag value to allow or deny user actions on resources with specific tags. |
|
aws:ResourceTag/${TagKey}aws:TagKeys |
Set this tag value to allow or deny user requests to create a Lambda function. | lambda:CreateFunction |
aws:ResourceTag/${TagKey}aws:TagKeys |
Set this tag value to allow or deny user requests to add or update tags. | lambda:TagResource |
aws:ResourceTag/${TagKey} |
Set this tag value to allow or deny user requests to remove tags. | lambda:UntagResource |
Security administrators create conditions that only permit the action if the tag matches between the role and the Lambda function.
In this example, the policy grants access to all Lambda function API calls when a project-name tag exists and matches on both the developer’s IAM role and the Lambda function.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllActionsLambdaSameProject",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction",
"lambda:UpdateFunctionConfiguration",
"lambda:CreateAlias",
"lambda:DeleteAlias",
"lambda:DeleteFunction",
"lambda:DeleteFunctionConcurrency",
"lambda:GetAlias",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:GetPolicy",
"lambda:ListAliases",
"lambda:ListVersionsByFunction",
"lambda:PublishVersion",
"lambda:PutFunctionConcurrency",
"lambda:UpdateAlias",
"lambda:UpdateFunctionCode"
],
"Resource": "arn:aws:lambda:*:*:function:*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/project-name": "${aws:PrincipalTag/project-name}"
}
}
}
]
}
In this policy, Resource is wild-carded as "*" for all Lambda functions. The condition limits access to only resources that have the same project-name key and value, without having to list each individual Amazon Resource Name (ARN).
The security administrator creates an IAM role for each developer’s project, such as falcon-developer-role or eagle-developer-role. Since the policy references both the function tags and the IAM role tags, she can reuse the previous policy and apply it to both of the project roles. Each role should have the tag key project-name with the value set to the project, such as falcon or eagle. The following shows the tags for Project Falcon:
Tags for Project Falcon
The developers now have access to the existing Lambda functions in their respective projects. The developer for Project Falcon needs to create additional Lambda functions for only their project. Since the project-name tag also authorizes who can access the function, the developer should not be able to create a function without the correct tags. To enforce this, the security administrator applies a new policy to the developer’s role using the RequestTag condition key to specify that a project-name tag exists:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowLambdaTagOnCreate",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
“lambda:TagResource"
]
"Resource": "arn:aws:lambda:*:*:function:*",
"Condition": {
"StringEquals": {,
“aws:RequestTag/project-name": “${aws:PrincipalTag/project-name}"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"project-name"
]
}
}
}
]
}To create the functions, the developer must add the key project-name and value falcon to the tags. Without the tag, the developer cannot create the function.
Project Falcon tags
Because Project Falcon is using ABAC, by tagging the Lambda functions during creation, they did not need to engage the security administrator to add additional ARNs to the IAM policy. This provides flexibility to the developers to support their projects. This also helps scale the security administrators’ function by no longer needing to coordinate which resources need to be added to IAM policies to maintain least privilege access.
The project must then add a manager who requires read access to projects as long as they are also in the organization labeled birds and cost-center : it.
Organization and Cost Center tags
The security administrator creates a new IAM policy called manager-policy with the following statements:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllActionsLambdaManager",
"Effect": "Allow",
"Action": [
"lambda:GetAlias",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:GetPolicy",
"lambda:GetPolicy",
"lambda:ListAliases",
"lambda:ListVersionsByFunction"
],
"Resource": "arn:aws:lambda:*:*:function:*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/organization": "${aws:PrincipalTag/organization}",
"aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
}
}
}
]
}
The security administrator attaches the policy to the manager’s role along with the tag organization:birds, and cost-center:it. If any of the projects change organization, the manager no longer has access, even if the cost-center remains IT.
In this policy, the condition ensures both the cost-center and organization tags exist for the function and the values are equal to the tags in the manager’s role. Even if the cost-center tag matches for both the Lambda function and the manager’s role, yet the manager’s organization tag doesn’t match, IAM denies access to the Lambda function. Tags themselves are only a key:value pair with no relationship to other tags. You can use multiple tags, as in this example, to more granularly define Lambda function permissions.
Conclusion
You can now use attribute-based access control (ABAC) with Lambda to control access to functions using tags. This allows you to scale your access controls by simplifying the management of permissions while still maintaining least privilege security best practices. Security administrators can coordinate with developers on a tagging strategy and create IAM policies with ABAC condition keys. This then gives freedom to developers to grow their applications by adding tags to functions, without needing a security administrator to update individual IAM policies.
Attribute-based Access Control (ABAC) for Lambda functions support is also available through many AWS Lambda Partners such as Lumigo, Pulumi and Vertical Relevance.
For additional documentation on ABAC with Lambda see Attribute-based access control for Lambda.