How are you authenticating Discourse to AWS? Help us improve the settings!

Meta Feature
1

Howdy all,

We’re looking at improving how Discourse handles AWS ^[here read: any S3-compatible object storage provider you’re using] 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_IDDISCOURSE_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!



Discuss this on our forum.