CloudTrail RunInstances, кто на самом деле подготовил экземпляр EC2 при использовании STS AssumeRole?

Моему клиенту нужна генеральная уборка AWS!

Прежде чем мы сможем закрыть инстансы EC2, нам нужно выяснить, кто их предоставил, и спросить, используют ли они инстанс до сих пор, прежде чем мы их удалим. AWS, похоже, не предоставляет готовых функций для сообщения о том, кто является «владельцем» / «поставщиком» экземпляра EC2, как я понимаю, мне нужно проанализировать кучу заархивированных заархивированных файлов журнала, находящихся в S3 .

Проблема в том, что их автоматизация использует STS AssumeRole для предоставления экземпляров. Это означает, что событие RunInstances в журналах не отслеживается до фактического пользователя (поправьте меня, если я ошибаюсь, пожалуйста, надеюсь, я ошибаюсь).

AWS blog представляет собой историю вымышленного персонажа Алисы и ее шагов по отслеживанию события TerminateInstance до пользователя, которое включает 2 события журнала: событие TerminateInstance и событие «где-то во времени» события AssumeRole, содержащего фактические данные пользователя. Есть ли прагматичный подход, который можно использовать для сопоставления этих двух событий?

Вот мой POC, который анализирует журнал cloudtrail с s3:

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

Однако детали являются общими, поскольку эти роли разделяют многие группы. Как я могу найти информацию о пользователе до того, как он примет роль в сценарии?

ОБНОВЛЕНИЕ: я провел небольшое исследование, и, похоже, я могу сопоставить событие Runinstances с событием AssumeRole с помощью общего «accessKeyId», и это должно показать мне имя учетной записи, прежде чем она примет роль. Однако сложно. Не все события RunInstances содержат этот accessKeyId, например, если 'invokedby' было событием автомасштабирования.


person buildmaestro    schedule 02.06.2017    source источник
comment
Я думаю, что у вас есть пробел в доступной информации. Как точно происходит AssumeRole? Запускает ли Мэллори (вымышленный враг Алисы и Боба) сценарий автоматизации на своей рабочей станции, используя свои учетные данные AWS для вызова AssumeRole? Или она подключается по SSH к машине на EC2, которая использует роль IAM, так что эту роль вообще не принимает человек? (С ролями экземпляра IAM именно инфраструктура EC2 вызывает AssumeRole, а затем делает полученные временные учетные данные доступными для экземпляра.)   -  person Michael - sqlbot    schedule 03.06.2017


Ответы (1)


Прямой ответ:

Для решения, которое вы предлагаете, вам, к сожалению, не повезло. Вы можете взглянуть на http://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html#w28aac22b9b4b7b3b1. В 4-й строке говорится, что предполагаемая роль будет сохранять идентификатор роли только для всех последующих вызовов.

Я бы связался со службой поддержки aws, чтобы убедиться в этом, так как вполне мог ошибаться.

Что бы я сделал в вашем случае:

Во-первых, подождите пару дней на случай, если у кого-то появилась идея получше или я ошибся, и aws support отвечает готовым решением.

  1. Создайте правило конфигурации aws, которое будет удалять все экземпляры с определенным тегом. Затем скажите своим разработчикам пометить все экземпляры, которые, как они уверены, должны быть удалены, тогда они будут удалены.
  2. Пометьте все производственные экземпляры и все еще необходимые экземпляры разработки собственным тегом.
  3. Запустите сценарий, который будет помечать все непомеченные экземпляры отдельным тегом. Дважды и трижды проверьте эти экземпляры.
  4. Создайте резервную копию и отключите экземпляры, отмеченные на шаге 3 (не удаляя экземпляры).
  5. Если кто-то пожаловался на то, что что-то не работает, это означает, что он пропустил экземпляр на шаге 1 или 2. Правильно пометьте этот экземпляр и включите его снова.
  6. Через некоторое время (неделю или около того) удалите экземпляры, которые все еще остановлены (сохраните резервные копии).
  7. Через пару месяцев удалите бэкапы, которые не восстановились

Обратите внимание, что это не является надежным, поскольку существует вероятность человеческой ошибки и возможного простоя, поэтому дважды и трижды проверьте, создайте клон той же среды и протестируйте ее (если у вас есть среда разработки, в которой уже есть такая конфигурация, это был бы лучший сценарий), не торопитесь, чтобы иметь возможность отслеживать все, и обязательно сохраняйте резервные копии всего.

Удачи и, пожалуйста, скажите мне, каким было ваше решение.

Общие рекомендации на будущее:

Примечание. Следующие пункты очень самонадеянны и представляют собой общие правила, которых я придерживаюсь, так как время от времени они избавляют меня от множества проблем. Прочитайте их, отбросьте то, что вы считаете непригодным для вас, и возьмите то, что вы считаете разумным.

  1. Не используйте предполагаемую роль слишком часто, так как это затрудняет доступ пользователя. В случае, если это был скрипт, запущенный на компьютере разработчика, пусть он запускается под его собственным именем пользователя. Если он работает на сервере, сохраните его с ролью, в которой он был создан. Объем управления будет меньше, так как вы просто уберете посредника (роль предполагаемого) и вам больше не нужно создавать роли, просто назначьте разрешения правильной группе/пользователю. Посмотрите ниже, когда я рассматриваю использование предполагаемой роли как необходимость.
  2. Автоматизируйте удаления. Первое, что вы должны создать, — это автоматизировать задачу поддержания учетной записи aws как можно более чистой, так как это сэкономит как $$$, так и усилия по отладке. Теги и сценарии для работы с этими тегами — очень мощные инструменты. Так что, если разработчику нужен инстанс на день, чтобы попробовать что-то новое, он может создать тег, который отключает инстанс, а затем есть скрипт, который очищает его, когда придет время. Они зависят от проекта, и не всем они нужны, поэтому посмотрите и оцените, что вам нужно для вашего проекта, и действуйте в соответствии с ними.

Я бы порекомендовал предоставить разрешения самим пользователям в среде разработки, поскольку это упростит отслеживание вещей до их корня и поиск наиболее знающего человека для решения проблем. Что касается производственной среды, то в любом случае все должно быть автоматизировано (создание, когда это необходимо, и удаление, когда оно больше не нужно), и ни у кого никогда не должно быть доступа для записи к этой учетной записи.

Что касается предполагаемой роли, я использую ее только в том случае, если хочу предоставить доступ к производственным журналам только для чтения в другой учетной записи. Другим случаем может быть что-то, что на самом деле не должно происходить так часто, если вообще должно происходить, но все же необходимо предоставить некоторым пользователям доступ к нему. Таким образом, в качестве дополнительного уровня защиты от «Я сделал это по ошибке», я заставляю их переключаться между ролями, чтобы сделать это, и никогда не использую сценарий, который автоматически переключает роли и выполняет действие, пытаясь сделать его как можно более преднамеренным. (подумайте об удалении базы данных и т. д.). Другое дело — доступ к конфиденциальной информации (база данных кредитных карт и т. д.). Может произойти много других сценариев, и здесь дело доходит до вашего суждения.

Еще раз, удачи.

person Ali Al Amine    schedule 02.06.2017
comment
просто хотел поблагодарить вас за описание рабочего процесса, если прагматичный подход не работает. Лучше не быть в этой ситуации, помечая вещи в первую очередь с помощью пунктов, которые вы упомянули. Спасибо, я включу это в свой отчет для руководства. - person buildmaestro; 03.06.2017