【问题标题】:AWS CloudFormation IAM policy and SQS policy seems to have similar settings, but not sure why?AWS CloudFormation IAM 策略和 SQS 策略似乎有类似的设置,但不知道为什么?
【发布时间】:2014-10-25 22:15:26
【问题描述】:

我是 AWS CloudFormation 的新手,我正在尝试找出一些预先存在的 CloudFormation JSON。我已经阅读了很多次文档,但我似乎最终得到的问题多于答案。

以下是我的 CloudFormation 文件的修改版本。我试图从 CloudFormation 示例中尽可能多地删除,以希望减少视觉噪音。我很感激读者不知道为什么要完成某些事情的原因,但我希望我的问题(如下)能够突出关于如何编写 CF 的一个更基本的问题。

CF JSON 创建一个 SQS 队列、一个 SQS 队列策略和一个 IAM 策略。

SQS 队列策略允许对 SQS 队列进行完整的 API 访问(它还通过条件限制对某些 IP 地址的访问)并且似乎将这些权限分配给队列本身。

但我们也有一个似乎做类似事情的 IAM 政策?它分配特定的 SQS 队列权限,但这次分配给角色,而不是像 SQS 队列策略似乎正在做的那样分配给队列本身。

我的问题是为什么重复?我们能否将访问权限应用到 SQS 队列策略并删除“QueuesPolicy”IAM 策略?

我可以理解为什么 IAM 策略“QueuesPolicy”会设置 SQS 队列访问权限:因为您可以有多个角色访问单个队列,并且您希望他们拥有不同的权限集(而不是队列具有所有角色的具体权限集)。但如果是这种情况,那么为什么还要在队列上设置权限呢?这看起来像是一个错误还是被用作某种“后备”?

我还假设我们可以保留 SQS 队列策略,但只需删除 API 权限并保留限制其对某些 IP 地址的访问的能力。这在这个例子中可行吗?

