Home / server / Questions / 833775
Accepted
ALex_hha
Asked: 2017-02-21 12:11:47 +0800 CST

How to grant access to an SQS to a specific IAM user

  • 772

I need to create a really simple IAM policy and grant it to a specific queue. I need to grant access (it should be a full access) to the queue only to specific IAM user.

Because at the moment by default all IAM users with policy AmazonSQSFullAccess/AdministratorAccess can send/read message to/from the queue.

I have tried the following policies but without success

Policy 1

{
  "Version": "2012-10-17",
  "Id": "arn:aws:sqs:us-east-1:930XXXXXX332:task-queue/SQSDefaultPolicy",
  "Statement": [
    {
      "Sid": "Sid1487598389851",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "SQS:*",
      "Resource": "arn:aws:sqs:us-east-1:930XXXXXX332:task-queue",
      "Condition": {
        "ArnNotEquals": {
          "aws:SourceArn": "arn:aws:iam::930XXXXXX332:user/test-sqs"
        }
      }
    },
    {
      "Sid": "Sid1487599825058",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::930XXXXXX332:user/test-sqs"
      },
      "Action": "SQS:*",
      "Resource": "arn:aws:sqs:us-east-1:930XXXXXX332:task-queue"
    }
  ]
}

Policy 2 (the same as above but I have tried another condition)

"Condition": {
        "NotPrincipal": { 
             "AWS": "arn:aws:iam::930XXXXXX332:user/test-sqs" 
        }
  }

In other words - I need to get something like the following

Allow: user1, user2
Deny: *

Is it possible at all?

At the moment I have to explicitly specify each user within Deny effect. And this is extremely inconvenient

amazon-web-services

2 Answers

  1. Best Answer

    Finally I have found a workaround. With the policy below it works as expected

    {
  "Version": "2012-10-17",
  "Id": "arn:aws:sqs:us-east-1:930XXXXXX332:test-queue",
  "Statement": [
    {
      "Sid": "Sid1472529596416",
      "Effect": "Deny",
      "NotPrincipal": {
        "AWS": [
          "arn:aws:iam::930XXXXXX332:user/test-sqs",
          "arn:aws:iam::930XXXXXX332:root"
        ]
      },
      "Action": "SQS:*",
      "Resource": "arn:aws:sqs:us-east-1:930XXXXXX332:test-queue"
    }
  ]
}

    The crucial part is - you have to explicitly specify root account. Without it - it wouldn't work at all. As for me it's some AWS magic :) But may be someone could shed some light on the situation.

    Update 01.03.2017 It seems I have found the description of such behavior - http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#NotPrincipal

    In the following example, all principals except the user named Bob in AWS account 444455556666 are explicitly denied access to a resource. Note that to achieve the intended effect, the NotPrincipal element contains the ARN of both the user Bob and the AWS account that Bob belongs to (arn:aws:iam::444455556666:root). If the NotPrincipal element contained only Bob's ARN, the effect of the policy would be to explicitly deny access to the AWS account that contains the user Bob.

    A user cannot have more permissions than its parent account, so if Bob's account is explicitly denied access then Bob is also unable to access the resource.

    "Effect": "Deny",
"NotPrincipal": {
  "AWS": [
    "arn:aws:iam::444455556666:user/Bob",
    "arn:aws:iam::444455556666:root"
  ]
}

    Combining Deny and NotPrincipal is the only time that the order in which AWS evaluates principals makes a difference

    • 4

  2. The first part of the initial code fails because the condition is verified again the resource Arn, so you're essentially denying access to all queues. The second part should work, but an explicit access denyal always has precedence.

    The "policy 2" is wrong as again you'd give access to everybody but the user you need to give access to. But the global deny you used above still has precedence so no effect at all.

    I think your problem is at the very base of your current IAM settings - you should have never given such a wide access to your systems to all of your users. IAM works on an "allow what you strictly need" basis which is best for security. Instead you got youself tied into a "deny everything but what you need" which is hardly maintenable in IAM because of the "deny" statements always winning.

    The workaround for now is what you did - apply a deny policy to a group, and apply that group to all the users who shouldn't have access. But, as more queues might be created, you'll find yourself into a never ending loop of deny policies where you'll need to explicity set the names of all of your queues in the deny policies. And still - will that be secure or make sense? You said You've given to many users an administrator role - if they can modify their IAM policies, they can do everything - cloudtrail might tell you what happened, but won't bring your data back.

    I'd seriously suggest you to take a different approach instead, and define much more limited policies for your users. Create extra policies as needed and make them so what they are cumulative, attach them to groups and from the groups to the users. Take advantage of the wildcard on the arn values to eventually create "reserved" namespaces for your resources with more restricted access.

    • 0