Wie authentifizieren Sie Discourse bei AWS? Helfen Sie uns, die Einstellungen zu verbessern!

[ducks]

Hallo zusammen,

wir möchten verbessern, wie Discourse die AWS ^[1] Authentifizierung handhabt, und wir würden gerne verstehen, wie Sie derzeit eingerichtet sind, bevor wir Änderungen vornehmen.

Die aktuelle Situation

Derzeit gibt es mehrere Möglichkeiten, die AWS-Authentifizierung in Discourse zu konfigurieren:

Option 1: Explizite Anmeldeinformationen (über Site-Einstellungen)

• s3_access_key_id und s3_secret_access_key in Ihren Site-Einstellungen festlegen
• Authentifizierung ist pro Site

Option 2: Explizite Anmeldeinformationen (über Umgebungsvariablen)

• Die Umgebungsvariablen festlegen:
  DISCOURSE_S3_ACCESS_KEY_ID
DISCOURSE_S3_SECRET_ACCESS_KEY
• Die Authentifizierung ist für alle Sites in einem Multisite-Cluster gleich

Option 3: Einstellung „IAM-Profil verwenden“

• Die Site-Einstellung s3_use_iam_profile aktivieren oder die Umgebungsvariable DISCOURSE_S3_USE_IAM_PROFILE=true festlegen
• Weist Discourse an, die AWS SDK-Anmeldeinformationen automatisch zu finden
• Ursprünglich für EC2-Instanzen und den Abruf von Anmeldeinformationen über IMDS konzipiert, funktioniert aber auch in anderen Umgebungen

Warum wir uns ändern wollen

1. Irreführende Einstellung

Der Name der Einstellung s3_use_iam_profile ist irreführend. Er suggeriert, dass sie nur mit EC2-Instanzprofilen funktioniert, aber sie aktiviert tatsächlich jede AWS SDK Anmeldeinformationsquelle:

• EC2-Instanzprofile
• ECS-Task-Rollen
• Umgebungsvariablen
• AWS-Anmeldeinformationsdateien
• IAM-Rollenzuweisung
• Und mehr…

2. Sicherheit: Statische Schlüssel vs. Rollenzuweisung

Auf unserer Metal-Hosting-Plattform verwenden wir derzeit Zugriffsschlüssel, die regelmäßig rotiert werden. Wir streben einen Wechsel zur Rollenzuweisung an, um eine bessere Isolierung, bessere Möglichkeiten zur Zugriffskontrolle und eine bessere interne Prozessunterstützung zu erzielen.

Nachteile des aktuellen Ansatzes:

• Zugriffsschlüssel laufen nicht ab (bis zur Rotation)
• Haben weitreichende Berechtigungsumfänge
• Können bei Leckage kompromittiert werden
• Erfordern manuelle Rotationsverfahren

Vorteile der Verwendung der Rollenzuweisung stattdessen:

• Persistente Anmeldeinformationen können per IP-Adresse eingeschränkt werden
• Operationen werden mit temporären Anmeldeinformationen durchgeführt, die automatisch ablaufen (normalerweise 1 Stunde)
• Just-in-Time-Zugriff, da Anmeldeinformationen nur bei Bedarf vorhanden sind
• Reduzierter Schadensradius, da kompromittierte temporäre Anmeldeinformationen schnell ablaufen
• Keine Schlüsselrotation – der Prozess der Rollenzuweisung kümmert sich um die Aktualisierung
• Bessere Audit-Protokolle – jede Sitzung wird separat verfolgt

Was wir in Erwägung ziehen

Wir denken darüber nach, entweder:

1. Die Einstellung in etwas Klareres wie aws_credentials_from_environment umzubenennen
2. Die Einstellung ganz zu entfernen und automatisch zu erkennen, wann Anmeldeinformationen aus der Umgebung und nicht aus den Site-Einstellungen stammen sollten

Wir brauchen Ihre Meinung!

Bitte lassen Sie uns wissen:

1. Wie authentifizieren Sie sich bei S3?

   • Explizite Zugriffsschlüssel in den Site-Einstellungen
   • EC2-Instanzprofil (mit aktivierter s3_use_iam_profile)
   • ECS-Task-Rolle (mit aktivierter s3_use_iam_profile)
   • Umgebungsvariablen (mit aktivierter s3_use_iam_profile)
   • … etwas anderes?

