SNS跨账户订阅，附加层答案

【问题标题】：SNS cross account subscription with additional layerSNS跨账户订阅，附加层
【发布时间】：2020-05-09 22:58:50
【问题描述】：

我们拥有一个 AWS 账户，账户 A。我们依靠外部团队向他们的 SNS 主题发布消息，该主题位于他们的账户 B 中。我们使用账户 A 中的 SQS 队列来订阅账户 B 中的 SNS 主题. 账户 A 已被账户 B 的所有者列入订阅 SNS 主题的白名单。

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

我们有没有办法通过在账户 A 中创建的 IAM 角色之类的方式，将账户 A 的权限委托或代理到我们正在创建的所有新账户？

【问题讨论】：

标签： amazon-web-services amazon-iam amazon-sns

【解决方案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 中运行，这可能是个问题。

【讨论】：

您能否说明帐户 C、D、E 将如何使用它？账户 A 是否可以向这些新账户委托或代理权限以使用账户 B 中的 SNS？
对于跨账户资源访问需要做 2 件事：1) 账户 B 向账户 A 用户授予权限。 2) 账户 A 中的用户（C、D、E）需要从账户 A 获得访问权限才能使用它（通过 IAM）。
在解决方案 #1 中，授予根用户权限允许该账户中的任何 IAM 用户拥有访问权限，只要有 IAM 语句允许他们这样做
在这个解决方案中，是role chaining used？我认为 Acc B 可以具有对其 SNS 的权限的角色。该角色可以由 Acc A 中的角色承担。Acc A 中的角色可以依次由其他帐户承担。随后，Acc A 只是 Acc B 中原始角色的代理。
不，不在我提供的解决方案中。我以前没有使用过，所以我不太确定用例，但这看起来像是一个临时解决方案（会话），不能解决问题。但是，在我的解决方案中，我只是说您可以将权限分配给 Acc A 根用户，这意味着 Acc A 创建的任何用户都可以获得访问权限。

【解决方案2】：

你现在的情况是：

您拥有的 Account-A 中的 Amazon SQS 队列 (Queue-A)
Account-B 中的 Amazon SNS 主题 (Topic-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 的 ARN 提供给拥有 Topic-B 的团队，并要求他们将这些队列添加为订阅者。这不需要对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"
        }
      }
    }
  ]
}

另见：

【讨论】：

不幸的是，由于我提到的外部团队的限制，我认为这不会奏效。有关更多上下文，我们正在创建的新帐户将是“开发人员”特定帐户，将用于部署单独的 AWS 堆栈以进行开发/测试。这意味着每次新开发人员加入团队时，外部团队都必须重复添加队列的步骤，而他们不会承诺。

【解决方案3】：

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

在 Account-A (Topic-A) 中创建您自己的 SNS 主题，您可以在其中管理订阅
创建一个将向Topic-A发送消息的AWS Lambda函数
将 Lambda 函数订阅到您现有的Queue-A，这样发送到Queue-A 的任何消息都将重新发送到Topic-A
让所有帐户都使用Topic-A，就好像它是Topic-B

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

【讨论】：