4

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

  • Why don't you create a policy that grants access to that specific queue and attach it to a group which contains the users? – AWippler Feb 20 '17 at 20:17
  • Because as I have told before - every user with attached policy AmazonSQSFullAccess/AdministratorAccess will have access to the queue. And that is not acceptable. – ALex_hha Feb 20 '17 at 20:29
4

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

| improve this answer | |
0

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.

| improve this answer | |
  • You may consider that your answer would be vastly more readable if it were broken up into logical paragraphs. There's a reason your keyboard has an enter key. :) – EEAA Feb 20 '17 at 21:05
  • @EEAA definitely :) – stoned Feb 20 '17 at 21:06
  • @stoned Thanks , that make sense. Unfortunately the access was given before me. So now I have to suffer. P.S. it would be nice to have something similar to apache directive Order. When you can specify in which order Allow and Deny are evaluated. – ALex_hha Feb 20 '17 at 21:20
  • @ALex_hha not that big of a suffering - define a base policy that won't make your users cry and assign that to everyone, removing the unrestricted policies. Then add extra groups/policies depending on the resources you want to restrict. As said, you can define some "namespaces" for which you can define more of a free access - i.e. "devel*" named queues. The big job won't be in the AWS side - it will be in making people understand the benefits. – stoned Feb 20 '17 at 21:27
  • Yeah. Will bear in mind. Is there any possibility to setup aws (probably via sns/lambda) to send email when someone add a new user to AmazonSQSFullAccess/AdministratorAccess groups? – ALex_hha Feb 20 '17 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.