Перестаньте помещать учетные данные AWS в файл учетных данных


От темы Бена Кехо к OSS-инструменту для генерации учетных данных по требованию

Для меня все началось с этой темы в Twitter и с этой статьи Бена Кехо:

При работе с CLI или SDK мы уже привыкли помещать учетные данные IAM в файл .aws/credentials.

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

Целью данной статьи является обзор того, что такое принципы IAM и лучшие способы управления программным доступом к AWS.

Кроме того, мы сосредоточимся на процессе создания учетных данных. Мы увидим, что с его помощью можно отполировать наше локальное использование принципов AWS.

Давайте погрузимся в это путешествие по системам авторизации AWS.

Начнем с основ: IAM Principals!

Согласно официальной документации: «Принципал — это лицо или приложение, которое может запросить действие или операцию над учетной записью или ресурсом AWS».

Принципалы IAM могут быть либо корневой учетной записью пользователя, либо сущностью IAM (пользователем или ролью).

Поскольку Root Account, согласно лучшим практикам, не должен использоваться для программного доступа, а IAM Users не является динамическим способом управления идентификационными данными AWS, поставщик подталкивает пользователей к использованию IAM Roles.

Роли AWS можно использовать для предоставления разрешений внешним поставщикам идентификационных данных (Okta, OneLogin, AzureAd и т.д.) для назначения их на идентификационные данные SSO.

Используя Роли AWS, субъект также может получить разрешение в другой существующей учетной записи AWS с помощью техники assumeRole.

Вы получили своего принципала. Что теперь? Получите доступ к другим учетным записям!

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

Вот исчерпывающая статья, которая объясняет, как вы можете получить доступ к другим учетным записям AWS!

AWS SSO: это процесс аутентификации, а не принцип!

Итак, мы рассмотрели, как использовать принципы в наиболее распространенных сценариях.

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

В современной среде AWS совет AWS — использовать AWS Organizations.

Любезно предоставлено Amazon Web Services

AWS Organizations позволяет использовать AWS Single Sign-On, что является возможностью аутентификации действительной внешней идентификации в экосистеме AWS через процесс федерации.

Важно четко понимать, что AWS SSO — это не Принцип! AWS SSO позволяет аутентифицировать внутри AWS внешние идентификаторы, но он не обрабатывает авторизацию в службах AWS.

AWS связывает одну или несколько IAM ролей с аутентифицированным пользователем через AWS SSO для управления авторизацией.

Подписание запросов API к AWS

Вы можете поместить учетные данные AWS в учетные данные или файлы конфигурации. Но знаете ли вы, как AWS эффективно авторизует запросы, сделанные с помощью этих учетных данных? С помощью процесса, называемого Signature V4.

Идентификатор ключа доступа, секретный ключ доступа и токен сессии используются для подписи HTTP-запросов, которые вы делаете к службам AWS, проверяя, кто обращается к службе.

Они никогда не включаются в запрос. Вместо этого вы используете их для создания криптографической подписи для запроса.

Хотя SigV4 встроен во все AWS SDK, его нельзя использовать самостоятельно (например, API Gateway требует подписи SigV4 для запросов, которые не могут быть сделаны через SDK).

Файл учетных данных AWS и временные учетные данные

Файл учетных данных — это обычный текстовый файл, обычно расположенный в папке ~/.aws/. Они могут быть долгоживущими (AWS IAM User) или краткоживущими (AWS IAM Role).

Формат учетных данных следующий:

[default]
aws_access_key_id = <YOUR_ACCESS_KEY_ID>
aws_secret_access_key =<YOUR_SECRET_ACCESS_KEY>
aws_session_token=<AWS_SESSION_TOKEN> #short-lived only
Войти в полноэкранный режим Выйти из полноэкранного режима

Они используются непосредственно (с определенным профилем или с профилем по умолчанию) в AWS CLI и SDK.

Они напрямую связаны с IAM Principal.

Каковы недостатки такого подхода? Давайте опишем некоторые из них:

AWS SSO

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

Хотя это не является проблемой как таковой, AWS CLI в настоящее время не дает простого способа просмотреть, какая роль связана с конкретным пользователем SSO, а SDK требует пользовательского кода для получения полезных учетных данных.

