In unserem Setup betreiben wir Discourse in einem AWS EKS-Cluster und erwarten, einen S3 Bucket im selben AWS-Konto für die Medienerstellung zu verwenden. Der EKS-Pod, der Discourse ausführt, wird mit dem Kubernetes Service Account und der IAM-Rolle bereitgestellt. Der S3 Bucket hat allen öffentlichen Zugriff blockiert, wobei eine ACL nur dem Bucket-Besitzer (AWS-Konto) Lese-/Schreibzugriff gewährt.
Mit den Discourse Site Settings “enabled s3 uploads”, “s3 use iam profile” und “secure media uploads” aktiviert, können wir unser Setup für den Upload von Medien in Discourse Topics verwenden. Aufgrund der Prüfungen im UploadCreator-Modul schlagen jedoch alle Site Settings-bezogenen Uploads, z. B. Logo usw., fehl, da versucht wird, die Medien mit dem S3 API-Parameter private_acl auf “false” hochzuladen. Wäre es nicht sinnvoll, dass, wenn “secure media uploads” aktiviert ist, alle Inhalte mit private_acl auf “true” hochgeladen werden?
Selbst in einer vollständig privaten Instanz werden Einstellungen-Uploads wie Logo und Favicon auf der Anmeldeseite angezeigt und als öffentlich betrachtet. Diese werden auch häufig von Tools heruntergeladen, die keine Authentifizierung durchführen, wie z. B. Websites, die OpenGraph-Einbettungen vornehmen, PWA-Installationen, Google-Ergebnisse usw.
Wäre es in diesem Fall sinnvoller, dies von der Aktivierung der Option „s3 use iam profile“ abhängig zu machen oder nicht? Wenn die IAM-Profilnutzung aktiviert ist, bestätigen wir sozusagen, dass der Bucket keinen öffentlichen Zugriff hat und daher mit einer privaten ACL zugegriffen werden muss. Ich könnte mich irren, aber ich sehe keinen Grund, warum man diese Einstellung in Discourse verwenden sollte, es sei denn, man kann seinen Bucket nicht öffentlich machen.
In Ordnung. Dann bleibt uns wohl nur die Option, ein weiteres Einstellungsflag einzuführen, um die ACL des S3-Buckets als privat zu definieren, oder erscheint Ihnen das unlogisch?
Das würde Ihren Anforderungen entsprechen, aber es ist nichts, was wir in unserer Roadmap planen, da öffentliche Buckets mit deaktivierter Dateiliste und einzelnen privaten ACLs für die eigentlichen Dateien bisher gut für uns funktionieren.
Warum ist ein öffentlicher Bucket mit privaten Dateien für Ihren Anwendungsfall nicht möglich?
Nun, das ist in unserem Fall eine Entscheidung auf Unternehmensebene. Alle Assets, einschließlich des Buckets, sollen privat sein und über IAM-Rollen zugänglich gemacht werden. Um die Bucket-Objekte an das Discourse-Frontend zu liefern, haben wir eine S3-Proxy-Anwendung im selben EKS-Cluster erstellt und sie als CDN in den Discourse-Einstellungen konfiguriert. Nun bleibt nur noch die Möglichkeit, Site-Settings-Assets wie Logos usw. als privat hochzuladen, wofür wir dieses Flag benötigen. Standardmäßig versucht Discourse, solche Assets als öffentlich hochzuladen, was ich mit diesem neuen Flag überschreiben möchte.
Wir nutzen die ausgezeichnete sichere Uploads-Funktion für unsere Discourse-Instanz. Sie funktioniert einwandfrei, aber es wäre großartig, wenn es Unterstützung für die Sperrung des gesamten öffentlichen Zugriffs auf den Bucket gäbe.
Kürzlich habe ich versucht, alle von AWS Security Hub gemeldeten Probleme mit den ‘AWS Foundational Security Best Practices’ zu beheben. Eines davon ist, dass ‘S3-Allzweck-Buckets den öffentlichen Zugriff blockieren sollten’.
Ich stelle mir vor, dass ziemlich viele Unternehmen den gleichen Prozess durchlaufen, um die ‘AWS Foundational Security Best Practices’ anzuwenden, und auf dieses Problem stoßen.
Ich erwarte nicht, dass dies in absehbarer Zeit priorisiert wird, aber ich habe diesen Thread gefunden und dachte, ich füge ihm ein ‘+1’ hinzu.