S3Proxy: Zugriff auf andere Storage-Backends über die S3-API

Was S3Proxy übersetzt

S3Proxy implementiert die Amazon-S3-API und leitet Anfragen an andere Speicher-Backends weiter. Laut README übersetzt es S3-Aufrufe an Google Cloud Storage, Microsoft Azure, OpenStack Swift und SFTP und kann auch das lokale Dateisystem oder einen In-Memory-Speicher verwenden. Das Projekt listet vier Hauptanwendungsfälle auf: die Arbeit mit diesen Cloud-Backends über eine gemeinsame S3-Schnittstelle, das Testen von S3-Clients ohne Amazon durch Verweisen auf ein lokales Dateisystem, die Erweiterung des Verhaltens durch Middlewares und das Einbetten des Proxys in Java-Anwendungen. Der Proxy selbst ist in Java geschrieben und benötigt Java 17 oder neuer.

S3Proxy ausführen

Das README beschreibt mehrere Möglichkeiten, S3Proxy auszuführen. Ein Docker-Image wird auf Docker Hub gehostet, und das Verzeichnis examples/kubernetes enthält Referenz-Manifeste, um dieses Image in Kubernetes zu integrieren, einschließlich Health Probes, Graceful Shutdown und Secret-basierten Anmeldeinformationen. Für nicht-containerisierte Bereitstellungen sind Releases von GitHub herunterladbar, und Entwickler können das Projekt mit mvn package erstellen, das eine Binärdatei unter target/s3proxy erzeugt. Die Konfiguration erfolgt über eine Properties-Datei. Das README zeigt ein minimales Beispiel mit dem Dateisystem-Backend und anonymem Zugriff: s3proxy.authorization=none, s3proxy.endpoint=http://127.0.0.1:8080, jclouds.provider=filesystem und jclouds.filesystem.basedir=/tmp/s3proxy. Nachdem dieses Verzeichnis erstellt wurde, können Linux- und macOS-Benutzer chmod +x s3proxy ausführen und es mit --properties s3proxy.conf starten. Windows-Benutzer rufen java -jar s3proxy mit demselben Flag auf. Das README zeigt dann curl-Befehle zum Erstellen eines Buckets und zum Auflisten aller Buckets, die das erwartete XML zurückgeben.

Speicher-Backends und Bucket-Routing

S3Proxy unterstützt sieben Speicher-Backends: aws-s3, azureblob, filesystem (auf der Festplatte), google-cloud-storage, openstack-swift (nur Keystone v3), sftp (über Apache MINA SSHD) und transient (im Speicher). Buckets können mit den Eigenschaften s3proxy.bucket-locator verschiedenen Backends zugewiesen werden. Das README zeigt nummerierte Einträge wie s3proxy.bucket-locator.1=bucket und s3proxy.bucket-locator.2=another-bucket und weist darauf hin, dass Glob-Syntax akzeptiert wird, sodass eine einzelne Regel viele Buckets abdecken kann. Ein Bucket (oder Glob) kann nicht mehr als einem Backend zugewiesen werden. Das Wiki enthält Konfigurationsbeispiele für jedes Backend, die im README verlinkt sind.

Middlewares und Erweiterungspunkte

S3Proxy kann sein Verhalten durch Middlewares ändern. Das README verlinkt zu Wiki-Seiten für die folgenden Punkte: Bucket-Aliasing, Bucket-Präfix-Scoping, Bucket-Locator, Eventual-Consistency-Modellierung, Large-Object-Mocking, Latenz, schreibgeschützt, Regex-Rename von Blobs, Sharded-Backend-Container, Storage-Class-Override, User-Metadata-Replacer und No-Cache-Override. Diese Middlewares ermöglichen es Bereitstellungen, die Verarbeitung von Anfragen zu ändern, ohne den Proxy-Kern zu verändern. Das README erklärt die Funktionsweise jeder Middleware nicht über den Namen und den Wiki-Link hinaus; Details müssten von diesen Seiten stammen.

Kompatibilitätsgrenzen der S3-API

