You can grant federated users access to an Amazon S3 bucket in another AWS account by using IAM Identity Center’s native cross-account permission sets. This approach eliminates the need for complex trust policies or manual role assumption code, allowing you to assign specific permissions directly to users or groups across accounts through a centralized identity provider.
Understanding the Native Cross-Account Model
The previous guidance suggested using
AssumeRole with strict tag-based conditions, which is often unnecessary and prone to configuration errors. IAM Identity Center simplifies this by handling the authentication and authorization flow automatically. When you enable cross-account access, Identity Center acts as the central source of truth for identities. It manages the session tokens that allow a user to interact with resources in target accounts without requiring them to manage long-term credentials or write custom scripts for token exchange.
This method relies on the concept of Permission Sets rather than individual IAM roles. A Permission Set defines what actions a user can perform, such as reading from an S3 bucket. These sets are assigned to users or groups within the Identity Center identity store. The actual linking between the user's identity and the target AWS account is handled by the "Account Assignment" feature. This separation of concerns ensures that your security posture remains consistent even as you add new users or change their responsibilities.
Prerequisites for Configuration
Before configuring access, ensure that IAM Identity Center is enabled in your organization’s management account. You must have administrative privileges in both the source account (where the user exists) and the target account (where the S3 bucket resides). If you do not already have users provisioned, refer to
Create Additional Users in AWS: A Step-by-Step Guide to understand how to populate your identity store. Without active users in the directory, there is no one to assign permissions to.
Additionally, verify that the S3 bucket policy allows access from trusted principals. While Identity Center handles most of the heavy lifting, the bucket itself must not block requests from the assumed role. Typically, enabling cross-account access via Identity Center automatically injects the necessary principal ARNs into the session context, but checking the bucket policy is a good diagnostic step if access fails initially.
Creating the Permission Set
Navigate to the IAM Identity Center console in the management account. Select "Permission sets" from the left-hand menu and click "Create permission set." Choose the AWS managed policy option for simplicity, or create a custom policy if you need granular control. For S3 access, select the
AmazonS3ReadOnlyAccess managed policy, or create a custom inline policy that specifies the exact bucket ARN you wish to protect.
Custom policies are recommended for production environments to follow the principle of least privilege. Your JSON policy should look like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::your-target-bucket-name",
"arn:aws:s3:::your-target-bucket-name/*"
]
}
]
}
Replace
your-target-bucket-name with the actual name of the bucket in the target account. This policy explicitly grants read-only access to the specified resource. Avoid using wildcard (*) resources unless absolutely necessary, as this increases the risk of accidental data exposure.
Assigning Permissions to Target Accounts
Once the permission set is created, you must associate it with the target AWS account. In the IAM Identity Center console, go to "AWS accounts" and select the target account where the S3 bucket resides. Click on "Assign permissions" for that account. Here, you will select the Permission Set you just created and choose the users or groups who require access.
This step is crucial because it binds the identity to the specific AWS account. Without this assignment, the user cannot assume any role in the target account, regardless of the permissions defined in the permission set. You can assign multiple users to the same permission set within the same account, streamlining the management of large teams.
Testing Access and Troubleshooting
After assigning permissions, wait a few minutes for propagation. Log in to the AWS Management Console using the federated user’s credentials. Navigate to the S3 service in the target account. If configured correctly, the user should see the bucket and be able to list objects. If access is denied, check the following:
- Propagation Delay: Identity Center assignments may take up to 5 minutes to propagate globally.
- Bucket Policy: Ensure the bucket does not have a deny-all statement that overrides the permission set.
- User Context: Verify that the user is actually logged into the correct AWS account console view.
For more complex scenarios involving external identity providers, consider reviewing
Integrating Keycloak SAML with LDAP Users for AWS Client VPN to understand how external identities map to internal AWS roles. However, for standard S3 access, the native Identity Center workflow is sufficient and more secure.
Frequently Asked Questions
Can I use IAM Identity Center with existing IAM users?
No, IAM Identity Center requires users to exist within its own identity store or be synced from an external directory like Active Directory. You cannot directly attach Identity Center permission sets to legacy IAM users created in the AWS Account. You must migrate those users to the Identity Center store first.
What happens if I remove a user from a group?
If you remove a user from a group that has an assigned permission set, the user loses access immediately upon the next session refresh. There is no grace period, so ensure you reassign permissions to other users before removing critical members from groups to avoid operational disruptions.
Does this method work for programmatic API access?
Yes, federated users can generate temporary security credentials via the AWS CLI or SDK. After logging in through Identity Center, you can use the
aws sso login command to obtain credentials. These credentials inherit the permissions defined in the assigned permission set, allowing seamless API integration.
Is there a limit to the number of accounts I can manage?
IAM Identity Center supports managing thousands of AWS accounts within a single organization. The primary limitation is usually administrative overhead rather than technical capacity. As you scale, consider using automated tools or infrastructure-as-code templates to manage bulk account assignments efficiently.
How do I audit who accessed which bucket?
Enable AWS CloudTrail logging for the target S3 bucket. CloudTrail records all API calls, including those made by federated users. You can filter logs by the
userIdentity.principalId field to trace actions back to specific Identity Center sessions, providing a clear audit trail for compliance purposes.