Question

我们拥有一个AWS账户（账户A）。我们依靠外部团队将消息发布到其账户B中的SNS主题。我们使用账户A中的SQS队列订阅账户B中的SNS主题帐户B的所有者已将帐户A列入白名单，以订阅SNS主题。

现在，我们想为多个（新）帐户订阅帐户B中的SNS主题。但是，拥有帐户B的团队无法手动将我们将要创建的许多帐户列入白名单。

是否可以通过帐户A中创建的IAM角色之类的方法，将帐户A的权限委派或代理到我们正在创建的所有新帐户中？

Answer 1

问题是帐户B试图向帐户A的特定用户授予权限。就像您提到的那样，如果您需要设置多个帐户，这可能是个问题。

您可以通过多种方式解决此问题。

帐户B授予帐户A的 root 权限。然后，帐户A具有将权限委派给任何IAM角色/用户的完全权限。这是一篇博客文章，其中包含这种设置方法https://aws.amazon.com/blogs/compute/cross-account-integration-with-amazon-sns/
在帐户A中创建一个IAM组，然后将用户分配给该组。然后，在帐户B中将权限授予帐户A的组，而不是特定用户。 Here is an example of providing access via groups

请注意，如果使用解决方案＃1，则帐户A中的任何IAM用户都将能够访问SNS资源。如果帐户A中正在运行多个应用程序，则可能是一个问题。

Answer 2

您当前的情况是：

您拥有的Queue-A中的Amazon SQS队列（Account-A）
别人拥有的Topic-B中的Amazon SNS主题（Account-B）
已向Topic-B添加了权限，该权限允许Account-A 订阅该主题

上面的方法效果很好。

新要求：

允许Account-C和Account-D订阅Topic-B
Account-B的所有者不希望修改Topic-B的权限以允许这些订阅请求

解决方案

请Account-C的所有者直接订阅新队列，而不是Account-D和Subscribe()发送Topic-B请求。

您说“拥有帐户B的团队没有能力将我们将要创建的许多帐户手动列入白名单。”

这是基于这样的想法，即Account-C和Account-D应该自己将订阅请求发送到Topic-B。相反，我建议您向拥有Queue-C的团队提供Queue-D和Topic-B的ARN，并要求他们将这些队列添加为订户。 不需要不需要更改Topic-B上的权限策略。

但是，有两点需要注意：

Queue-C和Queue-D需要确认订阅。最简单的方法是订阅主题后查看发送到队列的初始消息，复制消息中显示的订阅URL，然后将其粘贴到Web浏览器中。这是一个一次性的过程。
Queue-C和Queue-D将需要添加权限，以允许Topic-B将消息发送到他们的队列。您可能已经为Queue-A使用了此功能。该政策如下所示：

{
  "Version": "2012-10-17",
  "Id": "arn:aws:sqs:ap-southeast-2:ccc:my-queue/SQSDefaultPolicy",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "sqs:SendMessage",
      "Resource": "arn:aws:sqs:ap-southeast-2:ccc:my-queue",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:sns:ap-southeast-2:bbb:their-topic"
        }
      }
    }
  ]
}

另请参阅：

Answer 3

如果您不能依靠Account-B的所有者为您做任何事情，那么您唯一的选择是：

在帐户A（Topic-A）中创建自己的SNS主题，您可以在其中管理订阅
创建一个AWS Lambda函数，该函数将向Topic-A发送消息
将Lambda函数订阅到您现有的Queue-A上，以便发送给Queue-A的所有消息都将重新发送到Topic-A
让所有帐户都像使用Topic-A一样使用Topic-B

这样，您可以在控制下将现有的SQS队列（Queue-A）用作对新SNS主题（Topic-A）的“中继”。您还需要将当前从Queue-A开始使用的应用程序更改为从已订阅Topic-A的新队列使用。

具有附加层的SNS跨帐户订阅

3 个答案: