CODEWITHSUNDEEP
amazon-sqsamazon-sns
Sashi
Sashi

Reputation: 2867

KMS Access Denied exception on SNS Topic to SQS queue

Background: I am trying to execute a lambda function by using a SQS queue as the trigger. And once the lambda function finishes executing, I am trying to send a response to another SQS queue via a SNS topic.

SQS Queue -> Lambda -> SNS topic -> SQS Queue

I initially tried to use Destinations to send Lambda's response to SQS, but that only works for async invocations and SQS is considered as a sync invocation. Fine. So now I trigger a SNS topic which then handles adding the message to the SQS queue. This integration works fine.

Problem: The SNS topic always ends up failing to post to the SQS queue. I can see that the deadletter queue has the messages always and never the actual queue. This is the error message I found on CloudWatch

{
    "delivery": {
        "providerResponse": "{\"ErrorCode\":\"KMS.AccessDeniedException\",\"ErrorMessage\":\"null (Service: AWSKMS; Status Code: 400; Error Code: AccessDeniedException; Request ID: c)\",\"sqsRequestId\":\"Unrecoverable\"}",
        "dwellTimeMs": 51,
        "attempts": 1,
        "statusCode": 400
    },
    "status": "FAILURE"
}

I can see that KMS is denying access to something. But I'm not sure who is getting denied by KMS. The SNS topic has no encryption set. It is disabled. I initially enabled it, but after facing the problem, I disabled it. But the problem still persists.

What have I tried:

  1. I've tried disabling and enabling the encryption on SNS topic settings.
  2. I've tried looking at IAM roles associated with the SNS topic and SQS queue. Very few service roles were created and none of them have any restrictions.

Upvotes: 7

Views: 12708

Answers (1)

Sashi
Sashi

Reputation: 2867

As I was writing this question and crossing my t's and dotting my i's I stumbled upon the solution to my problem.

The encryption on the SQS queue side is configured from the Queue Actions (on SQS AWS Console) -> Configure Queue -> SSE section.

enter image description here

On the actual queue, the SSE option was selected with the default SQS KMS key while the dead letter queue had no setting and so could work without problems.

To solve this problem there are two possible solutions:

  1. Uncheck the SSE section to stop using KMS keys. Depending on your use case encryption may be needed for you.
  2. Create a separate key which you can share across SNS and SQS. By default the keys that are used by the two services cannot be shared.

Upvotes: 5

Related Questions