Das README ist explizit darüber, welche Teile der S3-API S3Proxy nicht unterstützt. Die Liste umfasst ACLs außer private und public-read, BitTorrent-Hosting, Bucket-Inventar, Analysen, Metriken, Lebenszyklus, Protokollierung, Benachrichtigung, Richtlinien, Replikation, bedingtes Löschen mit If-Match oder x-amz-*-Headern, CORS-Bucket-Operationen, statisches Website-Hosting, Objektsperre, Besitzkontrollen, serverseitige Verschlüsselung, Tagging, Versionierung, Paginierung von ListParts mit part-number-marker, Public Access Block, Lesen eines einzelnen Teils eines Multipart-Objekts, Requester Pays, Wiederherstellung archivierter Objekte, Select-Objektinhalt, Transfer Acceleration und x-amz-expected-bucket-owner. S3Proxy emuliert jedoch Multipart-Uploads auf den Backends filesystem und transient, indem es ein Stub-Objekt für Metadaten speichert, und meldet für alle Objekte und Buckets einen synthetischen Besitzer. Einige Einschränkungen variieren je nach Backend; beispielsweise unterstützen azureblob und openstack-swift keine Pro-Objekt-ACLs, und azureblob und google-cloud-storage geben ETags zurück, die nicht der MD5 des Objekts sind. Das README erläutert auch die Behandlung bedingter Schreibvorgänge: aws-s3, azureblob und google-cloud-storage führen ein bedingtes PUT im Backend aus, während filesystem und transient es innerhalb eines einzelnen Prozesses emulieren. Andere Backends verweigern bedingtes PUT, anstatt ein Read-Then-Write-Rennen zu riskieren.

CORS, SSL und zusätzliche Konfiguration

S3Proxy verfügt über grundlegende CORS-Preflight- und tatsächliche Anforderungs-/Antwortverarbeitung, die über Eigenschaften wie s3proxy.cors-allow-origins, s3proxy.cors-allow-methods, s3proxy.cors-allow-headers und s3proxy.cors-allow-credential konfiguriert werden. CORS kann nicht pro Bucket festgelegt werden, und s3proxy.cors-allow-all akzeptiert jeden Ursprung und Header. Tatsächliche CORS-Anforderungen werden für GET, PUT, POST, HEAD und DELETE unterstützt. Cross-Origin-Sharing ist Opt-in; ein Proxy ohne CORS-Konfiguration teilt nichts, und Antworten, die vom Origin der Anfrage abhängen, tragen Vary: Origin, damit Caches keine Antworten verschiedener Origins mischen. Für HTTPS kann S3Proxy auf einem secure-endpoint lauschen, und das README verweist auf eine Wiki-Seite zur Konfiguration eines Keystores und zur Verwendung von SSL mit Docker, Kubernetes oder einfachem Java.

Support, Referenzen und Lizenz

Das README listet Support-Kanäle auf: GitHub Issues, Stack Overflow mit dem Tag s3proxy und eine kommerzielle Support-E-Mail-Adresse. Es verweist auch auf Projekte mit ähnlichem oder angrenzendem Zweck: Ceph s3-tests für Kompatibilitätstests, fake-s3, gofakes3, minio, S3 ninja und s3rver als dateisystembasierte Alternativen, GlacierProxy und SwiftProxy für andere APIs, s3mock von Adobe, ein Drittanbieter-Helm-Chart, sbt-s3 für Scala-Builds, swift3 als S3-Middleware für OpenStack Swift und Zenko für Multi-Cloud. Das Repository ist unter der Apache-Lizenz 2.0 lizenziert, mit Urheberrecht von Andrew Gaul von 2014 bis 2026. Der Lizenzauszug gewährt Rechte zur Vervielfältigung, Erstellung abgeleiteter Werke und Verbreitung, sagt aber nichts über Garantien, Support oder Sicherheitszusicherungen aus, und das README tut dies auch nicht.

Redaktionelles Fazit

S3Proxy bietet Anwendungen eine stabile S3-Schnittstelle, während das darunterliegende Speicher-Backend geändert werden kann. Das README definiert die unterstützten Backends, die Middlewares, die das Verhalten ändern können, und eine lange Liste von S3-Funktionen, die nicht implementiert sind. Die Apache-2.0-Lizenz gewährt Vervielfältigungs- und Änderungsrechte, enthält jedoch keine Garantie oder Support-Zusage, und die Repository-Metadaten zeigen, dass es zum Zeitpunkt dieses Schreibens nicht archiviert ist.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes