如何以编程方式列出所有aws资源和标记

jer*_*own 14 amazon-web-services

我想审核AWS中标记方案的合规性,因此我想以编程方式从帐户中检索所有资产并检查其标记.

有没有合理的方法来实现这一点,而无需迭代boto或Java API中的碎片aws客户端?如果我统计boto3客户端,其中大约有40个,其中大多数只有略微不同的语义.如果我确实编写了使用所有这些代码的代码,那么每当AWS角色化新服务时,我都必须添加另一个客户端.

我已经看过了:
boto3 - 40每个服务客户端迭代一些使得它不可行.
AWS Java客户端 - 如上所述
AWS cli - 与上面的
Compliance Monkey(Netflix)相同 - 仅查看Auto Scaling组
AWS Config - 您必须按标签查询资源,这些标记将无法跟踪未标记的内容.

我很快就会看到:
Netflix Edda

我现在所做的:
正是我不想要的,遍历boto3 cloudformation,ec2,s3和autoscaling clients.这比没有好,但这种方法存在明显差距.

小智 5

一直在努力让上面共享的脚本@whorka工作,但我认为必须更新skew扫描资源的方式.无论如何,下面的脚本似乎成功了!

    #!/usr/bin/env python
    import skew
    from skew.arn import ARN
    arn = ARN()
    services=arn.service.choices()
    services.sort()
    #services=["route53", "iam"]
    print('Enumerating all resources in the following services: ' + ' '.join(services) + '\n')
    for service in services:
      #skipping global services because the API endpoint fails due to it being a global service. Bug that needs fixing.
      if service == "iam" or service == "route53":
        print(service)  
        print('Skipping global services')
        #uri = 'arn:aws:' + service + '::*:*/*'
        #arn = skew.scan(uri)
        #for i in arn:
        #  print(i.arn)
      else:
        print('******' + service + '******')
        uri = 'arn:aws:' + service + ':*:*:*/*'
        arn = skew.scan(uri)
        for i in arn:
          print(i.arn)
Run Code Online (Sandbox Code Playgroud)

全局服务存在一个错误,例如IAM和Route53,因为API端点不包含导致barf倾斜的区域


Bes*_*ces 1

不幸的是,您想要的解决方案不存在。

请记住,AWS 不支持为其所有服务添加标签;所以你想要做的事情甚至可能是不可能的(如果你想要的是某种通用方法来查询所有服务并利用通用标签)。

现有的服务(如 RightScale 或如您所知的 Boto)在 AWS 之上提供了抽象。然而,与 AWS CLI 相比,这些第三方抽象在支持新服务之前总会有一段延迟时间。

如果您真正想要的是查询所有服务并处理当前不支持标记的服务的通用方法,建议您执行以下一项或全部操作:

  1. 在当前支持标记的所有服务中利用标记:ec2、rds
  2. 如果服务不支持标记,请利用资源名称添加相当于“标签”的内容,例如<component>-<environment>-<resource type>
  3. 编写一个小程序,包装/调用每个服务的所有单独的 aws cli。
  4. 在程序中,将每个 aws cli 命令的标签和资源名称转换为规范格式,存储在数据存储中,例如 dynamo、berkleydb
  5. 编写一个小程序,然后针对此数据存储中的数据进行“合规性检查”

当新服务上线时,请在步骤 3 中标记您的资源并扩展您的程序以支持新服务。请注意,最近大多数新的 AWS 服务都经历了公告期,然后是持续 6 个月或更长时间的预览期,例如弹性文件系统等。因此,通常情况下,您将有时间扩展您的计划以支持新服务。

另外,请记住,在您提到的“40 项服务”中,实际上只有一小部分可以“启动或标记”。这些服务中的大多数并不是真正的“资源”,例如AWS Config、CloudWatch、CloudTrail、SES、SNS、Data Pipeline。因此,看似必须执行的 API 数量很多,但最终可能会减少到 10 个或更少。