0

我的客户需要 AWS 大扫除！

在我们可以终止 EC2 实例之前，我们需要找出谁提供了这些实例，并在我们删除它们之前询问他们是否仍在使用该实例。AWS 似乎没有提供开箱即用的功能来报告 EC2 实例的“所有者”/“供应商”是谁，据我了解，我需要解析驻留在 S3 中的归档压缩日志文件.

问题是，他们的自动化是利用 STS AssumeRole 来提供实例。这意味着日志中的 RunInstances 事件不会追溯到实际用户（如果我错了，请纠正我，希望我错了）。

AWS 博客提供了一个虚构人物 Alice 的故事，以及她将 TerminateInstance 事件追溯到用户的步骤，该事件涉及 2 个日志事件：TerminateInstance 事件和包含实际用户详细信息的 AssumeRole 事件的“某时某时”事件. 是否有一种实用的方法可以将这两个事件关联起来？

这是我的 POC，它通过来自 s3 的 cloudtrail 日志进行解析：

import boto3
import gzip
import json 

boto3.setup_default_session(profile_name=<your_profile_name>)
s3 = boto3.resource('s3')
s3.Bucket(<your_bucket_name>).download_file(<S3_path>, "test.json.gz")
with gzip.open('test.json.gz','r') as fin:
   file_contents = fin.read().replace('\n', '')
   json_data = json.loads(file_contents)
   for record in json_data['Records']:
        if record['eventName'] == "RunInstances":
            user = record['userIdentity']['userName']
            principalid = record['userIdentity']['principalId']
            for index, instance in enumerate(record['responseElements']['instancesSet']['items']):
                print "instance id: " + instance['instanceId']
                print "user name: " + user
                print "principalid " + principalid

然而，细节是通用的，因为这些角色由许多组共享。如何在脚本中担任角色之前找到用户的详细信息？

更新： 做了一些研究，看起来我可以通过共享的“accessKeyId”将 Runinstances 事件与 AssumeRole 事件相关联，并且应该在它承担角色之前向我显示帐户名称。虽然很棘手。并非所有 RunInstances 事件都包含此 accessKeyId，例如，如果“invokedby”是一个自动缩放事件。

4

1 回答 1

0

直接回答：

对于您提出的解决方案，不幸的是您不走运。您可以查看http://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html#w28aac22b9b4b7b3b1。在第 4 行，它表示 Assume Role 将仅为所有后续调用保存角色身份。

我会联系 aws 支持以确保这一点，因为我很可能会弄错。

在你的情况下我会做什么：

首先，等待几天以防有人有更好的想法或我弄错了，aws 支持使用开箱即用的解决方案提供答案

  1. 创建一个 aws config 规则，该规则将删除具有特定标签的所有实例。然后告诉您的开发人员标记他们确定应该删除的所有实例，然后这些实例将被删除
  2. 用自己的标签标记所有生产实例和仍然需要的开发实例
  3. 运行一个脚本，该脚本将使用单独的标签标记所有未标记的实例。双重和三重检查这些实例。
  4. 备份并关闭在步骤 3 中标记的实例（不删除实例）。
  5. 如果有人抱怨某事没有开启，这意味着他们错过了第 1 步或第 2 步中的实例。正确标记此实例并再次打开它。
  6. 一段时间后（一周左右），删除仍然停止的实例（保留备份）
  7. 几个月后，删除未恢复的备份

请注意，这并不是万无一失的，因为它可能会出现人为错误和停机时间，因此请进行双重和三重检查，克隆相同的环境并对其进行测试（如果您的开发环境已经具有这样的配置，那将是最好的情况），慢慢来能够监控一切，并确保保留一切的备份。

祝你好运，请告诉我你的解决方案最终是什么。

未来的一般指导方针：

注意：以下几点非常自以为是，并且是我遵守的一般规则，因为我发现它们有时会为我省去很多麻烦。阅读它们，将您认为不适合您的内容视为不适合的内容，并接受您认为合理的内容。

  1. 不要经常使用承担角色，因为它会混淆用户访问。如果它是在开发者的电脑上运行的脚本，让它使用他们自己的用户名运行。如果它在服务器上运行，请保留创建它的角色。管理量会更少，因为您只需切断中间人（假设角色）并且不再需要创建角色，只需将权限分配给正确的组/用户。看看下面什么时候我会考虑使用假设角色作为必需品。
  2. 自动删除。您应该创建的第一件事是自动化保持 aws 帐户尽可能干净的任务，因为这将节省 $$$ 和调试痛苦。标签和作用于这些标签的脚本是非常强大的工具。因此，如果开发人员需要一天的实例来尝试新事物，他可以创建一个标记来使实例超时，然后有一个脚本可以在时间到来时清理它。这些是特定于项目的，并不是每个人都需要所有这些，因此请查看并评估您的项目需要什么并采取行动。

我建议在开发环境中将权限授予用户自己，因为这将使跟踪事情到他们的根目录并找到最有知识的人来解决问题更容易。在生产环境中，一切都应该是自动化的（需要时创建，不再需要时删除），并且任何人都不应该对该帐户具有任何写入权限。

至于承担角色，我仅在我想授予对另一个帐户的只读生产日志的访问权限时使用它。另一种情况是确实不应该经常发生的事情，如果有的话，但仍然需要让一些用户访问它。因此，作为防止“我做错了”的额外保护层，我让他们切换角色来做这件事，并且永远不会有一个脚本自动切换角色并执行操作以试图使其尽可能深思熟虑（考虑删除数据库等）。另一件事是访问敏感信息（信用卡数据库等）。可能会发生更多的情况，这取决于您的判断。

再次，祝你好运。

于 2017-06-02T01:57:07.637 回答