Es scheint, dass die Aufgabe, das Frontend für AWS unter nginx zu implementieren, wie ein typischer Fall für StackOverflow klingt - schließlich kann es keine Probleme mit dem Proxy von Dateien aus S3 geben? Tatsächlich stellte sich heraus, dass eine fertige Lösung nicht so einfach zu finden ist, und dieser Artikel sollte diese Situation korrigieren.
Warum brauchst du das überhaupt?
- Steuern Sie den Zugriff auf Dateien mit nginx - relevant für das Konzept von IaC (Infrastruktur als Code). Alle Änderungen in Bezug auf den Zugriff werden nur in den Konfigurationen vorgenommen , die sich im Projekt befinden.
- Wenn Sie Dateien über Ihren Nginx übergeben, können Sie diese zwischenspeichern und bei Anforderungen an S3 speichern.
- Ein solcher Proxy hilft dabei , die Art des Dateispeichers für verschiedene Anwendungsinstallationen zu ignorieren (schließlich gibt es neben S3 noch andere Lösungen).
Wir formulieren den Rahmen
- Der Quell-Bucket muss privat sein - Sie können anonymen Benutzern nicht erlauben, Dateien direkt von S3 herunterzuladen. Wenn in Ihrem Fall diese Einschränkung nicht funktioniert, verwenden Sie einfach
proxy_pass und Sie können nicht mehr lesen. - Die Optimierung durch AWS sollte einmalig erfolgen, um die Bedienung zu vereinfachen.
Wir suchen nach einer Lösung für die Stirn
Wenn Ihr ursprünglicher Bucket öffentlich ist, drohen Ihnen keine Schwierigkeiten, Proxy-Anfragen für S3 und alles wird funktionieren. Wenn es privat ist, müssen Sie sich irgendwie bei S3 authentifizieren. Was bieten uns Kollegen aus dem Internet:
- Es gibt Beispiele für die Implementierung des Authentifizierungsprotokolls mit nginx. Die Lösung ist gut, aber leider wurde sie für ein veraltetes Authentifizierungsprotokoll ( Signature v2 ) entwickelt, das in einigen Amazon-Rechenzentren nicht funktioniert. Wenn Sie versuchen, diese Lösung beispielsweise in Frankfurt zu verwenden, wird die Fehlermeldung "Der von Ihnen bereitgestellte Autorisierungsmechanismus wird nicht unterstützt. Bitte verwenden Sie AWS4-HMAC-SHA256 . " Eine neuere Version des Protokolls ( Signature v4 ) ist viel schwieriger zu implementieren, aber es gibt keine vorgefertigten Lösungen für Nginx.
- Es gibt ein Drittanbieter-Modul für nginx - ngx_aws_auth . Nach der Quelle zu urteilen, unterstützt es Signature v4. Das Projekt scheint jedoch aufgegeben zu sein: Seit mehr als einem Jahr wurden keine Änderungen an der Codebasis vorgenommen, und es gibt auch ein Kompatibilitätsproblem mit anderen Modulen, auf die der Entwickler nicht reagiert. Darüber hinaus ist das Hinzufügen zusätzlicher Module zu Nginx oft ein schmerzhafter Schritt für sich.
- Sie können einen separaten s3-Proxy verwenden, von dem ziemlich viel geschrieben wurde. Persönlich hat mir die Go-Lösung gefallen - aws-s3-proxy : Sie hat ein fertiges und ziemlich beliebtes Image auf DockerHub. In diesem Fall erhält die Anwendung jedoch eine andere Komponente mit ihren potenziellen Problemen.
Wenden Sie die AWS Bucket-Richtlinie an
AWS macht neuen Benutzern in der Regel Angst vor Komplexität und Dokumentationsvolumen. Aber wenn Sie schauen, verstehen Sie, dass es sehr logisch und flexibel gestaltet ist. Amazon hat auch eine Lösung für unsere Aufgabe gefunden -
S3 Bucket Policy . Mit diesem Mechanismus können Sie flexible Autorisierungsregeln für den Bucket erstellen, die auf verschiedenen Parametern des Clients oder der Anforderung basieren.
Richtliniengenerator- Schnittstelle - AWS Policy GeneratorHier sind einige interessante Optionen, an die Sie binden können:
- IP (
aws:SourceIp ), - Referer-Header (
aws:Referer ), - User-Agent-Header (
aws:UserAgent ), - Der Rest ist in der Dokumentation beschrieben .
IP-Bindung ist nur dann eine gute Option, wenn der Antrag einen bestimmten Wohnort hat, und in unserer Zeit ist dies selten. Dementsprechend müssen Sie sich an etwas anderes binden. Als Lösung schlage ich vor,
einen geheimen User-Agent oder Referer zu
generieren und Dateien nur an Benutzer
weiterzugeben , die den geheimen Header kennen. So sieht eine ähnliche Richtlinie aus:
{ "Version": "2012-10-17", "Id": "http custom auth secret", "Statement": [ { "Sid": "Allow requests with my secret.", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::example-bucket-for-habr/*", "Condition": { "StringLike": { "aws:UserAgent": [ "xxxyyyzzz" ] } } } ] }
Eine kleine Erklärung:
"Version": "2012-10-17" ist die interne AWS-Küche, die Sie nicht bearbeiten müssen.Principal - wer von dieser Regel betroffen ist. Sie können angeben, dass es nur für ein bestimmtes AWS-Konto funktioniert. In unserem Fall kostet es jedoch "*" Dies bedeutet, dass die Regel für alle Benutzer gilt, auch für anonyme Benutzer.Resource - ARN-Bucket (Amazon Resource Name) und Vorlage für Dateien im Bucket. In unserem Fall gilt die Richtlinie für alle Dateien, die sich im example-bucket-for-habr .Condition - Hier sind die Bedingungen, die konvergieren müssen, damit die Richtlinie funktioniert. In unserem Fall vergleichen wir den vordefinierten User-Agent-Header mit der Zeile xxxyyyzzz .
Und so sieht die Arbeit dieser Regel aus der Sicht eines anonymen Benutzers aus:
$ curl -I https://s3.eu-central-1.amazonaws.com/example-bucket-for-habr/hello.txt HTTP/1.1 403 Forbidden $ curl -I https://s3.eu-central-1.amazonaws.com/example-bucket-for-habr/hello.txt -H 'User-Agent: xxxyyyzzz' HTTP/1.1 200 OK
Nginx muss noch für das Proxy
konfiguriert werden :
location /s3-media/ { limit_except GET { deny all; } set $aws_bucket "example-bucket-for-habr"; set $aws_endpoint "s3.eu-central-1.amazonaws.com:443"; set $aws_custom_secret "xxxyyyzzz"; proxy_set_header User-Agent $aws_custom_secret; rewrite ^/s3-media/(.*)$ /$aws_bucket/$1 break; proxy_buffering off; proxy_pass https://$aws_endpoint; }
Fazit
Nachdem wir eine einfache Richtlinie für Bucket geschrieben hatten, hatten wir insgesamt die Möglichkeit, Dateien mit nginx sicher zu vertreten. Wir sind jedoch nicht an IP gebunden und nicht auf zusätzliche Software angewiesen.
PS
Lesen Sie auch in unserem Blog: