Освойте инструменты и лучшие практики DevOps — Центр знаний DevOps Освойте инструменты и лучшие практики DevOps — Центр знаний DevOps

Лучшие практики безопасного управления учетными данными с помощью AWS CLI

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

Лучшие практики безопасного управления учетными данными с AWS CLI

Учетные данные AWS CLI могут создавать, удалять и раскрывать реальные облачные ресурсы, поэтому утечка ключа доступа — это не мелкая ошибка. Самая безопасная настройка предоставляет людям краткосрочные учетные данные через IAM Identity Center, а рабочим нагрузкам — временные учетные данные через роли.

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

Понимание порядка загрузки учетных данных AWS CLI

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

  1. Переменные окружения: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY и опционально AWS_SESSION_TOKEN.
  2. Конфигурация Assume-role и веб-идентификации: Профили, которые указывают CLI вызывать AWS STS для получения временных учетных данных.
  3. Учетные данные IAM Identity Center: Профили, созданные с помощью aws configure sso или aws configure sso-session.
  4. Общий файл учетных данных: Обычно ~/.aws/credentials.
  5. Общий файл конфигурации: Обычно ~/.aws/config, включая записи credential_process.
  6. Учетные данные контейнера: Роли задач ECS и совместимые конечные точки учетных данных контейнера.
  7. Учетные данные профиля экземпляра EC2: Временные учетные данные из службы метаданных экземпляра (IMDS).

AWS CLI не использует флаги командной строки --access-key-id или --secret-access-key для обычных команд. Если вы видите их в скрипте, это, вероятно, путаница поведения AWS CLI с другим инструментом или SDK.

1. Обеспечение безопасности учетных данных в файлах конфигурации (~/.aws/credentials)

Общий файл учетных данных, обычно ~/.aws/credentials, удобен, но должен использоваться как запасной вариант в случаях, когда невозможно использовать IAM Identity Center или роли. Если вам все же необходимо хранить там статические ключи, защитите файл и установите узкие разрешения.

Защита файла и разрешения

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

chmod 600 ~/.aws/credentials

Использование профилей для разделения

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

Пример ~/.aws/credentials:

[default]
aws_access_key_id = AKIAEXAMPLE000000000
aws_secret_access_key = exampleSecretAccessKeyDoNotUse

[production-user]
aws_access_key_id = AKIAEXAMPLE111111111
aws_secret_access_key = anotherExampleSecretDoNotUse

При использовании именованного профиля вы должны указать его с флагом --profile:

aws s3 ls --profile production-user

2. Использование переменных окружения

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

Установите следующие переменные в вашей сессии оболочки:

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_SESSION_TOKEN="temporary-session-token-if-using-sts"
export AWS_DEFAULT_REGION="us-east-1"

Важное замечание о приоритете: Учетные данные, установленные через переменные окружения, всегда переопределяют те, что находятся в файле ~/.aws/credentials, так как они находятся выше в цепочке загрузки учетных данных.

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

unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN

3. Предпочтение ролям IAM для рабочих нагрузок AWS

Для рабочих нагрузок, работающих на инфраструктуре AWS, таких как EC2, Lambda, ECS и EKS, избегайте статических учетных данных. Используйте роли IAM, чтобы AWS автоматически выдавал временные учетные данные.

На EC2 профиль экземпляра предоставляет временные учетные данные через IMDS. На ECS роли задач предоставляют учетные данные через конечную точку учетных данных контейнера. На EKS роли IAM для сервисных аккаунтов используют токены веб-идентификации. AWS CLI и SDK знают, как использовать этих провайдеров без хранения долгоживущих ключей на диске.

Как это работает:

  1. Экземпляр EC2 запускается с связанной ролью IAM через профиль экземпляра.
  2. CLI, работающий на этом экземпляре, запрашивает службу метаданных экземпляра (IMDS) для получения временных учетных данных.
  3. CLI использует эти временные учетные данные для всех последующих вызовов API.

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

4. Использование IAM Identity Center для доступа людей

Для инженеров, использующих AWS CLI с ноутбуков, IAM Identity Center обычно безопаснее, чем ключи доступа пользователя IAM. Вы входите через браузер, выбираете аккаунт и роль, а CLI использует кэшированные краткосрочные учетные данные.

Настройте его с помощью:

aws configure sso

Затем войдите, когда ваша сессия истечет:

aws sso login --profile <profile-name>

IAM Identity Center ранее назывался AWS SSO, поэтому вы все еще можете видеть sso в командах CLI и ключах конфигурации.

5. Использование credential_process для внешних брокеров

Вы можете настроить CLI на вызов внешнего инструмента, такого как агент хранилища или корпоративный брокер учетных данных, для динамического получения учетных данных. Это указывается в ~/.aws/config:

Пример ~/.aws/config:

[profile my-vault-profile]
region = us-west-2
credential_process = /usr/local/bin/my-vault-cli get-aws-creds --profile my-vault-profile

Этот метод крайне важен при интеграции с инструментами управления секретами, такими как HashiCorp Vault.

Сводка лучших практик и контрольный список

Чтобы максимизировать безопасность ваших операций с AWS CLI, придерживайтесь следующих основных принципов:

  • Принцип минимальных привилегий: Убедитесь, что все пользователи и роли IAM имеют только те разрешения, которые строго необходимы для выполнения их задач.
  • Предпочитайте роли ключам: Всегда используйте роли IAM (профили экземпляров) при работе в инфраструктуре AWS.
  • Используйте IAM Identity Center: Для интерактивного использования людьми используйте IAM Identity Center для управления доступом к нескольким аккаунтам.
  • Никогда не жестко кодируйте ключи: Избегайте размещения ключей доступа непосредственно в скриптах, исходном коде или истории команд.
  • Защищайте файл учетных данных: Ограничьте разрешения файловой системы (chmod 600) на ~/.aws/credentials.
  • Регулярно ротируйте ключи: Если статические ключи должны использоваться, обеспечьте строгий график ротации.

Вашим стандартом должны быть временные учетные данные: IAM Identity Center для людей, роли IAM для рабочих нагрузок и credential_process для брокерского корпоративного доступа. Используйте статические ключи доступа только тогда, когда нет лучшего варианта, затем ограничьте их область действия, ротируйте их и удаляйте, как только зависимость исчезнет.