Устранение ошибок 'Access Denied' и проблем аутентификации в AWS CLI
Систематическое устранение ошибок 'Access Denied' и аутентификации при использовании AWS CLI. Это руководство охватывает основные шаги диагностики, начиная с проверки учетных данных с помощью `aws sts get-caller-identity`, анализа сложной иерархии оценки политик IAM и решения проблем, связанных с временными учетными данными или политиками на основе ресурсов (например, политики корзин S3). Узнайте, как использовать ключевые команды и симулятор политик IAM для быстрого выявления и исправления ошибок авторизации в вашей среде AWS.
Устранение ошибок 'Access Denied' и проблем аутентификации в AWS CLI
Ошибка Access Denied в AWS CLI вызывает разочарование, поскольку сообщение часто называет неудачный вызов API, но не строку политики, которая его вызвала. Эти проблемы почти всегда связаны с неправильной настройкой политик Identity and Access Management (IAM), истекшими временными учетными данными или некорректной настройкой окружения CLI.
Полезная привычка — разделить проблему на два вопроса: от имени кого CLI выполняет вызовы и какая граница политики мешает этому субъекту выполнить действие?
1. Первичная диагностика: определение вызывающего и учетных данных
Прежде чем углубляться в сложный анализ политик, первый шаг — окончательно подтвердить, какой субъект IAM использует AWS CLI и действительны ли эти учетные данные.
Проверка текущего субъекта: sts get-caller-identity
Это самая важная диагностическая команда. Она точно сообщает, какой ARN пользователя, ARN роли или сеанс предполагаемой роли выполняет последующие команды AWS.
aws sts get-caller-identity
Ожидаемый вывод:
{
"UserId": "AIDAIAMUSERID",
"Account": "123456789012",
"Arn": "arn:aws:iam::123456789012:user/DevUser"
}
Если возвращенный ARN не соответствует ожидаемому пользователю или роли, вы работаете под неправильным профилем AWS или переменными окружения.
Проверка конфигурации профиля и региона
Убедитесь, что используется правильный профиль AWS, указанный либо через флаг --profile, либо через переменную окружения AWS_PROFILE.
# Проверка настроек для профиля по умолчанию
aws configure list
# Или проверка конкретного профиля
aws configure list --profile prod-admin
Если вывод показывает отсутствие региона или неверный регион, операции с глобальными ресурсами или сервисами, специфичными для региона (например, корзины S3 или экземпляры EC2), могут завершиться ошибкой, иногда приводя к Access Denied, если ресурс не найден там, где его ищет CLI.
Совет: Если сама команда
sts get-caller-identityзавершается ошибкой аутентификации, это указывает на фундаментальную проблему с ключами доступа (они могут быть удалены, отозваны или неверны).
Работа с временными учетными данными
Если вы используете роль IAM (через STS AssumeRole), CLI работает с временными учетными данными, которые включают SessionToken. Эти учетные данные истекают по истечении времени, настроенного для сеанса, часто одного часа в стандартных конфигурациях. Хотя AWS CLI обычно автоматически обновляет их при получении из стандартной цепочки поставщиков учетных данных, ручные конфигурации могут давать сбой.
Симптом: Команды работают изначально, но перестают работать через определенный период (например, 60 минут) с ошибкой аутентификации.
Решение: Если вы используете пользовательский скрипт или вручную загруженное окружение, убедитесь, что ваш метод принятия роли включает механизм обновления учетных данных по истечении их срока действия.
2. Глубокое погружение в политики IAM и авторизацию
После подтверждения используемого субъекта следующий шаг — определить, почему этому субъекту не хватает необходимых разрешений. Ошибки авторизации AWS сложны, поскольку одновременно оценивается несколько политик.
Иерархия оценки политик IAM
Ошибки авторизации обычно возникают из-за одного из следующих компонентов политики:
- Явный запрет: Явный оператор
Denyв любой применимой политике (субъекта, ресурса или границы) всегда переопределяет операторAllow. - Отсутствие разрешения: Ни одна политика, применимая к субъекту или ресурсу, не предоставляет конкретное действие.
A. Политики на основе субъекта (пользователи и роли)
Проверьте политики IAM, прикрепленные непосредственно к пользователю или принимаемой роли. Ищите:
- Отсутствующие действия: Указано ли в политике конкретное необходимое действие API (например,
s3:ListBucket,ec2:DescribeInstances)? - Ограничения ресурсов: Ограничивает ли политика действие конкретными ресурсами с помощью элемента
Resource? Распространенная ошибка — установкаResource: "*", когда действие требует конкретного ARN, или наоборот. - Условия: Есть ли условия (например, исходный IP-адрес, время суток, требование MFA), которые не выполняются?
B. Политики на основе ресурсов (S3, SQS, KMS)
Для таких сервисов, как S3 или KMS, сам ресурс имеет политику, которая определяет, кто может получить к нему доступ. Для кросс-аккаунтного доступа и для многих дизайнов, специфичных для ресурсов, политика ресурса также должна разрешать субъекту. В том же аккаунте точное взаимодействие зависит от типа субъекта и сервиса, поэтому не предполагайте, что только политика субъекта объясняет каждый результат.
Пример: Попытка доступа к корзине S3 (политика ресурса), которая имеет явный Deny для всех пользователей за пределами конкретного VPC Endpoint, приведет к Access Denied, независимо от политики IAM пользователя.
C. Границы разрешений и SCP
Если ваша организация использует AWS Organizations, Сервисные контрольные политики (SCP) определяют максимальные разрешения, разрешенные в аккаунте. Аналогично, Границы разрешений ограничивают максимальные разрешения, которые может иметь субъект IAM.
Если SCP или граница запрещает требуемое действие, операция CLI завершится ошибкой, даже если политика субъекта предоставляет разрешение.
Практический инструмент: Симулятор политик IAM
При устранении сложных ошибок симулятор политик IAM в консоли управления AWS неоценим. Вы можете протестировать конкретное действие (например, s3:GetObject) для конкретного ресурса (например, arn:aws:s3:::my-bucket/key) и указать субъект IAM, что поможет точно определить, какой оператор политики вызывает запрет.
3. Распространенные сценарии 'Access Denied' и их решения
Сценарий 1: Отказ в доступе к S3 (ресурс против субъекта)
Отказ в доступе к S3 (Access Denied) известен тем, что может быть вызван как политикой пользователя, так и политикой корзины.
| Причина | Диагностика | Решение |
|---|---|---|
| Отсутствие разрешения в политике корзины | sts get-caller-identity работает, но aws s3 ls не работает. |
Измените политику корзины, чтобы явно разрешить вызывающему ARN выполнять необходимые действия (s3:ListBucket, s3:GetObject). |
| Отсутствие разрешений на расшифровку KMS | Доступ к зашифрованным объектам не удается (даже если политика S3 разрешает). | Убедитесь, что субъект IAM имеет разрешения на использование базового ключа KMS (kms:Decrypt), который зашифровал объект. |
| Платит запрашивающий | Попытки загрузить большие файлы не удаются. | Если корзина требует Requester Pays, команда CLI должна включать флаг --request-payer requester. |
Сценарий 2: Неявный запрет из-за невыполнения условий
Многие политики используют условия, которые обеспечивают соблюдение лучших практик безопасности, например, требование многофакторной аутентификации (MFA).
Если ваша политика включает условие, подобное:
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
И вы пытаетесь выполнить команду без аутентифицированной MFA, действие будет неявно запрещено.
Решение: Для команд, требующих MFA, вы должны сначала создать сеанс STS, аутентифицированный с помощью вашего устройства MFA:
# 1. Получите временные учетные данные, используя ваш токен MFA
aws sts get-session-token --serial-number arn:aws:iam::123456:mfa/user --token-code 123456
# 2. Экспортируйте полученные AccessKeyId, SecretAccessKey и SessionToken как переменные окружения для вашего сеанса CLI.
Сценарий 3: Отсутствие или неверный регион
Хотя это не всегда ошибка Access Denied, попытка выполнить действие с ресурсом без указания правильного региона часто приводит к ошибкам авторизации или ненахождения ресурса, особенно при работе с региональными сервисами, такими как EC2, DynamoDB или EKS.
Решение: Явно укажите регион в вашей команде или убедитесь, что ваш профиль настроен правильно.
aws ec2 describe-instances --region us-west-2
Сервис-специфичные проверки, которые экономят время
Ошибки IAM легче отлаживать, когда вы перестаете рассматривать AWS как единую систему разрешений. Каждый сервис добавляет свою собственную модель ресурсов и ключи условий.
Для S3 разделяйте действия на уровне корзины и на уровне объектов. s3:ListBucket использует ARN корзины, в то время как s3:GetObject и s3:PutObject используют ARN объектов внутри корзины. Политика, которая предоставляет s3:GetObject на arn:aws:s3:::my-bucket, сформирована неправильно; для доступа к объекту требуется arn:aws:s3:::my-bucket/*. Обратная ошибка так же распространена для листинга.
Для KMS проверяйте как политику ключа, так и политику IAM. Роль может казаться имеющей kms:Decrypt, но если политика ключа не разрешает этот путь роли, расшифровка все равно не удастся. Это проявляется при загрузке зашифрованных объектов S3, извлечении зашифрованных снимков EBS или чтении секретов, использующих управляемый клиентом ключ.
Для ECR вход в Docker и извлечение образа требуют согласованности нескольких сервисов. Субъекту CLI может потребоваться ecr:GetAuthorizationToken, а политика репозитория может потребовать разрешения на извлечение, если репозиторий используется совместно между аккаунтами. Если роль узла кластера извлекает образ, отладка с вашим личным профилем администратора мало что доказывает; тестируйте как роль узла или роль выполнения задачи.
Для рабочих процессов с принятием роли STS смотрите обе стороны доверительных отношений. Вызывающему нужно разрешение на вызов sts:AssumeRole, а политика доверия целевой роли должна доверять вызывающему. Если в политике доверия присутствует внешний ID или условие MFA, команда принятия роли должна его удовлетворить.
Приоритет окружения может обмануть опытных пользователей
AWS CLI читает не только ~/.aws/credentials. Он проходит по цепочке поставщиков учетных данных, которая может включать флаги командной строки, переменные окружения, именованные профили, записи кэша SSO, токены веб-идентификации, метаданные EC2 или ECS и принятия ролей, настроенные в профиле. Вот почему aws configure list полезнее, чем открытие одного файла.
Один распространенный локальный сбой выглядит так: вы запускаете export AWS_PROFILE=dev, а затем вставляете временные производственные учетные данные в AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY и AWS_SESSION_TOKEN. Ключи окружения могут взять верх, поэтому команды, которые выглядят так, как будто используют dev, на самом деле используют экспортированный сеанс. В терминале, который был открыт весь день, выполните:
env | sort | grep '^AWS_'
Если вы часто переключаете аккаунты, используйте отдельные вкладки терминала, помощник по учетным данным или скрипты-обертки, которые выводят идентификатор вызывающего перед разрушительными командами. Дополнительная строка в выводе дешевле, чем удаление из неправильного аккаунта.
4. Сводка диагностических команд
Используйте этот контрольный список команд для быстрой диагностики цепочки сбоев авторизации:
| Цель | Команда | Назначение |
|---|---|---|
| Проверить субъект | aws sts get-caller-identity |
Подтверждает ARN, выполняющий команду. |
| Проверить конфигурацию | aws configure list |
Проверяет настройки профиля, регион и формат вывода. |
| Проверить действительность политики | (Используйте симулятор политик IAM) | Проверяет, может ли субъект IAM выполнить конкретное действие API над ресурсом. |
| Определить запреты политик | aws cloudtrail lookup-events ... |
Используйте CloudTrail, чтобы увидеть точную запись события, где оценка политики не удалась. |
Реальный путь отладки
Хороший первый проход выглядит так. Запустите неудачную команду снова с явно указанными профилем и регионом, даже если вы думаете, что ваша оболочка уже настроена:
AWS_PROFILE=prod-readonly aws s3 ls s3://example-audit-logs --region us-east-1
aws sts get-caller-identity --profile prod-readonly
aws configure list --profile prod-readonly
Если субъект неверен, остановитесь здесь. Проверьте AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_PROFILE и AWS_REGION в окружении. Учетные данные окружения могут иметь приоритет над профилем и заставить CLI действовать как роль, которую вы забыли, что экспортировали ранее. В CI выведите aws sts get-caller-identity рядом с неудачным шагом, чтобы журнал сборки подтвердил роль, используемую во время выполнения.
Если субъект верен, запишите точное действие API. Команды высокого уровня могут скрывать это. aws s3 cp может потребовать s3:GetObject, s3:PutObject, s3:ListBucket, kms:Decrypt или kms:GenerateDataKey в зависимости от направления, шифрования и того, должен ли CLI проверять корзину. Когда сообщение об ошибке включает AccessDenied, но не действие, CloudTrail обычно предоставляет имя события и ресурс.
Для S3 проверьте политику корзины, владение объектом, настройки блокировки публичного доступа, политику VPC endpoint и политику ключа KMS. Для объектов, зашифрованных KMS, разрешения S3 недостаточно; вызывающему также требуется соответствующее разрешение KMS, и политика ключа должна разрешать путь субъекта. Для организаций проверьте SCP перед редактированием политик субъекта. SCP не может предоставить доступ, но может ограничить то, что любой субъект в аккаунте может делать.
Профилактика — это в основном скучная гигиена: краткосрочные учетные данные роли, четко названные профили, политики минимальных привилегий, протестированные на реальном ARN, и CloudTrail, включенный там, где инженеры могут его запрашивать. Лучшее исправление — не более широкое Action: "*"; это поиск одного отсутствующего действия или одного условия запрета, которое соответствует запросу.