来自账户 A 的 AWS Cloudwatch 警报无法发布到账户 B 中的 SNS 主题

Posted 2023-02-18

【中文标题】来自账户 A 的 AWS Cloudwatch 警报无法发布到账户 B 中的 SNS 主题

【英文标题】：AWS Cloudwatch alarm from Account A unable to publish to SNS topic in Account B

【发布时间】：2020-09-10 22:20:38

【问题描述】：

就在我以为我已对跨组织权限进行排序时，我被 CloudWatch 警报和 SNS 卡住了。 尝试了几种选择，但无法获得有关 SNS 主题的访问策略。 Cloudwatch 和 SNS 主题在同一区域，但在同一组织中的不同帐户。当然，我不需要中间的 lambda 来管理它，AWS 现在已经为 CloudWatch 提供跨组织支持。我尝试过以下几个选项。

SNS 主题在帐户 A = 1111111111 中 Cloudwatch 警报在账户 B = 22222222

选项 1 - 账户 B 拥有 SNS 主题的发布权限

    "Sid": "__console_pub_0",
    "Effect": "Allow",
    "Principal": 
      "AWS": [
        "arn:aws:iam::111111111111:root",
        "arn:aws:iam::222222222222:root"
      ]
    ,
    "Action": "SNS:Publish",
    "Resource": "arn:aws:sns:us-east-1:111111111111:alerttopicname"
  

选项 2 - 授予 Cloudwatch 服务访问权限以发布到 SNS 主题

 
        "Sid": "Allow_Publish_Alarms",
        "Effect": "Allow",
        "Principal":
        
            "Service": [
                "cloudwatch.amazonaws.com"
            ]
        ,
        "Action": "sns:Publish",
        "Resource": "arn:aws:sns:us-east-1:111111111111:alerttopicname"
    

选项 3 - 跨组织权限，我也更新了账户 B 中的 IAM 角色

 
       "Sid": "CrossOrgPublish01",
       "Effect": "Allow",
       "Principal": 
          "AWS": "*"
       ,
       "Action": "SNS:Publish",
       "Resource": "arn:aws:sns:us-east-1:111111111111:alerttopicname",
       "Condition": 
          "ArnLike": 
             "aws:SourceArn": "arn:aws:cloudwatch:us-east-1:222222222222:alarm:*"
          
       
    

【参考方案1】：

选项 3 是正确的。但是，这不是 Acc B 中的不是 IAM 角色。它应该作为声明添加到 Acc A 的主题策略中。

假设您在 Acc A 中有一个默认主题策略，在添加新语句后，您将：

ACC A 中的 SNS 主题政策

  "Version": "2008-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    
      "Sid": "__default_statement_ID",
      "Effect": "Allow",
      "Principal": 
        "AWS": "*"
      ,
      "Action": [
        "SNS:Publish",
        "SNS:RemovePermission",
        "SNS:SetTopicAttributes",
        "SNS:DeleteTopic",
        "SNS:ListSubscriptionsByTopic",
        "SNS:GetTopicAttributes",
        "SNS:Receive",
        "SNS:AddPermission",
        "SNS:Subscribe"
      ],
      "Resource": "arn:aws:sns:us-east-1:111111111111:alerttopicname",
      "Condition": 
        "StringEquals": 
          "AWS:SourceOwner": "111111111111"
        
      
    ,       
    
       "Sid": "CrossOrgPublish01",
       "Effect": "Allow",
       "Principal": 
          "AWS": "*"
       ,
       "Action": "sns:Publish",
       "Resource": "arn:aws:sns:us-east-1:111111111111:alerttopicname",
       "Condition": 
          "ArnLike": 
             "aws:SourceArn": "arn:aws:cloudwatch:us-east-1:222222222222:alarm:*"
          
       
    

  ]

【讨论】：

很抱歉，澄清该政策适用于 SNS 主题，而不是 IAM 角色。我将捕获您上面的策略，它看起来与我目前作为 SourceOwner 所建议的故障排除非常相似。

@RobQlder 不必担心“此 IAM 用户无权访问此帐户的 SNS 主题和订阅。”消息。该消息与您的 IAM 用户有关，而不是服务。忽略它，通过实际触发警报来检查，从 OK 进入 ALARM 状态。

啊，好吧，这解释了奇怪的 IAM 用户参考。我使用的其他指标也没有改变。账户 2 中的 CloudWatch 警报处于正常状态，但表示无法验证 SNS，因为它在另一个账户中。我已经配置了跨组织 cloudwatch。当我通过帐户 1 中的控制台查看此警报时，状态正常，但显示“未找到 SNS 主题”。我可能会尝试触发此警报，以查看发生了什么以及记录了什么。我已经通过直接发布测试了 SNS。

@RobQlder 手动测试一下。您可以使用set-alarm-state 触发警报。它必须改变状态。所以它只会从状态改变 OK->ALARM 触发。处于警报状态不会触发它。

AWS 现在严重吗！！好的，这很有效，非常感谢 Marcin 和 mokugo-devops 帮助我。因此，控制台 GUI 仍然在多个位置显示“找不到主题”或“此 IAM 用户无权访问此帐户的 SNS 主题和订阅”的问题。但它确实有效....而且可能在几个小时前就有效了！！！好吧好吧，所以今天我学会了在假设它们不起作用之前不要相信控制台错误消息和测试功能。感谢您的耐心等待。

【参考方案2】：

选项 3 应该按照 AWS documentation 工作，但你说它们在同一个区域。

在这方面，它们是不同的区域。一个是 us-east-1 一个是 us-east-2。它们共享同一个区域很重要。

还要验证选项 3 应该是 SNS 主题策略，而不是 IAM 用户或角色。

要对此进行修改，请转到控制台中的 SNS 主题，选择编辑，然后添加到“访问策略”部分中的语句。

【讨论】：

嗯，我确信我在北弗吉尼亚创建了这两个。显然不是 - 让我清理一下，让他们都在 us-east1 中，然后再试一次。

哦，请查看AWS doco 选项 2。

啊，这将是主题策略，但这只会授予来自同一账户中 CloudWatch 的访问权限

好的，所以 SNS 和 Cloudwatch 都在 us-east-1 中，我更新了策略选项 3 以更正我的错字。 CloudWatch 仍然不高兴，告诉我“此 IAM 用户无权访问此帐户的 SNS 主题和订阅。”

将其更新为选项 3