AWS Database Blog
Join the preview of attribute-based access control for Amazon DynamoDB
Amazon DynamoDB is a serverless, NoSQL, fully managed database service that delivers single-digit millisecond latency at any scale. AWS recently announced the limited preview of attribute-based access control (ABAC) for Amazon DynamoDB. ABAC is an authorization strategy that defines permissions based on attributes. In AWS, these attributes are called tags. You can attach tags to AWS Identity and Access Management (IAM) entities, such as users and roles, and to AWS resources, such as DynamoDB tables. The tags attached to a table are inherited by the table’s indexes. Instead of creating individual policies for users or groups, or for each table you want to grant access to, you can enhance your security posture by creating policies with tag-based conditions, to evaluate whether a principal’s tag matches the resource tag. ABAC is helpful in environments that are growing rapidly and helps with situations where policy management becomes cumbersome.
DynamoDB supports identity-based, resource-based, and other AWS policies that enable you to define access control for IAM principals, to perform specific actions on resources such as tables and indexes. To manage access control segmentation, you might use multiple conditional statements in your policies to specify different access levels for IAM principals with varying permissions. With new IAM principals being added to the policies regularly, the complexity of permission management within the policies increases and policy management is no longer scalable. Customers have asked for a scalable solution to manage the segmentation of access control with multiple IAM principals and to simplify their regular policy management tasks.
In this post, we will show you how you can now simplify access control for your tables and indexes with ABAC for DynamoDB. With ABAC, you can use tags for authorizing IAM principals in identity-based, resource-based, or other AWS policies. Tags can be used to group users, cost centers, or for any logical grouping of identities and resources, enabling authorization of access to IAM principals with matching tags in the conditional statements of policies. As a result, no policy changes are required to onboard new IAM principals and group them under the same tags in the future.
Benefits of using ABAC with DynamoDB
Using ABAC with DynamoDB offers the following benefits:
- Fewer policies – ABAC requires fewer policies because role differentiation is handled by tags. New or existing IAM principals that share a role to perform actions on DynamoDB tables or indexes automatically inherit permissions authorized by tag-based conditions. This simplifies policy management by requiring fewer policies.
- Automatic permission management – Permissions to DynamoDB tables or indexes are automatically granted based on tags, so you don’t need to update policies to allow access to new tables with the same tags.
- Alignment with corporate directory: You can map tags with existing employee attributes from your corporate directory to align your AWS policies with your organizational structure. By doing so, you can simplify access control for users in a given department or with a common role.
- Monitoring for actions that users have performed – When using ABAC, you can determine which identity is responsible for actions performed using IAM roles. For example, the IAM
SourceIdentityattribute is logged in AWS CloudTrail for every action performed in AWS using an IAM role. With theSourceIdentityattribute set, you can connect the CloudTrail event with the identity of the user or application that performed the action. Even in the case of role chaining, where a user uses one IAM role to assume another IAM role, you can determine which identity performed what actions.
Solution overview
When you create or modify an identity-based policy, resource-based policy, or other policy, you can specify attribute-based conditions using tags. These conditions determine whether IAM principals with matching tags are granted or denied access to a DynamoDB table and index.
In the following sections, we explore some use case examples.
Example 1: Restrict actions with tags
For this example, we have three roles and three separate DynamoDB tables where every table has one global secondary index. Each table is associated with specific project tags: one for the star project, another for the lightning workload, and a third for the drop blue project.
When there is a requirement to provide access to a new resource to the lightning workload, you only need to assign the lightning role to that resource. If you decide to include a new resource like another DynamoDB table in the future, you only have to assign the appropriate tag and the permissions will automatically propagate, thereby simplifying access control.
The following diagram illustrates this configuration.
Imagine you have the following resource-based policy in your lightning DynamoDB tables. This allows access to any user that has the tag environment=Lightning to put and update items in the table:
Example 2: Restrict an action by comparing tags using ResourceTag
Using the aws:ResourceTag/tag-key condition key, you can restrict an operation if a specific tag key-value pair present in an IAM policy isn’t specified on a DynamoDB table.
The following example shows an identity-based policy that allows any user in the account to put items into DynamoDB tables, as long as they are working on the same project:
Example 3: Restrict an action by comparing tags using RequestTag
You can also implement ABAC based on the exclusion of certain tags. For example, you can restrict the creation of new tables if a key-value pair present in an IAM policy is missing in the CreateTable request.
The following IAM policy example uses the aws:RequestTag/tag-key condition key to compare the key-value pair that’s passed in your CreateTable request with the tag pair that’s specified in the IAM policy:
Your request must include the key-value pair of "Owner": "${aws:username}" for the CreateTable request to succeed. For this example, assume that the aws:username value must resolve to Mary. If you send the request with the username value of Mary, the request will succeed. If the username value isn’t Mary, the request will fail.
The following successful example request includes tags that match the condition specified in the preceding IAM policy:
However, if you do not include the requester key-value pair that matches the Owner key-value, the request will fail. The following is an example of a failed CreateTable request, where the Owner has been set as Pat:
Auditing your policies before ABAC enablement
Until your account is enabled for DynamoDB ABAC by AWS, the tag-based conditions in your identity-based or other policies that are intended to act on DynamoDB tables or indexes are evaluated as if no tags are present for your tables or access requests. When DynamoDB ABAC is enabled for your account, the tag-based conditions in the policies of your account will be evaluated considering the tags attached to your tables or access requests.
Before ABAC is enabled for your account, audit your policies to confirm that the tag-based conditions that might exist in the policies within your account are setup as intended. Auditing your policies will help avoid surprises from authorization changes with your applications that connect to DynamoDB after ABAC is enforced. An example of the authorization behavior before and after ABAC is enabled is illustrated below.
Example: Allow an action using aws:RequestTag
Using the aws:RequestTag/tag-key condition key, you can compare the tag key-value pair that’s passed in your request with the tag pair that’s specified in the IAM policy. For example, you can allow a specific action, such as CreateTable, using the aws:RequestTag if the tag conditions don’t match. To do this, perform the following steps:
- Create an inline policy and add it to a role which has the ReadOnlyAccess AWS managed policy attached to it, as shown in the following example
- Create a table that contains the tag key-value pair of
"Owner": "John"
Without ABAC enabled
If ABAC isn’t enabled for your AWS account, the tag conditions in the inline policy and the DynamoDB table are not matched. Consequently, the CreateTable action fails and your table isn’t created.
With ABAC enabled
If ABAC is enabled for your AWS account, your table creation request completes successfully. Because the tag key-value pair of “Owner”: “John” is present in the CreateTable request, the inline policy allows the user John to perform the CreateTable action.
Conclusion
In this post, we showed how you can use ABAC to simplify permission management, segmentation of access control for DynamoDB tables and indexes, and team access as your organization expands. You can implement ABAC using identity-based, resource-based, or other AWS policies with tag-based conditions, authorizing actions based on matching tags between IAM principals and DynamoDB table tags, and simplify your day-to-day policy management.
There is no additional cost to use ABAC for Amazon DynamoDB. As the first step to exploring ABAC for DynamoDB, sign up for the limited preview.
About the authors
Esteban Serna is a Senior DynamoDB Specialist Solutions Architect. Esteban has been working with databases for the last 15 years, helping customers choose the right architecture to match their needs. Fresh from university, he worked deploying the infrastructure required to support contact centers in distributed locations. When NoSQL databases were introduced, he fell in love with them and decided to focus on them because centralized computing was no longer the norm. Today, Esteban focuses on helping customers design distributed massive scale applications that require single digit-millisecond latency using DynamoDB. He is an open book and he loves to share his knowledge with others.
Ashwin Venkatesh is a Senior Product Manager for Amazon DynamoDB at Amazon Web Services, and is based out of Santa Clara, California. With 25+ years in product management and technology roles, Ashwin has a passion for engaging with customers to understand business use cases, defining strategy, working backwards to define new features that deliver long-term customer value, and having deep-dive discussions with technology peers. Outside work, Ashwin enjoys travel, sports and family events.