2. Wenn Sie s3_use_iam_profile verwenden:

   • In welcher Umgebung laufen Sie? (EC2, ECS, Docker, Bare Metal usw.)
   • Haben der aktuelle Name/die Beschreibung zu Verwirrung geführt?
   • Wäre ein anderer Name klarer?

3. Haben Sie Bedenken hinsichtlich Änderungen an dieser Einstellung?

   • Befürchten Sie, dass Ihre aktuelle Einrichtung beeinträchtigt wird?
   • Benötigen Sie Zeit, um Änderungen zu testen?
   • Andere Überlegungen?

Warum das wichtig ist

Bessere S3-Authentifizierung bedeutet:

• Sicherer – keine statischen Schlüssel zu verwalten
• Einfachere Einrichtung – insbesondere für Cloud-Bereitstellungen
• Weniger Verwirrung – klarere Einstellungen und Dokumentation
• Bessere Unterstützung für moderne AWS-Authentifizierungsmuster

Ihr Feedback hilft uns, Verbesserungen vorzunehmen, die für alle funktionieren. Vielen Dank, dass Sie sich die Zeit nehmen, Ihre Einrichtung zu teilen!

---

1. hier lesen: jeder S3-kompatible Objektspeicheranbieter, den Sie verwenden ↩︎

[Jagster (Jakke Lehtonen)]

Einfacher ist es so:

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

Meine ist eine ein Mann, ein Admin-Operation. Ich brauche also nichts Ausgefallenes, aber Einfachheit hat einen hohen Wert.

[nathank (Nathan Kershaw)]

Ich verwende auch den ENV-Ansatz.
Der Hauptvorteil ist die Ausfallsicherheit/Agilität – solange ich die app.yml habe, kann ich meine Website mit minimalem Aufwand auf einem neuen Server neu starten.
Außerdem ist dies in der Regel etwas, das man einmal erledigt, wenn man eine Website einrichtet. Oder vielleicht als einmaliges Upgrade durchführt. Es passt also gut zu ENV.
Davon abgesehen ist es auch hilfreich, die Einstellungen zur Fehlerbehebung zur Verfügung zu haben, ohne neu erstellen zu müssen; sobald die Einstellungen stabil sind, können sie dann in ENV-Einstellungen migriert werden.

[RGJ (Richard - Communiteq)]

@ducks

wann Anmeldeinformationen aus der Umgebung und nicht aus den Site-Einstellungen stammen sollten

Das mag kleinlich klingen, aber ich denke, hier gibt es einige wichtige Nuancen.
Die von Ihnen angebotenen Optionen sind eine Mischung aus WIE Einstellungen übergeben werden und WAS für Einstellungen übergeben werden.

In Bezug auf WIE Einstellungen übergeben werden, gelten zwei Dinge:

1. die Art und Weise, wie Umgebungsvariablen derzeit verwendet werden
   Die DISCOURSE_WHATEVER-Umgebungsvariablen werden derzeit während des Docker-Build-Prozesses verwendet, um Einträge in discourse.conf zu erstellen, die innerhalb von Discourse als GlobalSetting oder SiteSetting verfügbar sind. Discourse nimmt diese Umgebungsvariablen nicht als solche wahr.

2. die Einschränkungen von discourse.conf-Einträgen
   Obwohl GlobalSettings den netten Vorteil haben, SiteSettings unterdrücken und überschreiben zu können, haben sie auch die Einschränkung, dass sie in Multi-Site-Umgebungen für alle Sites im Multi-Site gelten.

Diese beiden kombiniert bedeuten, dass SiteSetting innerhalb von Discourse am flexibelsten ist. Sie können tatsächliche SiteSettings sein, sie können aus discourse.conf stammen und diese Einträge können aus DISCOURSE_-Umgebungsvariablen stammen. Meiner Meinung nach gibt es dort keine wirkliche Wahl, SiteSetting ist am flexibelsten und hat keine Nachteile, da sie eine funktionale Obermenge darstellen. Sie können stattdessen GlobalSettings verwenden, und diese können mithilfe von Umgebungsvariablen gefüllt werden.

Das impliziert, dass die einzige tatsächliche Wahl darin besteht, ob die automatische Erkennung von Anmeldeinformationen verwendet werden soll oder nicht. Meiner persönlichen Wahrnehmung nach ist die automatische Erkennung immer sehr fehleranfällig, daher würde ich etwas Explizites bevorzugen.

D.h. eine SiteSetting haben, die irgendwie auf tatsächliche, konkrete Anmeldeinformationen verweist.