Messages From Unencrypted SNS Topic Not Reaching Encrypted SQS Queue - amazon-web-services

I have an unencrypted SNS topic with an encrypted SQS queue subscribed to it. Whenever I publish messages from the SNS topic, the SQS queue does not receive the message (the SQS queue receives messages successfully from the SNS topic when encryption is disabled). So far I have been following this guide. Here is what I have completed so far:
Create KMS customer managed key (CMK) with the following key policy ("Configure KMS permissions for AWS services" section in linked guide):
{
"Version": "2012-10-17",
"Id": "key-consolepolicy-3",
"Statement": [
{
"Sid": "Allow administration of the key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::${aws_account_id}:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow SNS to use KMS",
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*"
}
]
}
Currently I am stuck on the "Configure KMS permissions for producers" section. When I add the following statement in the Statement list of my KMS CMK's key policy, I get the error MalformedPolicyDocumentException - Policy contains a statement with no principal.
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "${kms_customer_managed_key_arn}"
},
{
"Effect": "Allow",
"Action": [
"sqs:SendMessage"
],
"Resource": "${sqs_queue_arn}"
}
The guide does not include a principal in its policy, so I do not understand why I am getting an error. Can anyone give me any help or advice on how to move forward with this?

Related

How use SNS resource policy to restrict SQS subscription in the owner account

I have a scenario whereby I want to create an SNS topic but apply resource policy such that only certain endpoints are allowed to subscribe to it. e.g
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__console_pub_0",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::555555555:root"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:eu-west-1:555555555:hafiz-test"
},
{
"Sid": "__console_sub_0",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::555555554:root"
},
"Action": [
"SNS:Subscribe",
"SNS:Receive"
],
"Resource": "arn:aws:sns:eu-west-1:555555555:hafiz-test",
"Condition": {
"StringLike": {
"SNS:Endpoint": "arn:aws:sqs:eu-west-1:555555554:hafiz-test"
}
}
}
]
}
This scenario works perfectly in a scenario where the SQS subscribing to the SNS topic is across another account so unless I list the SQS arn "SNS:Endpoint": "arn:aws:sqs:eu-west-1:555555554:hafiz-test" in the condition subscription fails with permissions.
I want to achieve the same thing for any SQS queues that are in the SNS owner account. At the moment any SQS resource in the same account as SNS can subscribe to the SNS topic
Thanks much appreciated.

SNS published messages not reaching SQS

I've a encrypted SQS queue and SNS topic by custom managed KMS key. Currently I'm using a similar kind of SQS policy stated in the below link where it is working fine SQS Policy
But if i use the below SQS policy it's not working. I don't want to have Principal as '*' due to security reasons. Can someone explain me why is this happening
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"MySQSPolicy001",
"Effect":"Allow",
"Principal":{
"AWS": "arn:aws:iam::123456789012:root"
},
"Action":"sqs:SendMessage",
"Resource":"arn:aws:sqs:us-east-1:123456789012:MyQueue"
}
]
}
So if you've a condition with SNS arn in your queue policy when more than one topic needs to publish to same queue you might need to add the ARN again & again.
So the workaround will be the below policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Queue1_SendMessage",
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com",
"AWS": "arn:aws:iam::1234567890:root"
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage",
"sqs:DeleteMessage"
],
"Resource": "arn:aws:sqs:eu-central-1:1234567890:test-queue",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "1234567890"
}
}
}
]
}

Invoking SNS from cross account using API Gateway

I am having an API gateway end point in my AWS account which will invoke a SNS in another AWS account in same region.
The access policy in API gateway in my account is like follows
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sns:Publish",
"Resource": "arn:aws:sns:ap-southeast-1:604970532282:PublishSourceMsgTopic"
}
]
}
The sns arn : arn:aws:sns:ap-southeast-1:604970532282:PublishSourceMsgTopic belongs to another AWS account in same region.
The json of the access policy configured in the above SNS is :
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__default_statement_ID",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"SNS:Publish",
"SNS:RemovePermission",
"SNS:SetTopicAttributes",
"SNS:DeleteTopic",
"SNS:ListSubscriptionsByTopic",
"SNS:GetTopicAttributes",
"SNS:Receive",
"SNS:AddPermission",
"SNS:Subscribe"
],
"Resource": "arn:aws:sns:ap-southeast-1:604970532282:PublishSourceMsgTopic",
"Condition": {
"StringEquals": {
"AWS:SourceOwner": "604970532282"
}
}
},
{
"Sid": "__console_pub_0",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::148445556582:root"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:ap-southeast-1:604970532282:PublishSourceMsgTopic"
}
]
}
When I am invoking the API Gateway its showing the following error :
User: arn:aws:sts::148445556582:assumed-role/api_gateway_sns_role/BackplaneAssumeRoleSession is not
authorized to perform: SNS:Publish on resource: arn:aws:sns:ap-southeast-
1:604970532282:PublishSourceMsgTopic
I am able to invoke the SNS successfully if i am giving SNS topic which is configured in my AWS account.
What am I missing here?
You are giving permission for the root owner of the external account to publish on the topic, but the actual publish request is using the role of the API gateway.
So in your access policy, you'll need to give the publish permission to the role the API Gateway is using, not the role of root.
Typically what you would do is set "Principal": "*" and then add conditions under resource in the policy to match the account and arn of the resource accessing SNS from another account.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-2:444455556666:MyTopic",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:cloudwatch:us-east-2:111122223333:alarm:MyAlarm"
}
}
}]
}
There are several example access policies here, that should help you.

