我需要创build一个非常简单的IAM策略并将其授予特定的队列。 我需要授予访问权限（它应该是一个完全的访问权限）到队列只有特定的IAM用户。
因为默认情况下，所有具有策略AmazonSQSFullAccess / AdministratorAccess的 IAM用户都可以向/从队列发送/读取消息。
我已经尝试了以下政策，但没有成功
政策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" } ] } 政策2 （同上，但我已经尝试了另一个条件）
"Condition": { "NotPrincipal": { "AWS": "arn:aws:iam::930XXXXXX332:user/test-sqs" } }
换句话说 – 我需要得到如下的东西
Allow: user1, user2 Deny: *
有没有可能？
目前，我必须明确指定每个用户在拒绝效果。 这是非常不方便的
最后，我find了一个解决方法。 有了下面的政策，它按预期工作
{ "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" } ] }
关键部分是 – 您必须明确指定root帐户 。 没有它 – 根本就不行。 至于我这是一些AWS魔术:)但也许有人可以对这种情况有所了解。
更新01.03.2017似乎我发现了这种行为的描述 – http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#NotPrincipal
在以下示例中，除了在AWS账户444455556666中名为Bob的用户之外的所有主体都被明确拒绝访问资源。 请注意，为了达到预期效果，NotPrincipal元素包含用户Bob和Bob所属的AWS账户（arn：aws：iam :: 444455556666：root）的ARN。 如果NotPrincipal元素仅包含Bob的ARN，则策略的作用是明确拒绝对包含用户Bob的AWS账户的访问。
用户不能拥有比其父帐户更多的权限，因此如果Bob的帐户被明确拒绝访问，那么Bob也无法访问资源。
"Effect": "Deny", "NotPrincipal": { "AWS": [ "arn:aws:iam::444455556666:user/Bob", "arn:aws:iam::444455556666:root" ] }
将Deny和NotPrincipal组合在一起是AWS评估委托人顺序的唯一时间
初始代码的第一部分失败，因为条件再次validation资源Arn，所以你基本上拒绝访问所有队列。 第二部分应该工作，但明确的访问密码总是优先。
“策略2”是错误的，因为您可以访问每个人，但您需要访问的用户也是如此。 但是，以上使用的全球否认仍然具有优先权，所以根本没有任何效果。
我认为你的问题在于你当前的IAM设置的基础 – 你应该从来没有给你所有的用户提供如此广泛的系统访问权限。 IAM在“允许你严格需要”的基础上工作，这对于安全来说是最好的。 相反，你把自己绑在一个“否认一切，但你需要的东西”，这在IAM中是难以维持的，因为“否认”陈述总是获胜。
目前的解决方法是您所做的 – 将拒绝策略应用于组，并将该组应用于所有不应访问的用户。 但是，随着更多的队列可能被创build，你会发现自己陷入了拒绝策略的永无止境的循环，你需要明确地设置拒绝策略中所有队列的名称。 还是 – 这将是安全的或有意义的？ 你说过你已经给了许多用户一个pipe理员angular色 – 如果他们可以修改他们的IAM策略，他们可以做所有事情 – cloudtrail可能会告诉你发生了什么事情，但不会带回你的数据。
我会认真地build议你采取不同的方法，并为用户定义更多有限的策略。 根据需要创build额外的策略，使它们成为累积的，并将它们附加到组和用户组。 利用arn值上的通配符最终为具有更多受限访问的资源创build“保留”命名空间。