此外,AWS::IAM::Role 让我感到困惑,因为我不确定我是否理解它在做什么。似乎表明 EC2 实例将能够假设 FooRole,对吗?我猜我们只有一组 AWS 凭证,在 EC2 实例上运行的应用程序很可能会使用这些凭证来访问我们的 AWS 账户,但由于没有单独的“用户”,我们将 需要 创建一个角色,并且 EC2 实例有权访问该角色以获得授权请求(例如从应用程序向队列发送消息)?

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Resources": {
    "EC2ComponentPolicy": {
      "Type": "AWS::IAM::Policy",
      "Properties": {
        "PolicyName": "EC2ComponentPolicy",
        "PolicyDocument": {
          "Statement": [
            {
              "Action": [
                "cloudformation:Describe*"
              ],
              "Resource": [
                "*"
              ],
              "Effect": "Allow"
            },
            {
              "Action": [
                "ec2:Describe*"
              ],
              "Resource": [
                "*"
              ],
              "Effect": "Allow"
            }
          ]
        },
        "Roles": [
          {
            "Ref": "FooRole"
          }
        ]
      }
    },
    "SQSFooQueue": {
      "Type": "AWS::SQS::Queue",
      "Properties": {
        "MessageRetentionPeriod": 86400,
        "VisibilityTimeout": {
          "Ref": "VisibilityTimeout"
        }
      }
    },
    "ComponentInstanceProfile": {
      "Type": "AWS::IAM::InstanceProfile",
      "Properties": {
        "Path": "/",
        "Roles": [
          {
            "Ref": "FooRole"
          }
        ]
      }
    },
    "SQSFooQueuePolicy": {
      "Type": "AWS::SQS::QueuePolicy",
      "Properties": {
        "Queues": [
          {
            "Ref": "SQSFooQueue"
          }
        ],
        "PolicyDocument": {
          "Version": "2012-10-17",
          "Id": "SQSFooQueuePolicy",
          "Statement": [
            {
              "Resource": [
                {
                  "Fn::GetAtt": [
                    "SQSFooQueue",
                    "Arn"
                  ]
                }
              ],
              "Effect": "Allow",
              "Sid": "Allow-User-SendMessage",
              "Action": [
                "sqs:*"
              ],
              "Condition": {
                "IpAddress": {
                  "aws:SourceIp": [
                    "xxx.xx.xxx.x/xx",
                    "xxx.xx.xxx.x/xx",
                    "xxx.xx.xxx.x/xx"
                  ]
                }
              },
              "Principal": {
                "AWS": "*"
              }
            }
          ]
        }
      }
    },
    "QueuesPolicy": {
      "Type": "AWS::IAM::Policy",
      "Properties": {
        "PolicyName": "QueuesPolicy",
        "PolicyDocument": {
          "Statement": [
            {
              "Action": [
                "sqs:AddPermission",
                "sqs:ChangeMessageVisibility",
                "sqs:ChangeMessageVisibilityBatch",
                "sqs:CreateQueue",
                "sqs:DeleteMessage",
                "sqs:DeleteMessageBatch",
                "sqs:DeleteQueue",
                "sqs:GetQueueAttributes",
                "sqs:GetQueueUrl",
                "sqs:ListQueues",
                "sqs:ListDeadLetterSourceQueues",
                "sqs:ReceiveMessage",
                "sqs:RemovePermission",
                "sqs:SendMessage",
                "sqs:SendMessageBatch",
                "sqs:SetQueueAttributes"
              ],
              "Resource": [
                {
                  "Fn::GetAtt": [
                    "SQSFooQueue",
                    "Arn"
                  ]
                }
              ],
              "Effect": "Allow"
            }
          ]
        },
        "Roles": [
          {
            "Ref": "FooRole"
          }
        ]
      }
    },
    "FooRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "Path": "/",
        "AssumeRolePolicyDocument": {
          "Statement": [
            {
              "Action": [
                "sts:AssumeRole"
              ],
              "Effect": "Allow",
              "Principal": {
                "Service": [
                  "ec2.amazonaws.com"
                ]
              }
            }
          ]
        }
      }
    }
  }
}

【问题讨论】:

  • 似乎 Statement必须 有一个 Action 键,这可以解释为什么在 SQS 队列策略中它包含了似乎与操作重复的内容.但是昨天有人向我解释说,Condition 实际上是在说“将对 SQS 队列资源的访问限制为这些 ip 集并让这些 ip 具有完全访问权限”
  • 我也有类似的问题,发现此文档很有帮助:docs.aws.amazon.com/AWSSimpleQueueService/latest/…

标签: amazon-web-services amazon-sqs amazon-cloudformation


【解决方案1】:

我将尝试按顺序回答您的问题,但首先给出我对这个 sn-p 的一般解释。这可能是基于 AWS 的应用程序的模板,该应用程序将在与 sn-p 中的角色绑定的实例配置文件下运行,并将使用 SQS 与已知 IP 范围内的某些云外系统集成。大概它会被更新以使用 SDK,但显然不能像通过元数据端点那样容易地获取临时凭据。

  1. 队列策略和 IAM 策略资源引用同一个队列,但它们似乎并不多余。一个用于匿名用户(IAM 策略无法实现),另一个用于您的 EC2 实例。

  2. 您可以扩展队列策略以涵盖这两种明显的需求,但我个人更喜欢以主体为中心的 IAM 策略。同样,我会使用旧版 S3 控制选项,例如,仅当您无法使用 IAM 策略时。但这主要是一种偏好,除非您必须使用资源绑定策略。

【讨论】:

    猜你喜欢
    • 2014-05-02
    • 2017-11-21
    • 1970-01-01
    • 2018-04-13
    • 2017-06-09
    • 2016-06-05
    • 2012-07-20
    • 2021-10-30
    • 2020-03-11
    相关资源
    最近更新 更多