S3-Backup funktioniert nicht mit EC2 IAM

Installation
,
1

Ich glaube, ich habe alle Themen und Tutorials zu diesem Thema durchsucht und bearbeitet.

Ich erhalte immer diesen Fehler, wenn ich versuche, die Seite Backups zu öffnen:

Fehler beim Versuch, /admin/backups.json zu laden

Wenn ich /admin/backups.json öffne, erhalte ich nur eine generische Fehlermeldung „Zugriff verweigert“.

Was ich nicht verstehe, ist, dass die folgenden Befehle auf meiner EC2-Instanz ordnungsgemäß funktionieren:

aws s3 ls s3://my-bucket-name

Und wenn ich mit ./launcher enter app in den Discourse-Container wechsle, kann ich dies nach der Installation von s3cmd auch erfolgreich ausführen:

s3cmd ls s3://my-bucket-name

Ich kann auch mit diesen Befehlen Dinge in meinen Bucket hochladen, daher sollte die IAM-Richtlinie in Ordnung sein, und ich kann nicht verstehen, warum Discourse nicht auf den Bucket zugreifen kann. Ich habe auch versucht, der IAM-Rolle „AdministratorAccess“ hinzuzufügen, um Probleme mit zu engen Berechtigungen auszuschließen.

Konfiguration in Discourse:

backup location: S3
s3 backup bucket: my-bucket-name
s3 use iam profile: true
s3 region: the correct one. tripple checked.

Die restlichen S3-Optionen bleiben unberührt → Daher meist leer/deaktiviert.

Irgendeine Idee, was schiefgehen könnte?

Danke!

2

Ich bin mir nicht sicher, ob dies etwas mit Ihren S3-Einstellungen zu tun hat, es klingt nach einer internen Berechtigungsnachricht von Discourse. Können Sie /admin/backups als Seite laden (anstatt .json am Ende anzuhängen)?

1 „Gefällt mir“
3

Der einfachste Weg, Probleme dieser Art zu debuggen, ist die Überprüfung der Cloudtrail-Protokolle.

4

Das war ein großartiger Hinweis. Ich konnte den Berechtigungsfehler aufspüren und feststellen, dass Discourse einen anderen Benutzer verwendete. Nun zum großen Warum und warum niemand diesen Fehler zuvor hatte.

Wir haben ein benutzerdefiniertes Plugin zum Senden von Push-Benachrichtigungen über AWS SNS, das Anmeldeinformationen über Aws.config.update global gesetzt hat und daher scheint S3 Backup auch die falschen Anmeldeinformationen verwendet zu haben, die offensichtlich nicht die erforderlichen Berechtigungen hatten.

Wir werden nun unser Plugin korrigieren, um die Anmeldeinformationen/Region lokal bereitzustellen und EC2 IAM-Rollen zu unterstützen, was ich zu diesem Zeitpunkt bevorzuge :slight_smile:

Danke für den Anstoß in die richtige Richtung!

paresy

2 „Gefällt mir“
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.