Comment authentifiez-vous Discourse auprès d'AWS ? Aidez-nous à améliorer les paramètres !

Fonctionnalité
1

Howdy all,

We’re looking at improving how Discourse handles AWS [1] authentication, and we’d love to understand how you’re currently set up before making any changes.

The Current Situation

Right now, there are a few ways to configure AWS authentication in Discourse:

Option 1: Explicit Credentials (via site settings)

  • set s3_access_key_id and s3_secret_access_key in your site settings
  • authentication is per-site

Option 2: Explicit Credentials (via environment variables)

  • set the environment variables:
    DISCOURSE_S3_ACCESS_KEY_ID
    DISCOURSE_S3_SECRET_ACCESS_KEY
  • authentication is the same for all sites in a multisite cluster

Option 3: “Use IAM Profile” Setting

  • enable s3_use_iam_profile site setting or set the environment variable DISCOURSE_S3_USE_IAM_PROFILE=true
  • tells Discourse to let the AWS SDK find credentials automatically
  • originally designed for EC2 instances and obtaining credentials via IMDS, but works in other environments

Why we want to change

1. Confusing Setting Name

The s3_use_iam_profile setting has a misleading name. It suggests it only works with EC2 instance profiles, but it actually enables any AWS SDK credential source:

  • EC2 instance profiles
  • ECS task roles
  • Environment variables
  • AWS credential files
  • IAM role assumption
  • And more…

2. Security: Static Keys vs. Role Assumption

On our metal hosting platform we currently use access keys that get rotated on a regular basis. We’re aiming to switch that to role assumption for better isolation, better opportunities for access control, and to support a better internal process.

Disadvantages of the current approach:

  • access keys do not expire (until rotated)
  • have wide permission scopes
  • can be compromised if leaked
  • require manual rotation procedures

Advantages of instead using role assumption:

  • persistent credentials can be restricted via IP address
  • operations are done using temporary credentials that auto-expire (usually 1 hour)
  • just-in-time access as credentials only exist when needed
  • reduced blast radius since compromised temporary creds expire quickly
  • no key rotation - the role assumption process handles refreshing
  • better audit trails - each session gets tracked separately

What We’re Considering

We’re thinking about either:

  1. Rename the setting to something clearer like aws_credentials_from_environment
  2. Remove the setting entirely and automatically detect when credentials should come from the environment vs. site settings

We Need Your Input!

Please let us know:

  1. How do you authenticate with S3?

    • Explicit access keys in site settings
    • EC2 instance profile (with s3_use_iam_profile enabled)
    • ECS task role (with s3_use_iam_profile enabled)
    • Environment variables (with s3_use_iam_profile enabled)
    • … something else?

  2. If you use s3_use_iam_profile:

    • What environment are you running in? (EC2, ECS, Docker, bare metal, etc.)
    • Did the current name/description cause any confusion?
    • Would a different name be clearer?

  3. Any concerns about changes to this setting?

    • Worried about breaking your current setup?
    • Need time to test changes?
    • Other considerations?

Why This Matters

Better S3 authentication means:

  • More secure - no static keys to manage
  • Easier setup - especially for cloud deployments
  • Less confusion - clearer settings and documentation
  • Better support for modern AWS authentication patterns

Your feedback will help us make improvements that work for everyone. Thanks for taking the time to share your setup!

  1. here read: any S3-compatible object storage provider you’re using ↩︎

1 « J'aime »
2

Easier to answer this way:

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

Mine is one man, one admin operation. So I don’t need anything fancy, but easiness has high value.

2 « J'aime »