CloudTrail RunInstances 事件，当 STS AssumeRole 使用时，谁实际配置了 EC2 实例？

Question

我的客户需要 AWS 大扫除！

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

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

AWS blog 提供了一个虚构人物 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' 是一个自动缩放事件。

Answer 1

直接回答：

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

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

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

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

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

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

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

未来的一般准则：

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

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

我的建议是在开发环境中将权限授予用户自己，因为这样可以更轻松地跟踪问题并找到最有知识的人来解决问题。在生产环境中，一切都应该是自动化的（需要时创建，不再需要时删除），并且任何人都不应该对该帐户有任何写入权限。

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

再次祝你好运。