8

I have a queue from which messages are being read as soon as I send some message in it. I have not configured Dead Letter Queue, so messages should always be there if processing of sent message yields exception.

My code, which is a SpringBootApplication, listens to that queue and yields Exception when some wrong message is sent. Listening is done via JMS Listener.

After changing queue name, the same message stays there till I manually delete it. But in previous queue it gets deleted which I find really strange cause to my best knowledge I am not running my services anywhere.

I need to find out who is reading and deleting messages from my SQS. (IP Address, AWS credentials or something) Is there a way? I have heard of CloudTrail and trying to figure it out.

John Rotenstein
  • 241,921
  • 22
  • 380
  • 470
sian
  • 153
  • 1
  • 10

1 Answers1

0

You mention CloudTrail, which is indeed the correct service here to identify the IP and the identity.

That said, I would strongly recommend checking your queue permissions as well. You can do this in the AWS Console by viewing the SQS Queue, and clicking the Access Policy tab. In this sample, the user jbezos has permission to receive and delete messages. Details about these permission values is in the permissions reference

{
  "Version": "2008-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::${AWS::AccountId}:jbezos"
      },
      "Action": [ "sqs:DeleteMessage", "sqs:ReceiveMessage"]
      "Resource": "arn:aws:sqs:${AWS::Region}:${AWS::AccountId}:my-test-queue"
    }
  ]
}

Another valuable source of information here will be in your IAM (Identity and Access Management) service. Here, you can view the last activity for users and roles.

Armed with information about IAM users or roles have been active, and which have the required permissions to delete messages, you may be able to identify the cause.

Following this sort of exercise on a routine basis is a great way to ensure that access is maintained at an appropriate level. Many are surprised to find that a role or account is still active from a leftover project.

Brian
  • 4,921
  • 3
  • 20
  • 29