SNS cannot send messages to SQS queues due to permission issue

0

SNS topic created arn:aws:sns:af-south-1:XXXXXXXXXXXX:topic.fifo and has the following access policy set:

{
  "Version": "2008-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Sid": "__default_statement_ID",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "SNS:GetTopicAttributes",
        "SNS:SetTopicAttributes",
        "SNS:AddPermission",
        "SNS:RemovePermission",
        "SNS:DeleteTopic",
        "SNS:Subscribe",
        "SNS:ListSubscriptionsByTopic",
        "SNS:Publish"
      ],
      "Resource": "arn:aws:sns:af-south-1:XXXXXXXXXXXX:topic.fifo",
      "Condition": {
        "StringEquals": {
          "AWS:SourceOwner": "XXXXXXXXXXXX"
        }
      }
    }
  ]
}

The topic is subscribed to the following two queues.

  • First queue: arn:aws:sqs:af-south-1:XXXXXXXXXXXX:first-queue.fifo with the following policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "sns.amazonaws.com"
      },
      "Action": "sqs:SendMessage",
      "Resource": "arn:aws:sqs:af-south-1:XXXXXXXXXXXX:first-queue.fifo",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:sns:af-south-1:XXXXXXXXXXXX:topic.fifo"
        }
      }
    }
  ]
}
  • Second queue: arn:aws:sqs:af-south-1:XXXXXXXXXX:second-queue.fifo with the following policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "sns.amazonaws.com"
      },
      "Action": "sqs:SendMessage",
      "Resource": "arn:aws:sqs:af-south-1:XXXXXXXXXX:second-queue.fifo",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:sns:af-south-1:XXXXXXXXXXXX:topic.fifo"
        }
      }
    }
  ]
}

But SNS is failing to send the messages to SQS queues with the following error:

{
    "notification": {
        "messageId": "1c2a9c20-977f-5552-a73b-c16037ebcac6",
        "topicArn": "arn:aws:sns:af-south-1:XXXXXXXXXXXX:topic.fifo",
        "timestamp": "2023-07-30 17:31:00.864"
    },
    "delivery": {
        "deliveryId": "b69c20d5-88b6-4fc4-ba4c-b69e12585e40",
        "destination": "arn:aws:sqs:af-south-1:XXXXXXXXXX:second-queue.fifo",
        "providerResponse": "{\"sqsRequestId\":\"1bda078a-2866-5392-a525-5aca88f2ce07\",\"errorCode\":\"AccessDenied\",\"errorMessage\":\"User: sns.amazonaws.com is not authorized to perform: sqs:sendmessage on resource: arn:aws:sqs:af-south-1:XXXXXXXXXX:second-queue.fifo because no resource-based policy allows the sqs:sendmessage action\"}",
        "dwellTimeMs": 16,
        "statusCode": 403
    },
    "status": "FAILURE"
}
4 Answers
1
Accepted Answer

First, double-check the ARNs of your resources, especially the ARN of your second queue, and ensure they match in the queue's policy and the error message. In your error message, the ARN is "arn:aws:sqs:af-south-1:XXXXXXXXXX:second-queue.fifo", but in your policy, it's "arn:aws:sqs:af-south-1:XXXXXXXXXXXX:second-queue.fifo". If the number of X's is representative of your actual account ID, they do not match - one has 10 X's, the other has 12. Please ensure the ARN is correct and the same in all places.

Assuming that the ARN is correct, let's consider the policies. The SNS topic policy allows a broad set of actions, which is good, but we need to make sure that the SQS policies allow SNS to interact with them.

Your SQS queue policies appear to be correctly configured to allow SNS to send messages ("sqs:SendMessage") to them, with the condition that the SourceArn matches your SNS topic. However, remember that you need to have the correct ARN in these policies.

If you're still having trouble after verifying the ARNs and the policies, try adding the following policy to your SQS queues:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "SQS:SendMessage",
      "Resource": "arn:aws:sqs:af-south-1:XXXXXXXXXXXX:second-queue.fifo",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:sns:af-south-1:XXXXXXXXXXXX:topic.fifo"
        }
      }
    }
  ]
}

In this policy, the Principal has been changed from "Service": "sns.amazonaws.com" to "AWS": "". If this change allows the SNS to send messages to the SQS queues, then the issue was with AWS identifying the SNS service as a principal. However, using a wildcard "" for the principal is less secure because it allows any AWS account to perform actions on the resource, provided they meet the other policy conditions. It's better to restrict access to specific AWS services or accounts whenever possible.

Another important note is to make sure you have the correct region specified. The regions in your ARNs should match the actual regions of your services. In this case, the region is "af-south-1", so you need to ensure your SNS topic and SQS queues are indeed in this region.

profile picture
answered 9 months ago
0

Hello!

I understand that you are facing issues with sending messages from your SNS topic to your SQS queues. Here are a few steps that you can use to troubleshoot and resolve the problem:

[1] Double-check that the AWS Region of both the SNS topic and the SQS queues are the same. Messages cannot be directly sent from an SNS topic in one region to an SQS queue in another region, unless you change your policies (documentation for cross-region interaction below)

[2] Verify the Amazon Resource Names (ARNs) for the SNS topic and the SQS queues. Ensure that the ARNs in the policies match the actual ARNs of the resources. Additionally, confirm that the names of the SQS queues specified in the policies match the actual names of the queues.

[3] Check the "AWS:SourceOwner" specified in the SNS access policy. Verify that it matches the correct AWS account ID. This will aid in getting the necessary access.

[4] Enable CloudTrail to check the logs for any additional clues about the "AccessDenied" error. Use this information to determine what issue you might be having.

If the issue persists after trying these steps, there might be other methods and steps to explore for resolution. You can refer to the following AWS resources for further guidance:

[1] Sending SNS message to SQS in another region: https://docs.aws.amazon.com/sns/latest/dg/sns-cross-region-delivery.html

[2] Subscribing SQS to SNS topic: https://docs.aws.amazon.com/sns/latest/dg/subscribe-sqs-queue-to-sns-topic.html

[3] Troubleshooting AccessDenied for SQS: https://repost.aws/knowledge-center/sqs-accessdenied-errors

AWS
Vidit_P
answered 9 months ago
0

If you are using SSE-KMS on the SQS queue, you need to grant SNS access to the KMS key or else the Message will be rejected. This could be the cause of the error message.

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-sse-existing-queue.html

profile picture
EXPERT
answered 9 months ago
0

Hello everyone,

Thanks a lot for all your suggestions. I can confirm that both SNS and SQS are in the same region. I also checked the ARNs - those are also correct. In fact. I was using Terraform to create these resources in 7 regions. Apart from af-south-1 region, other 6 are working well.

I have just changed the the principal to wildcard AWS and it's working. @Ercan -flightlesstux-

"Principal": {
    "AWS": "*"
},

It seems weird though. Why other regions are working and only this one doesn't? Any idea? I don't want to use a wildcard entry.

@Gary Mclean: thanks for the information. But I can confirm that the queues are using Amazon SQS key (SSE-SQS), not KMS.

profile picture
answered 9 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions