AWS IAM — может ли служба знать вызывающую ее роль?

Общая цель:

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

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

Проблема:

Если мы решим пойти по этому пути, может возникнуть желание по-прежнему блокировать параметры на основе разрешений IAM (ролей/политик). Я ищу способ в этой службе конфигурации, чтобы, возможно, захватить пользователя/роль, вызывающую службу конфигурации, и передать ее в хранилище параметров, например, при вызове ssm.getParameters(...).

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

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

Я использую node.js в Elastic Container Service, используя новый тип luanch Fargate, если это влияет на возможные ответы.


node.js amazon-web-services aws-ssm aws-sdk ssm
person ps2goat    schedule 16.01.2018    source источник
comment
Я сделал консольный дамп process, который включает переменные среды и т. д., но я ничего там не увидел.   -  person ps2goat    schedule 16.01.2018
comment
Экземпляр EC2 может определить имя роли с помощью метаданных. Это находится в разделе iam/info и iam/security-credentials. docs.aws.amazon.com/AWSEC2/latest/ Руководство пользователя/   -  person John Hanley    schedule 16.01.2018
comment
@JohnHanley Я просмотрел вашу ссылку и нашел несколько других способов, которые будут работать (а именно, этот с переменной окружения AWS_CONTAINER_CREDENTIALS_RELATIVE_URI). Однако это по-прежнему означает, что каждый сервис зависит от AWS, чтобы иметь возможность найти свою исполнительную роль. Я надеялся, что AWS сможет передать информацию в службу конфигурации, чтобы ей можно было доверять, а зависимость существовала только в одной службе.   -  person ps2goat    schedule 17.01.2018

Ответы (1)


arrow_upward
0
arrow_downward

Если вы хотите заблокировать параметр SSM для определенного микросервиса

  1. Создайте и прикрепите роль IAM для каждой задачи ECS.
  2. Организуйте свои параметры, используя нотацию path
  3. Для каждой роли IAM укажите Resource, чтобы ограничить доступ только для определенного пути (см. это). Это позволит вам иметь только определенные параметры, доступные для каждого микросервиса.

PS. если вы просто хотите получить текущую роль б/у aws sts get-caller-identity

Другое альтернативное решение:

  1. При вызове вашего config-service укажите имя microservice в запросе и создайте роли IAM, соответствующие имени microservice.
  2. Используйте aws sts assume-role в своем config-service, чтобы принять на себя роль IAM, которая будет доступна для микросервиса.
  3. Заблокируйте свой config-service, чтобы принимать только разрешенные роли.
person b.b3rn4rd    schedule 16.01.2018
comment
Это хороший момент, но потенциально много избыточности для шага 2. Например, расположение общего сервиса. Но все сводится к компромиссам, верно? Я не уверен, как применить шаг 3, если я не могу получить сквозную аутентификацию от вызывающей службы к хранилищу параметров (вызывающий -> служба конфигурации -> хранилище параметров). Я изучил STS и посмотрел, будет ли идентификатор работать для определения пути, если это необходимо. Спасибо за информацию. - person ps2goat; 17.01.2018
comment
@ ps2goat Я добавил еще одно потенциальное решение - person b.b3rn4rd; 17.01.2018
comment
Да, второе решение - это то, что я сейчас изучаю. - person ps2goat; 17.01.2018