Резервное копирование S3 не работает с EC2 IAM

Кажется, я пересмотрел все темы и руководства по этому вопросу.

При попытке открыть страницу «Резервные копии» я постоянно получаю эту ошибку:

Ошибка при загрузке /admin/backups.json

Когда я открываю /admin/backups.json, получаю только общую ошибку Access Denied (Отказано в доступе).

Что я не понимаю, так это то, что следующие команды на моем экземпляре EC2 работают корректно:

aws s3 ls s3://my-bucket-name

А при входе в контейнер Discourse с помощью ./launcher enter app я также успешно выполняю это после установки s3cmd:

s3cmd ls s3://my-bucket-name

Я также могу загружать файлы в свой бакет с помощью этих команд, следовательно, политика IAM должна быть настроена верно, и я не понимаю, почему Discourse не может получить доступ к бакету. Я также пробовал добавить роль “AdministratorAccess” к IAM-роли, чтобы исключить проблемы со слишком строгими разрешениями.

Конфигурация в Discourse:

backup location: S3
s3 backup bucket: my-bucket-name
s3 use iam profile: true
s3 region: правильный. проверено трижды.

Остальные параметры S3 оставлены без изменений > поэтому в основном пустые/отключены.

Есть ли идеи, что может быть не так?

Спасибо!

Не думаю, что это связано с вашими настройками S3; похоже, это стандартное сообщение о правах доступа в Discourse. Можете ли вы загрузить страницу /admin/backups (без добавления .json в конец)?

Самый простой способ отладить подобные проблемы — проверить логи CloudTrail.

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

У нас есть кастомный плагин для отправки push-уведомлений через AWS SNS, который глобально устанавливал учётные данные с помощью Aws.config.update. Из-за этого резервное копирование в S3 также, похоже, использовало неверные учётные данные, у которых, очевидно, не было необходимых прав.

Теперь мы исправим наш плагин так, чтобы он локально указывал учётные данные и регион, а также будет поддерживаться использование ролей IAM для EC2, что я сейчас предпочитаю :slight_smile:

Спасибо за наводку в правильном направлении!

paresy