CODEWITHSUNDEEP
amazon-web-servicesamazon-sqsamazon-sns
MadcowThaFirst
MadcowThaFirst

Reputation: 79

AWS default Access Policy SNS topics and SQS q's

In an attempt to further tighten the security of our solution we are now looking at the used SNS topics and SQS queues. All our components live in the same AWS account.

For starters we want to restrict the access to the SQS queues based on IP. So only requests coming from our NAT Gateway IP will be allowed. We don't allow anonymous access to our SQS queues.

But there seems no way to achieve this as the creator of the SQS queues - the AWS account id - has access per default. So you can't create an effective permission for another user in the same AWS account id. As this newly created user, user2, will fall under the same AWS account id, with the same set of permissions.

Am I correct in my understanding that all users in the same AWS account id have access per default to all created SQS queues as long as their IAM policy permits it? And is my assumption right that the same behavior goes for the SNS topics?

Below is the policy I would like the implement. Beside this policy I have no other policies active for this SQS q. But it is not honoring the source IP condition. I still can connect from everywhere when I use a correct AWS access key/secret combination. Only when I set the AWS principal to * - everyone - the policy seems effective.

{
  "Version": "2012-10-17",
  "Id": "arn:aws:sqs:eu-west-1:4564645646464564:madcowtestqueue/SQSDefaultPolicy",
  "Statement": [
    {
      "Sid": "Sid1589365989662",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::4564645646464564:user/user2"
      },
      "Action": [
        "SQS:DeleteMessage",
        "SQS:SendMessage",
        "SQS:ReceiveMessage"
      ],
      "Resource": "arn:aws:sqs:eu-west-1:143631359317:madcowtestqueue",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "1.1.1.1"
        }
      }
    }
  ]
}

Reference:

Upvotes: 1

Views: 17118

Answers (1)

John Rotenstein
John Rotenstein

Reputation: 270104

Amazon SQS

Amazon SQS has the ability to define Amazon SQS policies. These policies can be used in addition to IAM policies to grant access to a queue.

For example, a policy can be added that permits anonymous access to a queue, which is useful for external applications to send messages to the queue.

Interestingly, these policies can also be used to control access to the queue by IP address.

To test this, I did the following:

  • Created an Amazon SQS queue
  • Used an Amazon EC2 instance to send a message to the queue -- Successful
  • Added the following policy to the SQS queue:
{
  "Version": "2012-10-17",
  "Id": "Queue1_Policy_UUID",
  "Statement": [
    {
      "Sid": "Queue1_AnonymousAccess_AllActions_IPLimit_Deny",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "SQS:SendMessage",
      "Resource": "arn:aws:sqs:ap-southeast-2:xxx:queue",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": "54.1.2.3/32"
        }
      }
    }
  ]
}

The IP address is that of my Amazon EC2 instance.

  • I then tried send a message to the queue again from the EC2 instance -- Successful
  • I then ran the identical command from my own computer -- Not successful

Therefore, it would appear that the SQS policy can override the permissions granted via IAM.

(Be careful... I added a policy that Denied sqs:* on the queue, and I wasn't able to edit the policy or delete the queue! I had to use the root account to delete it.)

Amazon SNS

I managed to achieve the same result with Amazon SNS using this access policy:

{
  "Version": "2008-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Sid": "__default_statement_ID",
      "Effect": "Deny",
      "Principal": {
        "AWS": "*"
      },
      "Action": "SNS:Publish",
      "Resource": "arn:aws:sns:ap-southeast-2:xxx:topic",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": "54.1.2.3/32"
        }
      }
    }
  ]
}

Upvotes: 1

Related Questions