- Newest
- Most votes
- Most comments
Hi, Thanks for the detailed question. What you're seeing is not a bug or a misconfiguration — it's CloudTrail's designed behavior. When an external user (from another account) accesses your bucket directly via a bucket policy, CloudTrail in your account (the bucket owner) will only show you:
- That the request came from another account (userIdentity.type: AWSAccount)
- The account ID of that account (555555555555)
- But not the specific user ARN Why? Because CloudTrail enforces a privacy boundary between accounts. Your account doesn't have the "right" to see the internal identity details of another account in your own logs. This is an AWS design decision, not something you can change with any configuration. S3 Access Logs do capture the full ARN because they operate at a different layer — they record the identity directly from the request signature without applying that privacy boundary.
What can you do?
- Keep using S3 Access Logs to identify the external user (you're already doing this and it's the correct source for this information).
- Combine both sources — use S3 Access Logs for the "who" and CloudTrail for the additional context (IP, user agent, errors, etc.). You can correlate by timestamp + object key + source IP.
- Require the external user to assume a role in your account before accessing the bucket. If you do this, CloudTrail in your account would show type: AssumedRole with the full session ARN. But this requires changing the access architecture — the external user would need to call AssumeRole first instead of accessing directly with their IAM user. Bottom line: There is no CloudTrail or IAM setting you can change to make the external ARN appear. Your best immediate option is to use S3 Access Logs as the authoritative source for identity, and if you need everything in CloudTrail in the future, migrate to a cross-account role-based access model.
answered 2 months ago
The discrepancy you're experiencing between CloudTrail logs and S3 Access Logs for GetObject events with external User ARNs is a known behavior in AWS CloudTrail. This is not an error or misconfiguration on your part, but rather a limitation of how CloudTrail logs cross-account access to S3 buckets.
When an IAM user or role from an external AWS account accesses an S3 bucket in your account, CloudTrail logs this as an "AWSAccount" type event rather than an "IAMUser" or "AssumedRole" event. This is because CloudTrail in your account doesn't have direct visibility into the identity details of users in other AWS accounts.
In these cross-account scenarios, CloudTrail will log:
- The userIdentity.type as "AWSAccount"
- The userIdentity.accountId as the external AWS account ID
- The userIdentity.arn as null
This behavior is by design and is intended to protect the privacy and security of users in other AWS accounts.
S3 Access Logs, on the other hand, are able to capture more detailed information about the requester, including the full ARN of external users. This is because S3 has direct access to this information at the time of the request.
Unfortunately, there isn't a configuration change you can make in CloudTrail or IAM policies to capture the external User ARN in CloudTrail logs for cross-account access. This limitation is inherent to how CloudTrail works across account boundaries.
To get the level of detail you're looking for, you have a few options:
-
Continue using S3 Access Logs alongside CloudTrail for the most comprehensive logging solution. While this requires managing two log sources, it provides the most complete picture of access to your S3 bucket.
-
If possible, use AWS Organizations and enable all features. This allows CloudTrail to capture user identity information across accounts within your organization.
-
Consider implementing custom logging solutions or using AWS Lambda in conjunction with CloudTrail to enrich the logs with additional information from other sources.
-
Use AWS CloudTrail Lake, which allows you to aggregate and analyze CloudTrail logs from multiple accounts in a centralized location. While it won't change how the events are logged, it can make it easier to correlate events across accounts.
Remember, while CloudTrail may not provide the exact User ARN for cross-account access, it still provides valuable information such as the source account ID, which can be used for auditing and security analysis.
Sources
Secure and Standardized Logging - AWS CloudTrail Resources - Amazon Web Services
Monitoring S3 on Outposts with AWS CloudTrail logs - Amazon S3 on Outposts
Identifying Amazon S3 requests using CloudTrail - Amazon Simple Storage Service
Relevant content
asked 5 years ago
- AWS OFFICIALUpdated 4 months ago
