Как вы аутентифицируете Discourse с AWS? Помогите нам улучшить настройки!

Внести вклад Функция
1

Всем привет,

Мы рассматриваем возможность улучшения того, как Discourse обрабатывает аутентификацию для AWS [1], и хотели бы понять, как вы настроены в данный момент, прежде чем вносить какие-либо изменения.

Текущая ситуация

На данный момент существует несколько способов настройки аутентификации AWS в Discourse:

Вариант 1: Явные учетные данные (через настройки сайта)

  • установите s3_access_key_id и s3_secret_access_key в настройках вашего сайта
  • аутентификация выполняется для каждого сайта отдельно

Вариант 2: Явные учетные данные (через переменные окружения)

  • установите переменные окружения:
    DISCOURSE_S3_ACCESS_KEY_ID
    DISCOURSE_S3_SECRET_ACCESS_KEY
  • аутентификация одинакова для всех сайтов в кластере с поддержкой нескольких сайтов

Вариант 3: Настройка «Использовать профиль IAM»

  • включите настройку сайта s3_use_iam_profile или установите переменную окружения DISCOURSE_S3_USE_IAM_PROFILE=true
  • указывает Discourse предоставить AWS SDK возможность автоматически находить учетные данные
  • изначально предназначалась для экземпляров EC2 и получения учетных данных через IMDS, но работает и в других средах

Почему мы хотим внести изменения

1. Путаница в названии настройки

Настройка s3_use_iam_profile вводит в заблуждение своим названием. Она предполагает, что работает только с профилями экземпляров EC2, но на самом деле она включает любой источник учетных данных AWS SDK credential source:

  • профили экземпляров EC2
  • роли задач ECS
  • переменные окружения
  • файлы учетных данных AWS
  • присвоение ролей IAM
  • и многое другое…

2. Безопасность: статические ключи против присвоения ролей

На нашей платформе хостинга на «железе» мы в настоящее время используем ключи доступа, которые регулярно обновляются. Мы планируем перейти на присвоение ролей для лучшей изоляции, более гибкого контроля доступа и поддержки улучшенных внутренних процессов.

Недостатки текущего подхода:

  • ключи доступа не истекают (пока не будут обновлены)
  • имеют широкие области разрешений
  • могут быть скомпрометированы при утечке
  • требуют ручных процедур обновления

Преимущества использования присвоения ролей:

  • постоянные учетные данные могут быть ограничены по IP-адресу
  • операции выполняются с использованием временных учетных данных, которые автоматически истекают (обычно через 1 час)
  • доступ по требованию, так как учетные данные существуют только при необходимости
  • уменьшенный радиус поражения, поскольку скомпрометированные временные учетные данные быстро истекают
  • отсутствие необходимости в обновлении ключей — процесс присвоения ролей сам обеспечивает обновление
  • улучшенные журналы аудита — каждая сессия отслеживается отдельно

Что мы рассматриваем

Мы думаем о том, чтобы:

  1. Переименовать настройку во что-то более понятное, например aws_credentials_from_environment
  2. Полностью удалить настройку и автоматически определять, когда учетные данные должны браться из окружения, а когда — из настроек сайта

Нам нужно ваше мнение!

Пожалуйста, сообщите нам:

  1. Как вы аутентифицируетесь с S3?

    • Явные ключи доступа в настройках сайта
    • Профиль экземпляра EC2 (с включенной настройкой s3_use_iam_profile)
    • Роль задачи ECS (с включенной настройкой s3_use_iam_profile)
    • Переменные окружения (с включенной настройкой s3_use_iam_profile)
    • … что-то другое?

  2. Если вы используете s3_use_iam_profile:

    • В какой среде вы работаете? (EC2, ECS, Docker, «голое железо» и т. д.)
    • Вызывало ли текущее название/описание путаницу?
    • Было бы другое название более понятным?

  3. Есть ли у вас опасения по поводу изменений этой настройки?

    • Опасаетесь, что это нарушит вашу текущую конфигурацию?
    • Нуждаетсяе во времени для тестирования изменений?
    • Есть ли другие соображения?

