#Признаки неисправности и область применимости
Сервисный аккаунт Yandex Cloud не может прочитать или записать объекты в конкретный бакет, хотя успешно работает с другими бакетами. Эта инструкция посвящена назначению прав на ресурс, а не отладке S3-подписи и параметров SDK.
#Почему это происходит
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Роль назначена не на тот ресурсРоли применяются на разных уровнях: облако, каталог или конкретный бакет. | Один бакет доступен, другой возвращает 403 | Сверьте ресурс и роль. |
| Роль на сервисном аккаунте понята неверноРазрешение использовать аккаунт не равно праву аккаунта работать с Object Storage. | Аккаунт существует и назначен пользователю, но доступ к объектам отсутствует | Назначьте роль на сам бакет или родительский каталог. |
| Действует политика бакетаПолитика и условия доступа могут дополнительно ограничивать операции. | Роль IAM есть, но запрос запрещён | Проверьте конкретную политику и действие. |
#Пошаговая диагностика и устранение
- Установите, какой аккаунт выполняет запросВ настройках приложения узнайте идентификатор сервисного аккаунта: не полагайтесь на похожее имя. Для S3-связки проверьте, что статический ключ принадлежит именно ему; не показывайте секретный ключ в отчёте.
- Откройте нужный бакетВ консоли выберите каталог → Object Storage → целевой бакет. Скопируйте точное имя (регистр важен). Проверьте, что приложение действительно обращается к этому бакету и не подставляет название из тестовой среды.
- Посмотрите существующие ролиНайдите управление доступом выбранного бакета или его родительского каталога. Запишите, какие роли действуют на сервисный аккаунт и где они назначены. Роль
iam.serviceAccounts.userна самом аккаунте разрешает его использование, но сама не выдаёт доступ к объектам.
- Сопоставьте действие с минимальной рольюДля операции получения/списка объектов нужна роль с правами чтения, для загрузки — право записи. Посмотрите справочник ролей Object Storage для выбранной операции и не назначайте общий editor, если требуется лишь доступ к одному бакету.
- Запросите точечное назначениеЕсли прав не хватает, попросите администратора добавить узкую роль на уровне конкретного бакета. Перед изменением сохраните список прежних разрешений; никогда не делайте бакет публичным, чтобы исправить серверный AccessDenied.
- Проверьте политику бакетаЕсли роль есть, осмотрите ограничения политики по действиям, префиксам и источникам доступа. Условия могут закрывать только часть объектов. При наличии KMS-шифрования отдельно проверьте права на конкретный ключ, не меняя настройки шифрования всего бакета.
- Повторите тест реальным сервисным аккаунтомИз приложения запросите один безопасный существующий объект, затем выполните пробную запись в специально выделенный тестовый префикс, если она вообще нужна. Не подтверждайте исправление запросом от вашего личного администраторского профиля: его права могут отличаться.
- Оставьте журнал и минимальный доступЗапишите, какая роль, на каком уровне и кому была назначена, и проверьте остальные приложения. При неожиданном расширении доступа верните исходный набор ролей и сообщите ответственному за безопасность.
#Как проверить, что проблема исправлена
Сервисный аккаунт выполняет требуемое действие с целевым бакетом, но не получает лишних разрешений на другие бакеты. Проверка прав проведена от имени самого приложения, а не администратора консоли.
#Если проблема осталась
Если роль добавлена, но AccessDenied сохраняется, проверьте ограничения политик, фактический ключ приложения и KMS. Если ответ сообщает неверную подпись, переходите к диагностике S3-клиента — простое повышение IAM-роли не поможет.