您如何将 Discourse 身份验证到 AWS？帮助我们改进设置！

功能
1

大家好，

我们正在考虑改进 Discourse 处理 AWS [1] 身份验证的方式，在进行任何更改之前，我们希望能了解您当前的设置情况。

当前情况

目前，Discourse 中有几种配置 AWS 身份验证的方法：

选项 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 凭证来源：

  • 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 个赞
2

这样回答更简单：

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

我的操作是一个人，一个管理员。所以我不需要什么花哨的东西，但简单性很有价值。

2 个赞
3

我也使用 ENV 方法。

主要优势是弹性/敏捷性——只要我有 app.yml，就可以轻松地在新服务器上重新启动我的网站。

此外，这通常是在建立网站时一次性解决的问题。或者可能作为一次性升级执行。因此，它很适合 ENV。

话虽如此，在无需重建的情况下即可获得设置以进行故障排除也很有帮助；一旦设置稳定，就可以将其迁移到 ENV 设置。

4

这听起来可能有点吹毛求疵，但我认为这里有一些重要的细微差别。
您提供的选项混合了设置的传递方式和传递的设置内容。

关于设置的传递方式，有两点适用：

  1. 目前环境变量的使用方式
    DISCOURSE_WHATEVER 环境变量目前在 Docker 构建过程中用于在 discourse.conf 中创建条目，这些条目在 Discourse 中可作为 GlobalSetting 或 SiteSetting 使用。Discourse 无法感知这些环境变量本身。

  2. discourse.conf 条目的限制
    虽然 GlobalSettings 具有抑制和覆盖 SiteSettings 的便利功能，但它们也带来了一个限制，即在多站点环境中，它们适用于多站点中的所有站点。

这两点结合起来意味着，在 Discourse 内部，SiteSetting 是最灵活的。它们可以是实际的 SiteSettings，可以来自 discourse.conf，而这些条目可以来自 DISCOURSE_ 环境变量。我认为那里没有真正的选择，SiteSetting 是最灵活的，并且没有缺点，因为它们是功能上的超集。您可以使用 GlobalSettings 代替，而这些设置可以通过环境变量填充。

这暗示唯一的实际选择是是否使用凭证的自动发现。在我个人看来，自动发现总是很容易出错，所以我更倾向于使用显式的方法。

也就是说，有一个 SiteSetting 可以某种方式指向实际的、具体的凭证。