В нашей конфигурации Discourse работает в кластере AWS EKS, и мы планируем использовать бакет S3 в той же учетной записи AWS для хранения медиафайлов. Поду EKS, на котором запущен Discourse, предоставлена учетная запись службы Kubernetes и роль IAM. В бакете S3 запрещен весь публичный доступ, а ACL предоставляет права на чтение и запись только владельцу бакета (учетной записи AWS).
При включенных настройках сайта Discourse: «включить загрузки в S3», «использовать профиль IAM для S3» и «безопасная загрузка медиафайлов», мы можем загружать медиафайлы в темы Discourse. Однако из-за проверок в модуле UploadCreator любые загрузки, связанные с настройками сайта (например, логотип и т. д.), завершаются неудачей, поскольку они пытаются загрузить медиафайл с параметром S3 API private_acl, установленным в значение «false». Не логично ли, что при включенной настройке «безопасная загрузка медиафайлов» весь контент загружается с параметром private_acl, установленным в значение true?
Даже в полностью приватном экземпляре такие настройки, как логотип и фавикон, отображаются на странице входа и считаются общедоступными. Их также часто загружают инструменты, не требующие аутентификации, например сайты, использующие встраивание OpenGraph, установки PWA, результаты поиска Google и т. д.
В таком случае, не будет ли логичнее сделать это зависимым от флага «s3 use iam profile»? Если использование IAM-профиля включено, это, по сути, подтверждает, что бакет не имеет публичного доступа, и, следовательно, к нему потребуется обращаться через приватный ACL. Я могу ошибаться, но не вижу причин использовать эту настройку в Discourse, если только пользователь не может сделать свой бакет публичным.
Этот сайт использует s3 use iam profile и при этом имеет публичный бакет. Между ними вообще нет никакой корреляции.
s3 use iam profile означает лишь: «Я не хочу передавать пару ключ/секретный ключ, пожалуйста, автоматически получите её для меня из внутреннего API AWS».
Справедливо. Тогда, полагаю, единственным решением для нас будет добавить ещё один флаг настройки для указания того, что ACL S3-бакета является приватным, или это звучит нелогично?
Это решило бы ваши проблемы, но мы не планируем это реализовывать в нашем плане развития, так как пока нас вполне устраивает использование публичных бакетов с отключенным списком файлов, при этом сами файлы имеют индивидуальные приватные ACL.
Почему для вашего сценария использования не подходит вариант с публичным бакетом и приватными файлами?
В нашем случае это корпоративное решение. Все ресурсы, включая бакет, должны быть приватными и доступны только через IAM-роли. Для доставки объектов бакета на фронтенд Discourse мы создали S3-прокси-приложение, работающее в том же кластере EKS, и настроили его как CDN в параметрах Discourse. Теперь осталось только добавить возможность загрузки таких ресурсов, как логотип и другие настройки сайта, в приватном режиме, для чего нам нужен этот флаг. По умолчанию Discourse пытается загружать такие ресурсы как публичные, и я хотел бы переопределить это поведение с помощью нового флага.
Мы используем отличную функцию защищенной загрузки для нашего экземпляра Discourse; она работает корректно, но было бы здорово, если бы появилась возможность блокировать весь публичный доступ к бакету.
Недавно я пытался устранить все проблемы, связанные с «Базовыми рекомендациями по безопасности AWS» (AWS Foundational Security Best Practices), которые были выявлены AWS Security Hub. Одна из них заключается в том, что «общие бакеты S3 должны блокировать публичный доступ».
Предполагаю, что многие компании проходят через аналогичный процесс применения «Базовых рекомендаций по безопасности AWS» и сталкиваются с этой проблемой.
Не ожидаю, что это будет приоритизировано в ближайшее время, но я нашел эту тему и решил добавить +1.