Поэтому в целом AWS SSO все еще требует значительного ручного вмешательства для эффективного использования для программного доступа.

Недолговечные учетные данные, используемые в файле учетных данных, не могут быть автоматически ротированы AWS

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

Есть несколько конкретных сценариев, в которых это может вызвать серьезные трудности:

  • Длительно выполняющиеся процессы: если вы запускаете длительно выполняющийся сторонний процесс, временные учетные данные будут истекать по пути, создавая исключения в задаче. Менеджер мандатов обязан позаботиться об истечении срока действия.
  • Сторонние инструменты для автоматической ротации: сложно справиться с ротацией без нарушения внешних процессов.

Общее загромождение файлов учетных данных

Как правильно отметил Бен в своей статье, файл учетных данных обычно превращается в список долго- и недолговечных учетных данных и различных профилей.

Такой список небезопасен и сложен в управлении.

Существует ли лучший способ управления всеми доступами AWS к службам и учетным записям? Да, он называется Credential Process.

Процесс мандатов обрабатывает учетные данные AWS, чтобы позволить сторонним инструментам генерировать учетные данные по запросу AWS CLI, API или SDK.

Поместив именованный набор настроек профиля в конфигурационный файл, расположенный в ~/.aws/config в формате, приведенном ниже:

[profile PROFILE_NAME]
credential_process=PROCESS_GENERATING_CREDENTIAL_PATH_SCRIPT
region=REGION
Войти в полноэкранный режим Выйти из полноэкранного режима

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

Процесс credential требует, чтобы внешний инструмент возвращал действительные учетные данные в формате:

{
    "Version": 1,
    "AccessKeyId": "an AWS access key",
    "SecretAccessKey": "your AWS secret access key",
    "SessionToken": "the AWS session token for temporary credentials",
    "Expiration": "ISO8601 timestamp when the credentials expire"
}
Вход в полноэкранный режим Выход из полноэкранного режима

Установка переменной времени истечения срока действия позволяет AWS точно знать, когда снова запрашивать учетные данные, не прерывая внешний процесс, требующий AWS.

Почему лучше использовать процесс мандатов, а не файл мандатов? Авторотация учетных данных!

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

Есть еще одно существенное преимущество: учетные данные не записываются на вашей машине, в файлах или переменных окружения.

Даже если процесс обработки учетных данных — это то, что нужно, все равно необходимо учитывать некоторые важные факторы:

  • Генератор учетных данных процесса: это подразумевает, что используемый вами инструмент может работать с различными принципами IAM.
  • Кэширование учетных данных: поскольку генерация учетных данных требуется внешнему инструменту, также требуется эффективное кэширование учетных данных.
  • Загромождение: избегайте длинного списка правил конфигурации.

Вот где OSS проект Leapp может стать вашим помощником. Leapp может управлять всеми основными принципами IAM и AWS SSO, преобразуя все их в жизнеспособные временные учетные данные.

Leapp — это действующий процесс получения учетных данных для AWS:

[profile PROFILE_NAME]
credential_process=leapp session generate SESSION_ID
region=REGION
Войти в полноэкранный режим Выход из полноэкранного режима

В сочетании с Desktop App, сам файл конфигурации может управляться приложением:

Выводы

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

Мы увидели, как AWS SSO работает с AWS Organizations и почему его нельзя путать с Принципалом. Но мы также увидели все преимущества AWS Organizations перед обычным кросс-аккаунтным доступом.

Также было рассказано о Signature V4, даны подсказки о том, как AWS авторизует запросы, поступающие из CLI и SDK.

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

Наконец, мы обсудили Leapp, наш инструмент с открытым исходным кодом, показав, как он может помочь справиться с процессом обработки учетных данных.

У вас есть вопросы? Хотите предложить решение? Нужно запросить что-то конкретное? Напишите мне в Twitter или присоединяйтесь к нам в нашем slack-сообществе и поделитесь своими мыслями.

Вот и все, друзья, до следующей статьи, до свидания и будьте осторожны 😷.

*Эта статья была написана в паре с моим коллегой @alessandro Gaggia (@balubor)

Оцените статью
Procodings.ru
Добавить комментарий