По большей части вы, вероятно, держите большую часть своей инфраструктуры AWS под одной учетной записью. Однако бывают ситуации, когда вам может потребоваться предоставить ресурсу или пользователю в другой учетной записи доступ к одному или нескольким вашим ресурсам. Это может быть связано с тем, что внешнему клиенту или поставщику требуется прямой доступ к вашей инфраструктуре, или потому, что инфраструктура вашей компании развернута в разных учетных записях. Действительно, AWS рекомендует использовать несколько учетных записей как лучший метод масштабирования облачной среды. Поскольку он обеспечивает изоляцию биллинга и безопасности, а также обеспечивает гибкость.
Тем не менее, предоставление доступа к кросс-аккаунту может быть непростой задачей. Конечно, мне потребовалось время, чтобы разобраться в шаблоне, которому я должен был следовать, чтобы последовательно установить доверительные отношения между учетными записями AWS.
В этой статье я собираюсь объяснить простой рецепт, которому вы можете следовать, чтобы убедиться, что вы настроили правильные разрешения, чтобы разрешить доступ между аккаунтами к вашим ресурсам AWS. Основная часть примера будет в CloudFormation, но принцип применим независимо от того, используете ли вы консоль AWS напрямую или инфраструктуру как код, используя CloudFormation или Terraform.
Немного терминологии
Если вы профессионал в области AWS, возможно, вы захотите пропустить этот раздел. В противном случае, вот некоторые ключевые термины, на которые мы будем ссылаться ниже.
- Аккаунт: аккаунт AWS - это контейнер для ваших ресурсов AWS. Вы создаете свои ресурсы AWS и управляете ими в учетной записи AWS, а учетная запись AWS предоставляет административные возможности для доступа и выставления счетов.
- Ресурс: объект, с которым пользователи могут работать в AWS, например экземпляр EC2, таблица Amazon DynamoDB, корзина Amazon S3, пользователь IAM и т. д. . По сути, все, что вы считаете продуктом AWS, является ресурсом.
- Действие: функция API. Также называется операцией или вызовом. Деятельность, на которую доверитель имеет разрешение. Например, Джейн отправляет запрос в Amazon SQS с Action = ReceiveMessage.
- Роль: инструмент для предоставления временного доступа к ресурсам AWS в вашей учетной записи AWS.
- Политика: документ, определяющий разрешения, которые применяются к пользователю, группе или роли; разрешения, в свою очередь, определяют, что пользователи и ресурсы могут делать в AWS. Политика обычно разрешает доступ к определенным действиям и может дополнительно разрешать действия для определенных ресурсов. Политики также могут явно запрещать доступ.
- Субъект: пользователь, служба, роль или учетная запись, получающие разрешения, определенные в политике.
Во фразе: «У A есть разрешения делать от B к C, где применяется D».
A = Принципал
B = Действие
C = ресурс
D = Политика
Что означает кросс-счет? Мотивирующий пример
НАСА считает, что они нашли доказательства жизни на Марсе. Их космический телескоп Хаббл уловил странные микроволновые сигналы, исходящие с планеты. Как специалист в области данных / физик мирового класса, вас пригласили опробовать ваши алгоритмы на данных, чтобы проверить гипотезу.
К сожалению, данные слишком важны, чтобы просто отправлять их вам. Однако они предоставят вам временные разрешения только на чтение для своей базы данных.
Платформа для настройки доверия
В каждой ситуации, связанной с разрешениями на несколько аккаунтов, у нас есть Доверенные и Доверенные аккаунты. В нашем примере; Учетная запись НАСА AWS является учетной записью Доверяя (например, они доверяют вам доступ к своему ресурсу). Ваш аккаунт AWS является доверенным (например, вам доверен доступ к их ресурсам).
Самый простой способ доверить доступ к ресурсу из другой учетной записи - разрешить доверенной учетной записи разрешить доверенной учетной записи взять на себя роль, политика (или политики) которой ограничены только необходимыми действиями на необходимые ресурсы. Как и всякая конфигурация в облаке, разрешения всегда должны быть настолько ограничены, насколько это практически возможно (без подстановочных знаков, пожалуйста!).
Чтобы вернуться к нашему примеру, НАСА потребуется создать роль, которая имеет разрешения только на чтение для одной таблицы и которая может быть принята только вашей службой.
Вот что нам нужно
- НАСА создает роль SecretMarsDataReadOnlyRole.
- НАСА назначает политику SecretMarsDataReadOnlyRole, чтобы указать, что он может читать из таблицы.
- Вы создаете (или повторно используете) роль, под которой работает ваша служба, мы назовем эту роль NumberCrunchingServiceRole.
- Вы добавляете политику к своей NumberCrunchingServiceRole, чтобы позволить ей выполнять действие sts: AssumeRole для роли SecretMarsDataReadOnlyRole.
- НАСА добавляет свойство AssumeRolePolicyDocument в SecretMarsDataReadOnlyRole, которое указывает, что NumberCrunchingServiceRole может принимать SecretMarsDataReadOnlyRole.
- Наконец, ваша служба явно принимает на себя эту роль, вызывая STS (Secure Token Service) для получения временных учетных данных, прежде чем инициализировать клиента для чтения из таблицы НАСА. Подробнее об этом ниже.
Заметьте, я ничего не сказал о том, что это за служба, или о том, в какой тип таблицы NASA хранит свои данные. Эта структура не зависит от этих деталей реализации. Действительно, этот фреймворк подойдет для любого сервиса. Это может быть лямбда-выражение, которому необходимо читать из очереди, или пакетное задание, которому требуется доступ к корзине S3. Возможно, вы даже как разработчик берете на себя роль и вызываете сервис AWS из командной строки. Применяются те же шаги. Вы создаете роль в доверенной учетной записи с необходимыми разрешениями и позволяете роли в доверенной учетной записи принимать эту роль.
Принимая на себя роль
Я говорил о принятии на себя роли, и интуитивно вы, наверное, знаете, что я имею в виду. Однако давайте конкретизируем.
Когда принципал принимает на себя роль IAM, он получает набор временных учетных данных безопасности, которые имеют разрешения, связанные с ролью, которую он принял.
Опять же, используя наш пример, последовательность событий выглядит как на диаграмме ниже. Чтобы проиллюстрировать последовательность; Я выбрал EC2 в качестве вычислительной среды, в которой работает ваша служба, и DynamoDB в качестве базы данных, которую использует НАСА. Повторюсь, это всего лишь детали реализации.
Шаги 2 и 3 будут зависеть от того, на каком языке написана ваша Служба обработки чисел. Я покажу пример на Python и сделаю ссылку на документы. Надеюсь, должно быть очевидно, как реализовать вызов роли STS на выбранном вами языке.
Вызов STS и инициализация клиента
Это единственное изменение кода, которое вам нужно. Теперь у вас есть клиент, который обращается к столу НАСА и готов получить данные, необходимые для проведения анализа. Ну, почти…
Вы могли заметить, что я еще не показал вам, как выглядят SecretMarsDataReadOnlyRole и NumberCrunchingServiceRole. Очевидно, что это информация, которая нам нужна, поскольку роли должны быть развернуты, чтобы знать роль ARN, которую вам нужно принять. Итак, без лишних слов, давайте взглянем на ямл!
CloudFormation Goodness
SecretMarsDataReadOnlyRole
Это роль, которую НАСА создает для учетной записи Доверяя. Цель этой роли - указать только разрешения, необходимые для доступа к ресурсу, и разрешить выполнение этой роли вашей роли службы в Доверенной учетной записи.
Число CrunchingServiceRole
Это ваша роль в задаче (в Доверенной учетной записи), связанной со службой, которой необходим доступ к данным НАСА, размещенным в учетной записи Доверенная.
Помните, что это наглядный пример. Ваши шаблоны CloudFormation будут немного отличаться в зависимости от служб, которые вы хотите использовать в доверенных и доверенных учетных записях.
Настройка доверия между аккаунтами из консоли AWS
Во многих отношениях это намного проще. Применяется та же структура, только вы создадите нужные роли с помощью панели управления IAM. Затем вам нужно будет отредактировать их доверительные отношения, чтобы указать, какие роли могут принимать на себя созданную вами роль доступа к ресурсам.
Заключение
Вот и все. Всего 2 роли с парой политик и крошечным изменением кода. Надеюсь, этот пример был полезен, но помните, что одна и та же структура будет работать независимо от задействованных служб.
Все, что вам нужно, это роль доступа к ресурсам в учетной записи Trusting со свойством AssumeRolePolicyDocument , роль в Trusted учетной записи с политикой, дающей ей разрешения на вызов STS для получения роли доступа к ресурсам и, наконец, некоторый код для инициализации клиента службы с вашими временными учетными данными.
Я инженер-программист в компании Skyscanner в Лондоне. Я также являюсь соучредителем inHouse, приложения, которое помогает соседям по дому избавиться от проблем, связанных с совместной жизнью, помогая им согласовывать счета и расходы в одном месте.
