Блог

Вот пример использования. У меня есть экземпляр EC2, на котором запущен агент среднего сервера ServiceNow. К экземпляру EC2 прикреплена IAM_Role, называемая «TestIAMRole», и предполагается, что к роли привязана политика роли. Я использую этот экземпляр EC2 и агент ServiceNow mid-server для вызова конечных точек VPC с использованием конечных точек AWS boto3. Скрипт Python сгенерирует токен аутентификации с использованием boto3 SDK и вызовет конечную точку.

Пример Python:

     import boto3
    client = boto3.client('sts')
    repsonse = client.assume_role(RoleArn='<IAM ROle ARN>',RoleSessionName='AssumeROle01')
    credentials=repsonse['Credentials']
  

Затем, используя Python request, мы вызываем конечные точки VPC, и это работает нормально.

Поскольку мы запускаем агент на экземпляре EC2, мы подумали о другом подходе к использованию метаданных экземпляра EC2 с использованием локальной конечной точки https с использованием curl, он возвращает access_key, secret_key и session_token

 http://169.254.169.254/latest/meta-data/iam/security-credentials/TestIAMRole
  

Итак, мы ищем мнение экспертов о том, какой из двух вышеупомянутых вариантов является наиболее безопасным / рекомендуемым.

Также несколько вопросов по оптимизации

1. Если мы используем метод assume role STS для извлечения учетных данных, рекомендуется ли хранить их в кэше / приложении до истечения срока действия, чтобы мы могли их повторно использовать, или нам следует получать новые учетные данные sts каждый раз, когда мы обращаемся к другим сервисам AWS? Просто пытаюсь сохранить дополнительный вызов STS при каждом вызове службы AWS.
2. если возможно сохранение в кэше или приложении, тогда мы можем надежно хранить ключ в ServiceNow (зашифрованный формат) и можем регулярно обновлять его до истечения срока действия.

Пожалуйста, сообщите, правильный ли это способ.

Это почти одно и то же.

При вызове boto3.client('sts') учетные данные просматриваются в нескольких местах. Одним из них являются метаданные экземпляра.

Вы могли бы получить метаданные экземпляра, извлечь из них учетные данные, а затем создать клиента с этими учетными данными. Это не только усложнило бы вам работу, но и восстановленные учетные данные были бы ограничены по времени: в какой-то момент срок их действия истек бы, и вам пришлось бы проходить процесс заново. Клиент Boto достаточно умен, чтобы сделать это за вас.

Что касается принятия на себя другой роли, как вы показываете в своем вопросе, метаданные экземпляра вам в этом не помогут. Вы можете получить учетные данные только для роли (профиля экземпляра), прикрепленной к экземпляру EC2.

Конечная точка метаданных экземпляра используется для ролей IAM, предпочтительным подходом является использование роли IAM для предоставления ваших разрешений экземпляру EC2.

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

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

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