Automate user-level custom permissions for Amazon Quick

extract

Artificial Intelligence Automate user-level custom permissions for Amazon Quick As Amazon Quick environments scale and new AI-powered capabilities expand what users can do, automating user-level custom permissions becomes critical to maintaining the principle of least privilege. To address this, with custom permissions in Quick, you can enforce fine-grained access control by toggling specific features on or off for individual users. For example, with custom permissions, you can control access so that financial analysts author reports without exporting raw data, and external partners view dashboards without accessing sharing controls. While Quick provides various options to apply custom permissions at the account, role, and user level, there are scenarios where your organization’s specific permissions need to be applied dynamically. This post walks through four architectural patterns to automate custom permissions assignment at key stages of the user lifecycle. The approaches range from a single API parameter to an event-driven automation, covering new users, future users, group-based logic, and retroactive bulk updates. What we will cover We will explore four scenarios to handle key stages of the user lifecycle: - Pre-registered users: If you build custom portals or scripts, we show how to apply custom permissions proactively at the exact moment of user creation using the RegisterUser API. - Default account or role permissions: To set default custom permissions at the account or role level, we cover how to use the UpdateAccountCustomPermission andUpdateRoleCustomPermission APIs to enforce a default profile for all existing and future users, no additional automation required. - Event-driven custom logic: When you need conditional logic beyond native defaults (such as applying different profiles based on group membership) we show how to use Amazon EventBridge and AWS Lambda to automatically detect new group memberships and apply permissions dynamically. This supports both native Quick groups and AWS IAM Identity Center (IDC) groups. - Retroactive batch updates: For existing users who were provisioned before automation was in place, we provide a robust Python script to retroactively apply custom permissions to all users in specified Quick groups. Scenario 1: Pre-registered users (API and CLI) If you have a custom onboarding portal that provisions users using the RegisterUser API, you don’t need complex automation. You can apply custom permissions during the creation of the Quick user by including the --custom-permissions-name parameter in your call. When to use this approach: Your organization controls the user creation process end-to-end through a custom portal or script. This is the most direct path, no event-driven infrastructure required. This is especially common for software as a service (SaaS) companies embedding Quick across customer accounts. For instance, automatically restricting premium features like paginated reports and GenBI based on a customer’s pricing tier at the moment each user is provisioned. The following example applies a custom permissions profile named Restricted-Author-Profile to Authors in the account, but the same API can be used to apply permissions profiles to any role (including Author Pros, Admins, Admin Pros, Readers, and Reader Pros). Scenario 2: Default account or role permissions (API and CLI) With two native APIs, you can set default custom permission profiles without per-user automation. Note that Quick custom permissions follow a three-level hierarchy (account, role, and user) where user-level settings override role-level, which override account-level, allowing administrators to implement flexible, layered security policies. When to use this approach: These APIs cover both current and future use cases with minimal operational overhead. Start here before building custom automation. Move to Scenario 3 only if you need conditional logic beyond what account or role-level defaults support. For example, a 50,000-user enterprise may need all newly launched GenBI features and connectors blocked by default until their security team completes a 60–90-day review. An account-level default enforces that restriction instantly, without requiring any per-user automation and with no provisioning gap. Option A: Account-level default The UpdateAccountCustomPermission API sets a fallback custom permission profile that Quick applies to any user who doesn’t have an explicit profile assigned, including new users created with Just-In-Time provisioning. Option B: Role-level default With the UpdateRoleCustomPermission API, you can set a default custom permission profile per Quick role (READER, AUTHOR, ADMIN, and PRO roles). Scenario 3: Event-driven custom logic (Amazon EventBridge and Lambda) This scenario addresses more granular requirements: applying different custom permissions profiles to users based on which Quick or IAM Identity Center group they belong to. For example, a 125,000-employee technology services company needs authors in each business unit to receive distinct permission profiles at the moment of group assignment. This prevents cross-unit asset sharing while granting power-user access only to approved individuals, even though all authors share the same Quick role. Because we don’t have a native API for assigning custom permissions to a Group, we will need an architecture that detects when a user is added to a group that should have specific permissions. Note: We suggest combining this approach with Scenario 2 for a fully layered permissions strategy. Scenarios 2 and 3 are complementary, not alternatives. When a user is provisioned through Just-In-Time federation, there’s an unavoidable window between account creation and the moment an administrator adds them to the appropriate group. Scenario 3 only fires on the group membership event. To keep users from ever being in an unrestricted state, apply Scenario 2 first as a baseline: set an account-level or role-level default that enforces your most restrictive acceptable profile. Then use Scenario 3 to refine permissions once the user is assigned to a group. The user-level override from Scenario 3 will take precedence over the Scenario 2 default, so there is no conflict, only complementary layers of control. Consider a global bank with more than 200,000 users, provisioned through single sign-on (SSO), that must block data export the instant an employee joins. Scenario 2 closes that gap immediately with a restrictive account-level default, and Scenario 3 refines permissions once the user is assigned to their compliance group. This prevents employees from downloading sensitive client data during the window between provisioning and group assignment. Quick and IAM Identity Center emit distinct AWS CloudTrail events for group membership changes. Quick emits CreateGroupMembership when a user is added and DeleteGroupMembership when removed. IAM Identity Center emits AddMemberToGroup when a user is added and RemoveMemberFromGroup when removed. The following architecture detects these events to trigger permission updates automatically. We will build this using Amazon EventBridge (to detect the event) and AWS Lambda (to apply the fix). - A user is added to a Quick or Identity Center group. - Amazon CloudTrail: Captures the CreateGroupMembership orAddMemberToGroup events. - Amazon EventBridge: Filters these logs to identify when a user is successfully added to the group. - AWS Lambda: Extracts the user details and applies the correct permission profile using the UpdateUserCustomPermission API. Prerequisites Before implementing this solution, confirm you have the following: - An AWS account with administrative access. - AWS Identity and Access Management (IAM) permissions to create and manage AWS resources using AWS CloudFormation. - Access to the following AWS services: - AWS CloudFormation: deploys and manages the infrastructure stack as code. - Amazon Quick: the target service where custom permissions are applied. - AWS CloudTrail: must be enabled in the target AWS Region. Captures Quick and IDC API events that Amazon EventBridge consumes. - Amazon EventBridge: filters CloudTrail events to detect group membership changes. - AWS Lambda: executes the automation logic that calls the UpdateUserCustomPermission API. - AWS IAM Identity Center: required only if using IDC group-based triggers. - Python 3.9+ and AWS Command Line Interface (AWS CLI) v2 are required for running the batch update script in Scenario 4. Deploy with CloudFormation You can deploy the full pipeline (IAM role, Lambda function, and Amazon EventBridge rule) using the provided CloudFormation template. The CloudFormation stack must be deployed in the same AWS Region as your Amazon Quick subscription, since Amazon EventBridge rules only capture events within their own Region. The template accepts the following parameters: If you prefer to deploy manually, follow these steps: Step 1: Create the IAM role for Lambda Your Lambda function needs permission to interact with Quick. - Go to the IAM Console → Policies → Create policy. - Switch to the JSON tab and paste this policy: - Note: the permissions to IdentityStore are only needed if your Quick account is integrated with IAM Identity Center. - Name the policy Quick-Lambda-Policy and choose Create policy. - Navigate to Roles → Create role. - Select AWS Service and choose Lambda. - Choose Next. - Search for and select the Quick-Lambda-Policy . - Choose Next. - Name the Role Quick-Auto-Permissions-Role and select Create role. Step 2: Deploy the Lambda function - Go to the Lambda Console → Create function. - Function name: Auto-Assign-QS-Permissions . - Runtime: Python 3.14 (or latest available). - Execution role: Use another role → Select Quick-Auto-Permissions-Role . - Choose Create function. - Under Configuration → General configuration, increase the timeout to 30 seconds. - This should be sufficient for single-event processing. If you observe timeouts in Amazon CloudWatch Logs, increase this value accordingly. - Set the following environment variables under Configuration → Environment Variables:. - Navigate back to the Code Source editor and paste the following code: - Choose Deploy. Step 3: Create the Amazon EventBridge rule Now we must configure this function so that it runs only when a user is successfully added to a group. - Go to the Amazon EventBridge Console. - Select Rules → Create rule. - Opt out of the Visual rule builder. - Under Name enter Quick-Group-Membership-Creation-Rule and choose Next. - Select Other under Event source. - Paste the following into the JSON editor for Event pattern:.When the Quick account is integrated with IDC, the source of this event will be the IDC identity store whereas the source will be Quick otherwise. Therefore, the Amazon EventBridge rule we will create will depend on the account authentication mechanism:Option A: IAM Identity Center Option B: Other Authentication (using Quick Groups) - Select AWS Service as the Target type. - Select Lambda function as the target and choose Auto-Assign-QS-Permissions (the function you built in Step 2). - Choose Next and Create rule. Step 4: Add the Amazon EventBridge trigger - Return to the Auto-Assign-QS-Permissions Lambda function. - Navigate to Configuration → Triggers → Add trigger. - Select Amazon EventBridge as the source. - Choose Existing rules and select the Quick-Group-Membership-Creation-Rule created in Step 3. - Choose Add. Step 5: Verify the setup To test this, add a user to a Group in Quick or IDC: - Test: Manually add a new or existing user to the target Group. - Monitor: Go to the CloudWatch Logs for your Lambda function. - Confirm: You should see a log entry like: Permission profile ‘123’ applied to user ‘XYZ’. - Result: When that user logs in, they will be restricted by the profile. Design considerations Group removal: This solution for Scenario 3 already handles removal events. When a user is removed from the target group, the Lambda calls DeleteUserCustomPermission, reverting them to the account or role-level default from Scenario 2. No additional configuration is needed. Multi-group membership: Quick supports only one custom permissions profile per user at a time. If your organization assigns users to multiple groups with different profiles, you can extend the Lambda logic to list all groups the user belongs to, look up the profile mapped to each group, and apply the highest-priority profile (for example, the most restrictive profile). This multi-group conflict resolution isn’t included in the provided solution and must be implemented by your team based on your organization’s specific priority rules. Scenario 4: Batch update for existing group members You likely have existing groups (for example, “Finance-Readers” or “Marketing-Authors”) containing users who need specific restrictions applied retroactively. Because these users were created in the past, the Amazon EventBridge automation (Scenario 3) won’t catch them. To fix this, we use a Python script to iterate through a specific Quick Group and apply the custom permission profile to every member. The challenge: Pagination Quick groups can contain thousands of users. The API ListGroupMemberships only returns 100 members at a time. If you write a script without pagination logic, it will stop after the first 100 users, leaving the rest unsecured. The following script handles this automatically using NextToken. Copy the following code. You only need to edit the Configuration Section at the top. Note: The default delay of 0.1 seconds between API calls (~10 requests/second) is suitable for most deployments. For large-scale groups (over 10,000 members), increase API_DELAY_SECONDS to avoid API throttling. Monitor for ThrottlingException errors in the output and adjust as needed for your environment. Detailed execution steps - Prepare your environment.You can run this locally or in AWS CloudShell directly in your browser, which comes pre-authenticated and has Boto3 installed. - Sign in to the AWS Management Console. - Choose the CloudShell icon (terminal icon) in the top navigation bar. - Create the script file.In the CloudShell terminal, enter the following command to open a text editor:nano update_permissions.py - Paste the preceding Python code into the editor. - Edit the AWS_ACCOUNT_ID andTARGET_GROUP_NAME variables at the top of the file to match your environment. - Press Ctrl+X, then Y, then Enter to save and exit. - Run the script.Execute the script with Python:python3 update_permissions.py - Verify results. - The script will print “OK” next to every user it successfully updates. - If any users fail, the script writes a failed_users_{GROUP_NAME}.csv file with the username and failure reason for each. Review this file to identify users that need manual follow-up. - If you see “Profile not found,” double-check that you created the Custom Permission Profile in the Amazon Quick console exactly as spelled in the script. - Run aws quicksight describe-user --aws-account-id <ACCOUNT_ID> --namespace <NAMESPACE> --user-name <USERNAME> and confirm that theCustomPermissionsName field in the response matches your expected profile. Clean up If you deployed using the CloudFormation template, delete the stack to remove all resources it created, including the Amazon EventBridge rule, Lambda function, and associated IAM role and policy. If you deployed manually, delete the following resources: - The Amazon EventBridge rule (Quick-Group-Membership-Creation-Rule ). - The Lambda function (Auto-Assign-QS-Permissions ). - The IAM role (Quick-Auto-Permissions-Role ) and policy (Quick-Lambda-Policy ). The batch update script (Scenario 4) does not deploy any infrastructure and requires no clean up. Conclusion Automating custom permissions in Amazon Quick is a foundational step toward a secure, scalable user governance strategy. As your Quick environment grows, the patterns in this post help verify that authentication and authorization scale together, not independently. The following table summarizes the four scenarios and when to apply each: One manual step remains in the Scenario 3 flow: an administrator must add each user to the appropriate group before the event-driven pipeline fires. You can remove this step entirely by extending the same Amazon EventBridge + Lambda architecture to listen for new user creation events. When new users are provisioned through Just-In-Time federation, CloudTrail captures a CreateUser event (when Quick users are invited by admins, this produces a BatchCreateUser event). A Lambda function can intercept that event and apply custom logic to determine the correct group based on email domain, internal user mapping, or any available user attribute. It then calls CreateGroupMembership to assign the user to that group automatically. Combined with Scenario 3, this approach can create a fully automated pipeline with no manual steps. A full implementation of this extension is beyond the scope of this post. However, the building blocks (CloudTrail event capture, Amazon EventBridge filtering, and Lambda-based Quick API calls) are identical to those described in Scenario 3. Start with Scenario 2 to establish your baseline today. For more details, see Amazon Quick Custom Permissions in the Amazon Quick User Guide.