S3Proxy : accéder à d'autres backends de stockage via l'API S3
Ce projet transforme « Access other storage backends via the S3 API. Developers can build the project by running mvn package which produces a binary at target/s3proxy. » en une solution open source exploitable, avec une chaîne d’outils réutilisable et des moyens d’intégration pour des cas d’usage concrets.
En bref
- De quoi s’agit-il ?
- Un proxy Java qui implémente l'API S3 et transmet les requêtes à Google Cloud, Azure, OpenStack Swift, SFTP ou au stockage local.
- À qui s’adresse-t-il ?
- S3Proxy offre aux applications une interface S3 stable tout en permettant de changer le backend de stockage sous-jacent. Le README définit les backends pris en charge, les middlewares qui peuvent modifier le comportement et une longue liste de fonctionnalités S3 non implémentées.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 5 jours.
- En quel langage est-il écrit ?
- Principalement Java, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Ce que traduit S3Proxy
S3Proxy implémente l'API Amazon S3 et relaie les requêtes vers d'autres backends de stockage. Selon le README, il traduit les appels S3 vers Google Cloud Storage, Microsoft Azure, OpenStack Swift et SFTP, et peut également utiliser le système de fichiers local ou un stockage en mémoire. Le projet énumère quatre cas d'utilisation principaux : travailler avec ces backends cloud via une interface S3 commune, tester des clients S3 sans Amazon en pointant vers un système de fichiers local, étendre le comportement via des middlewares et intégrer le proxy dans des applications Java. Le proxy lui-même est écrit en Java et nécessite Java 17 ou plus récent.
S3Proxy expose une interface compatible Amazon S3 devant des backends de stockage comme filesystem, S3, Azure ou Google Cloud, selon la configuration documentée. Le projet Java vise les applications qui parlent déjà S3 mais doivent changer l’emplacement réel des objets.
Exécution de S3Proxy
Le README décrit plusieurs façons d'exécuter S3Proxy. Une image Docker est hébergée sur Docker Hub, et le répertoire examples/kubernetes contient des manifestes de référence pour intégrer cette image dans Kubernetes, y compris des sondes de santé, un arrêt gracieux et des informations d'identification basées sur Secret. Pour un déploiement non conteneurisé, les versions sont téléchargeables depuis GitHub, et les développeurs peuvent compiler le projet avec mvn package, ce qui produit un binaire dans target/s3proxy. La configuration se fait via un fichier de propriétés ; le README donne un exemple minimal utilisant le backend de système de fichiers avec accès anonyme : s3proxy.authorization=none, s3proxy.endpoint=http://127.0.0.1:8080, jclouds.provider=filesystem et jclouds.filesystem.basedir=/tmp/s3proxy. Après avoir créé ce répertoire, les utilisateurs Linux et macOS peuvent exécuter chmod +x s3proxy et le lancer avec --properties s3proxy.conf ; les utilisateurs Windows invoquent java -jar s3proxy avec le même indicateur. Le README montre ensuite des commandes curl pour créer un bucket et lister tous les buckets, renvoyant le XML attendu.
Un test utile consiste à démarrer S3Proxy avec le fichier de configuration choisi, créer un bucket et envoyer un objet avec un client S3. Vérifiez ensuite la lecture, la suppression, les permissions et la traduction des erreurs du backend avant toute exposition réseau.
Backends de stockage et routage des buckets
S3Proxy prend en charge sept backends de stockage : aws-s3, azureblob, filesystem (sur disque), google-cloud-storage, openstack-swift (Keystone v3 uniquement), sftp (via Apache MINA SSHD) et transient (en mémoire). Les buckets peuvent être attribués à différents backends à l'aide des propriétés s3proxy.bucket-locator. Le README montre des entrées numérotées comme s3proxy.bucket-locator.1=bucket et s3proxy.bucket-locator.2=another-bucket, et note que la syntaxe glob est acceptée, de sorte qu'une seule règle peut couvrir plusieurs buckets. Un bucket (ou un glob) ne peut pas être attribué à plusieurs backends. Le wiki contient des exemples de configuration pour chaque backend, liés depuis le README.
Middlewares et points d'extension
S3Proxy peut modifier son comportement via des middlewares. Le README renvoie à des pages wiki pour chacun des éléments suivants : alias de bucket, portée de préfixe de bucket, localisateur de bucket, modélisation de cohérence éventuelle, simulation de gros objets, latence, lecture seule, renommage de blobs par regex, conteneurs de backend fragmentés, remplacement de classe de stockage, remplacement de métadonnées utilisateur et remplacement sans cache. Ces middlewares permettent aux déploiements de modifier la façon dont les requêtes sont traitées sans altérer le cœur du proxy. Le README n'explique pas le mécanisme de chaque middleware au-delà du nom et du lien wiki ; les détails doivent provenir de ces pages.
Limites de compatibilité de l'API S3
Le README est explicite sur les parties de l'API S3 que S3Proxy ne prend pas en charge. La liste comprend les ACL autres que private et public-read, l'hébergement BitTorrent, l'inventaire de buckets, les analyses, les métriques, le cycle de vie, la journalisation, les notifications, les politiques, la réplication, la suppression conditionnelle avec If-Match ou les en-têtes x-amz-*, les opérations CORS sur les buckets, l'hébergement de sites Web statiques, le verrouillage d'objets, les contrôles de propriété, le chiffrement côté serveur, le marquage, le versionnage, la pagination de ListParts avec part-number-marker, le bloc d'accès public, la lecture d'une seule partie d'un objet multipart, le payeur de requête, la restauration d'objets archivés, le contenu d'objet select, l'accélération de transfert et x-amz-expected-bucket-owner. S3Proxy émule néanmoins le téléversement multipart sur les backends filesystem et transient, en stockant un objet stub pour les métadonnées, et signale un propriétaire synthétique pour tous les objets et buckets. Plusieurs limitations varient selon le backend ; par exemple, azureblob et openstack-swift ne prennent pas en charge les ACL par objet, et azureblob et google-cloud-storage renvoient des ETag qui ne sont pas le MD5 de l'objet. Le README traite également de la gestion des écritures conditionnelles : aws-s3, azureblob et google-cloud-storage effectuent un PUT conditionnel sur le backend, tandis que filesystem et transient l'émulent dans un seul processus ; d'autres backends refusent le PUT conditionnel plutôt que de risquer une course de lecture-écriture.
CORS, SSL et configuration supplémentaire
S3Proxy dispose d'un traitement de base des pré-vols CORS et des requêtes/réponses réelles, configuré via des propriétés telles que s3proxy.cors-allow-origins, s3proxy.cors-allow-methods, s3proxy.cors-allow-headers et s3proxy.cors-allow-credential. CORS ne peut pas être défini par bucket, et s3proxy.cors-allow-all accepte toute origine et tout en-tête. Les requêtes CORS réelles sont prises en charge pour GET, PUT, POST, HEAD et DELETE. Le partage inter-origines est opt-in ; un proxy sans configuration CORS ne partage rien, et les réponses qui dépendent de l'origine de la requête portent Vary: Origin afin que les caches ne mélangent pas les réponses de différentes origines. Pour HTTPS, S3Proxy peut écouter sur un secure-endpoint, et le README pointe vers une page wiki sur la configuration d'un keystore et l'utilisation de SSL avec Docker, Kubernetes ou Java simple.
Support, références et licence
Le README liste les canaux de support : GitHub Issues, Stack Overflow avec le tag s3proxy, et une adresse e-mail de support commercial. Il référence également des projets ayant des objectifs similaires ou adjacents : Ceph s3-tests pour les tests de compatibilité, fake-s3, gofakes3, minio, S3 ninja et s3rver comme alternatives basées sur le système de fichiers, GlacierProxy et SwiftProxy pour d'autres API, s3mock d'Adobe, un chart Helm tiers, sbt-s3 pour les builds Scala, swift3 comme middleware S3 pour OpenStack Swift, et Zenko pour le multi-cloud. Le dépôt est sous licence Apache License 2.0, avec des droits d'auteur détenus par Andrew Gaul de 2014 à 2026. L'extrait de licence accorde des droits de reproduction, de préparation d'œuvres dérivées et de distribution, mais ne dit rien sur les garanties, le support ou les garanties de sécurité, et le README non plus.
Conclusion éditoriale
S3Proxy offre aux applications une interface S3 stable tout en permettant de changer le backend de stockage sous-jacent. Le README définit les backends pris en charge, les middlewares qui peuvent modifier le comportement et une longue liste de fonctionnalités S3 non implémentées. La licence Apache-2.0 accorde des droits de copie et de modification mais ne fait aucune promesse de garantie ou de support, et les métadonnées du dépôt indiquent qu'il n'est pas archivé au moment de la rédaction. Un test utile consiste à démarrer S3Proxy avec le fichier de configuration choisi, créer un bucket et envoyer un objet avec un client S3. Vérifiez ensuite la lecture, la suppression, les permissions et la traduction des erreurs du backend avant toute exposition réseau.
Notes de la communauté