How to set up AWS SNS in one account to be able to receive notifications from SES of other account?

I have two AWS accounts:
Account 1 (111111111111) contains Simple Notification Service Topic (Email Events Topic)
Account 2 (222222222222) contains Simple Email Service with Configuration Set (Configuration_Set_01).
I want to add SNSDestination to Configuration_Set_01 - to be able to publish SES event notifications to Email Events Topic
I’ve set up following Topic Policy for Email Events Topic:
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__console_pub_0",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::2222222222222:root"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-1:111111111111:email-events-topic"
}
]
}
When I try to add SNSDestination to Configuration_Set_01, referring Email Events Topic, it gives me an error Could not access SNS topic <…> …:
If Email Events Topic's policy is as follows, destination can be added successfully:
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__console_pub_0",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-1:111111111111:email-events-topic"
}
]
}
This works:
"Principal": {
"AWS": "*"
}
This doesn't work:
"Principal": {
"AWS": "arn:aws:iam::222222222222:root"
}
As I can see here https://docs.aws.amazon.com/AmazonS3/latest/dev/s3-bucket-user-policy-specifying-principal-intro.html - the syntax for Principal.AWS value in the second option is correct.
How can I correctly set up Topic Policy on Email Events Topic to be able to add it as an event destination only to Account 2's SES Configuration Sets (or any Account 2's services)?
What else should be done to solve the problem in case the problem is not only with the Topic Policy?
The sample link you shared is for S3 resource policy. Could you please try to edit the policy as following which is from SNS document?
{
"Version":"2012-10-17",
"Id":"AWSAccountTopicAccess",
"Statement" :[
{
"Sid":"give-1234-publish",
"Effect":"Allow",
"Principal" :{
"AWS":"111122223333"
},
"Action":["sns:Publish"],
"Resource":"arn:aws:sns:us-east-1:444455556666:MyTopic"
}
]
}
Additionally, you can also use "AWS:SourceAccount" condition key with Principal *.
Here is the Topic Policy, which works for the described situation:
{
"Version": "2012-10-17",
"Id": "MyTopicPolicy",
"Statement": [
{
"Sid": "sid001",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sns:Publish",
"Resource": "arn:aws:sns:us-east-1:111111111111:email-events-topic",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:ses:us-east-1:222222222222:*"
}
}
}
]
}
The tricky part was Condition -> ArnLike:
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:ses:us-east-1:222222222222:*"
}
}

How do I write the policy statement of an encrypted SQS for S3 events?

I have an SQS queue which used to have the following policy doc. for receiving S3 events from a bucket:
{
"Version": "2008-10-17",
"Id": "example-ID",
"Statement": [
{
"Sid": "example-statement-ID",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-1:<>:cypher-queue",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:*:*:cypher-secondarybucket"
}
}
}
]
}
Now, I have enabled Server-side encryption(SSE) for the queue. And, I have followed this doc for writing the policy statement for encryption. The policy statement now, looks like this:
{
"Version": "2008-10-17",
"Id": "example-ID",
"Statement": [
{
"Sid": "example-statement-ID",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-1:<>:cypher-queue",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:*:*:cypher-secondarybucket"
}
}
},
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:sqs:us-east-1:<>:cypher-queue",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:*:*:cypher-secondarybucket"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:<>:cypher-queue",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:*:*:cypher-secondarybucket"
}
}
}
]
}
But now, the queue is not getting any messages from the bucket on file additions. Is there something wrong which I did with the permissions?
This is now possible. From the AWS documentation:
https://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html#grant-destinations-permissions-to-s3 under the section AWS KMS Key Policy
If the SQS queue is SSE enabled, you can attach the following key
policy to the associated AWS Key Management Service (AWS KMS) customer
managed customer master key (CMK). The policy grants the Amazon S3
service principal permission for specific AWS KMS actions that are
necessary for to encrypt messages added to the queue.
{
"Version": "2012-10-17",
"Id": "example-ID",
"Statement": [
{
"Sid": "example-statement-ID",
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*"
}
]
}
I have missed the following announcement from the same article. A very silly mistake on my part. Will need to wait for sending S3 events to encrypted SQS.
The following features of AWS services aren't currently compatible
with encrypted queues:
Amazon CloudWatch Events
Amazon S3 Event Notifications
Amazon SNS Topic Subscriptions
Auto Scaling Lifecycle Hooks
AWS IoT Rule Actions
AWS Lambda Dead-Letter Queues