AWS Glue ajoute OAuth au catalogue Iceberg REST et offre une alternative aux clés AWS pour les moteurs tiers
Le 26 octobre 2026, AWS Glue Data Catalog accepte les jetons OAuth 2.0 sur son endpoint Iceberg REST, en plus de SigV4, via l’échange de jetons RFC 8693. Les équipes data qui fédèrent leurs tables Iceberg à Spark, Trino ou une plateforme tierce doivent basculer sur ces jetons à durée courte.
26 octobre 2026. AWS annonce que Glue Data Catalog accepte désormais les jetons OAuth 2.0 sur son endpoint Iceberg REST, en plus de la signature SigV4. 26 octobre 2026, même jour. La documentation précise le mécanisme : un jeton d’identité OIDC est échangé contre un jeton Glue à durée courte, selon la RFC 8693. Avant cette annonce. Seule la signature SigV4 était acceptée, ce qui forçait tout moteur tiers à détenir des clés AWS longue durée. Le point qui compte : une équipe data peut désormais exposer ses tables Iceberg à Snowflake, Starburst ou un DuckDB distant sans jamais leur remettre une clé IAM.
Ce que l’annonce change : OAuth devient le chemin d’authentification standard
La spécification Apache Iceberg REST Catalog définit OAuth 2.0 comme son mécanisme d’authentification de référence. Les moteurs de requête qui implémentent nativement le catalogue — Apache Spark, Trino, Apache Flink — savent déjà parler ce protocole. Jusqu’ici, AWS constituait l’exception : son endpoint Iceberg REST n’acceptait que la SigV4, une signature propre à AWS que ces moteurs ne génèrent pas nativement.
Le correctif d’AWS consiste à ouvrir un second chemin. Grâce à l’échange de jetons de la RFC 8693, un client échange un jeton d’identité OpenID Connect (OIDC) contre un jeton bearer à durée courte, limité au périmètre Glue. Ce jeton est ensuite présenté dans les requêtes IRC exactement comme le ferait n’importe quel client Iceberg du marché. Le résultat est un patron d’authentification unique, cohérent d’un moteur à l’autre.
L’annonce est disponible dans toutes les régions où AWS Glue et Lake Formation sont présents. Elle ne retire rien : SigV4 reste accepté pour les clients internes qui l’utilisent déjà.
Pourquoi SigV4 bloquait les moteurs tiers
La SigV4 est une signature calculée à partir d’une clé d’accès et d’un secret, portée par les en-têtes de chaque requête. Elle est robuste, mais elle impose deux contraintes à un moteur tiers.
D’abord, l’implémentation. Trino, Spark ou Flink parlent OAuth pour le catalogue Iceberg parce que c’est la norme de l’écosystème ; leur demander de signer en SigV4 exige un connecteur spécifique à AWS ou une couche de traduction maison. Ensuite, le secret. Pour signer, le moteur doit détenir une clé d’accès AWS — une paire statique qui, une fois partagée avec Snowflake ou un partenaire d’intégration, vit sur une machine que vous ne contrôlez pas, avec un cycle de rotation que vous ne maîtrisez plus.
C’est précisément le scénario que l’annonce cherche à éliminer. AWS le formule lui-même : on peut désormais « accorder à des partenaires un accès fédéré à vos tables Iceberg sans distribuer de clés AWS ». Le jeton OAuth est à durée courte, scopé au catalogue Glue, et révocable par les canaux IAM.
Le modèle de sécurité : des jetons courts, toujours gouvernés par IAM et Lake Formation
Il serait tentant de lire cette annonce comme un affaiblissement du contrôle. C’est l’inverse. Le jeton bearer émis par l’échange RFC 8693 n’est pas une permission en soi : l’autorisation reste entièrement décidée par IAM et par Lake Formation.
Concrètement, le flux se déroule en trois temps. Le client présente son jeton OIDC au point d’échange, qui vérifie l’identité et émet un jeton Glue à durée de vie courte. Ce jeton porte une portée limitée — lire les métadonnées d’un catalogue, exécuter des requêtes sur des tables précises — et rien d’autre. Enfin, chaque appel au catalogue Iceberg est contrôlé par les politiques IAM et les permissions Lake Formation qui s’appliquent à l’identité sous-jacente, pas par le jeton lui-même.
La conséquence pour un responsable data est mesurable. Une clé IAM partagée avec un partenaire est un secret qui peut fuir et ne rien signaler pendant des mois. Un jeton bearer à durée courte limite la fenêtre d’exploitation à quelques minutes, et sa révocation suit les chemins IAM habituels. C’est la même logique que STS a apportée aux EC2 il y a quinze ans, appliquée au catalogue de données.
Ce qu’il faut faire, concrètement
L’annonce ne force personne à migrer. SigV4 continue de fonctionner, et pour un accès interne — Athena, EMR, un job Glue — il reste le choix par défaut et le plus simple. La bascule vers OAuth ne se justifie que lorsque le catalogue Iceberg traverse une frontière d’organisation.
Voici les gestes qui comptent.
Inventoriez qui accède au catalogue Iceberg aujourd’hui. Cherchez les clés IAM qui ont été remises à un partenaire, un connecteur SaaS ou un moteur auto-hébergé. Ce sont elles qui portent le risque : une clé statique distribuée hors de votre périmètre.
Basculez les accès tiers sur l’échange de jetons OAuth. Pour les moteurs compatibles Iceberg REST, configurez le catalogue pour s’authentifier en OAuth 2.0 plutôt qu’en SigV4, en utilisant AWS Sign-In comme fournisseur d’identité.
Supprimez les clés statiques devenues inutiles. Une fois l’accès OAuth en place et vérifié, révoquez les clés d’accès correspondantes. Une clé qui n’existe plus ne peut pas fuir.
Gardez Lake Formation comme point de décision. Le jeton bearer ne remplace pas vos politiques de granularité. Continuez à limiter l’accès table par table, colonne par colonne, dans Lake Formation.
Verdict
Si vous fédérez vos tables Iceberg à des moteurs tiers — une plateforme SaaS comme Snowflake ou Starburst, un Trino auto-hébergé, un DuckDB distant —, activez l’échange de jetons OAuth dès maintenant et retirez les clés IAM que vous leur aviez remises : le gain est une surface de secret réduite à quelques minutes de validité, sans changer votre modèle de gouvernance. Si tout votre accès reste dans le périmètre AWS — Athena, EMR, jobs Glue —, SigV4 reste parfaitement adapté et vous n’avez aucune raison de migrer. La décision tient en une phrase : le OAuth est fait pour la frontière de votre organisation, pas pour l’intérieur.