Почему это важно

Улучшенная аутентификация S3 означает:

  • Повышенную безопасность — нет необходимости управлять статическими ключами
  • Упрощенную настройку — особенно для развертываний в облаке
  • Меньше путаницы — более понятные настройки и документация
  • Лучшую поддержку современных паттернов аутентификации AWS

Ваша обратная связь поможет нам внести улучшения, которые будут работать для всех. Спасибо за то, что нашли время поделиться информацией о своей конфигурации!

  1. здесь имеется в виду: любой провайдер объектного хранилища, совместимый с S3, который вы используете ↩︎

2 лайка
An AWS S3 Integration with Discourse Tutorial would be nice
2

Проще ответить так:

DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: eu-north-1
  DISCOURSE_S3_ACCESS_KEY_ID: <что-то>
  DISCOURSE_S3_SECRET_ACCESS_KEY: <что-то>
  DISCOURSE_S3_CDN_URL: https://cdnfoorumi.katiska.eu
  DISCOURSE_S3_BUCKET: <что-то>
  DISCOURSE_S3_BACKUP_BUCKET: <что-то>
  DISCOURSE_BACKUP_LOCATION: s3
  S3_ORIGIN_ASSETS: https://foorumi.katiska.eu

Моя система — это один человек, один администратор. Поэтому мне не нужны сложные решения, но простота имеет высокую ценность.

2 лайка
3

Я тоже использую подход с ENV.

Ключевое преимущество — устойчивость и гибкость: пока у меня есть файл app.yml, я могу запустить свой сайт на новом сервере с минимальными усилиями. Или легко управлять тестовым сервером.

Кроме того, это обычно решается один раз при создании сайта. Или, возможно, выполняется как разовое обновление. Поэтому ENV подходит для этого идеально.

Тем не менее, полезно иметь настройки доступными для устранения неполадок без необходимости пересборки; после того как настройки стабилизируются, их можно перенести в переменные окружения.

4

Возможно, это звучит как придирка, но я считаю, что здесь есть важные нюансы.
Предлагаемые вами варианты представляют собой смесь того, КАК передаются настройки, и ЧТО именно передается.

Что касается того, КАК передаются настройки, применимы два момента:

  1. способ использования переменных окружения на данный момент

Переменные окружения DISCOURSE_WHATEVER в настоящее время используются в процессе сборки Docker для создания записей в discourse.conf, которые становятся доступными как GlobalSetting или SiteSetting внутри Discourse. Сам Discourse не воспринимает эти переменные окружения как таковые.

  1. ограничения записей в discourse.conf

Хотя GlobalSettings обладают удобной возможностью подавлять и переопределять SiteSettings, они также накладывают ограничение: в мультисайтовых окружениях они применяются ко всем сайтам в этой группе.

Сочетание этих двух факторов означает, что внутри Discourse SiteSetting являются наиболее гибким вариантом. Они могут быть настоящими SiteSettings, которые опционально могут поступать из discourse.conf, а эти записи, в свою очередь, могут приходить из переменных окружения DISCOURSE_. На мой взгляд, здесь нет реального выбора: SiteSetting — наиболее гибкий вариант и не имеет недостатков, поскольку является функциональным надмножеством остальных. Вы можете использовать GlobalSettings, если хотите, и их можно заполнять с помощью переменных окружения.

Это подразумевает, что единственное реальное решение заключается в том, использовать ли автоматическое обнаружение учетных данных или нет. По моему личному мнению, автоматическое обнаружение всегда очень подвержено ошибкам, поэтому я предпочел бы что-то явное.

То есть иметь SiteSetting, который каким-то образом указывает на реальные, конкретные учетные данные.