Menu
It is possible to send S3 events from Account A to an SQS topic in Account B. But, the only way I have been able to achieve this is by opening the permissions for the sendMessage action in SQS to allow everyone access.
Is it possible to configure S3 events to sendMessage to a different account with some permission restrictions in place on the SQS topic?
For example, if I try to restrict access to a specific account (e.g. 123456789012, I receive an error in the S3 console when I try to save the event: "Unable to validate the following destination configurations : Permissions on the destination queue do not allow S3 to publish notifications from this bucket"
{
"Version": "2012-10-17",
"Id": "sqs-permission",
"Statement": [
{
"Sid": "sqs-permision-statement",
"Effect": "Allow",
"Principal": {
"AWS": "123456789012"
},
"Action": "SQS:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:210987654321:my-queue"
}
]
}
535
I had a use case to trigger two different lambdas from the same bucket for different requirements and if we try to create a new object create event notification, it will be failed automatically by S3 itself. S3 does not allow us to have two objectCreate event notifications on the same bucket.
To share your bucket via Bucket Policies:Start S3 Browser and select the bucket you want to share. Replace s3browser with your actual bucket name and 1234-5678-9012 with the actual grantee's Account Id. If you would like to grant other permissions, please check AWS Policy Generator to create bucket policy you need.
Sends notifications from S3 to SNS when an object is created. This SAM template creates an S3 bucket and an SNS topic. S3 writes a messages to the SNS topic when a new object is put into the bucket.
On the Lambda function overview tab, Click +Add trigger. Select SQS from dropdown and in SQS queue box enter the ARN of queue from Account A which the queue was created with cross-account permissions and lastly click Add.
According to the documented example, the authorization needs to be granted to S3, not the account owning the bucket.
"Principal": {
"AWS": "*"
},
...
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:*:*:bucket-name"
}
}
The * principal seems unusually permissive, but the likely explanation is that aws:SourceArn is not a value that could be spoofed by a malicious user, any more than, say, aws:SourceIp.
By contrast, the SNS example shows this principal, which seems more appropriate, if it works for SQS notifications:
"Principal": {
"Service": "s3.amazonaws.com"
},
You'd still want to include the Condition block.
140
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
