Несколько корневых учетных записей в одной организации AWS: администратор IAM не может видеть все экземпляры EC2 в указанном регионе

Question

Этот вопрос может показаться нудистским, но я вырываюсь из нашей организации AWS. У нас есть 3 отдельные корневые учетные записи, связанные в одной организации с учетными записями и политиками IAM. Мы можем видеть только экземпляры из учетной записи root по умолчанию в списке EC2 (да, я смотрю в правильном регионе). Мы предоставили полный доступ к аккаунту всем остальным аккаунтам и приняли приглашения. Наш биллинг работает отлично, и идет от нашего основного корневого аккаунта (и я вижу, что биллинг других отдельных аккаунтов в порядке). Даже наш самый высокий уровень администратора (буквально предоставляющий разрешение всем) не может видеть экземпляры, запущенные с одной из отдельных учетных записей root.

Наша цель - наша группа администраторов должна видеть экземпляры EC2 из всех трех корневых учетных записей в организации без смены учетных записей или учетных данных.

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

Answer 1

Здесь есть некоторые проблемы с терминологией. В организациях AWS нет корневых учетных записей или основных корневых учетных записей. Существует одна основная учетная запись AWS, а в учетной записи AWS - ноль или более участников.

Термин root относится к конструкции AWS Organizations внутри основной учетной записи, которая является родительским контейнером для всех учетных записей участников в вашей организации. Дополнительные сведения см. В разделе Терминология и концепции организаций AWS.

Есть два способа "присоединить" учетную запись участника к организации:

1. администратор в основной учетной записи создает новую учетную запись участника
2. администратор главной учетной записи приглашает существующую учетную запись стать участником

Если вы используете опцию № 1, вам автоматически предоставляется административный контроль над учетной записью участника через автоматически созданную роль IAM, которая называется OrganizationAccountAccessRole что вы можете использовать, чтобы предоставить пользователям в главной учетной записи администратора доступ к созданной учетной записи участника.

Если вы используете опцию № 2, вы автоматически не имеете полного административного контроля над учетной записью участника. Если вы хотите, чтобы основная учетная запись имела полный административный контроль над учетной записью приглашенного участника, необходимо создать OrganizationAccountAccessRole Роль IAM в учетной записи участника и предоставление разрешения основной учетной записи для принятия роли. Чтобы настроить это, после того, как приглашенная учетная запись станет участником, выполните действия, описанные в разделе Создание значения OrganizationAccountAccessRole в учетной записи приглашенного участника.

Answer 2

Ответ @jarmod дает хороший обзор терминологии. Я не думаю, что это решает твою проблему видимости.

Вы предполагаете, что основная учетная запись организации должна иметь возможность напрямую видеть все ресурсы всех учетных записей в организации через консоль AWS или через API. Это не правильно.

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

Чтобы узнать больше об организациях и их возможностях, вот несколько полезных ссылок:

• Документация по управлению разрешениями доступа для вашей организации AWS
• Услуги, которые можно использовать совместно с организациями

Ресурсы в учетной записи AWS логически принадлежат этой учетной записи, а не ее организации.