Cloudflare a annoncé le lancement de Cloudflare Access for Workers, un ensemble d’outils permettant de relier une politique Access directement à un Worker ou à toutes les applications Workers d’un compte. Grâce à cette liaison, les applications sont par défaut placées derrière la connexion de l’entreprise, sans dépendre du fait que chaque développeur se souvienne de configurer séparément les contrôles d’accès.
Cette initiative intervient alors que les employés, aidés par les outils d’intelligence artificielle, peuvent créer et déployer des applications plus rapidement. Cloudflare estime que cette rapidité peut également entraîner la publication accidentelle d’applications internes ou de données privées sur l’Internet public. L’entreprise a donc conçu les nouveaux outils afin que la protection des applications hébergées sur Workers fasse partie intégrante du processus de déploiement.
Protéger l’application quelle que soit la méthode d’accès
Lorsqu’Access est activé sur un Worker, Cloudflare impose l’authentification avant qu’une requête n’atteigne le code de l’application. Cela s’applique que l’utilisateur accède à l’application via un domaine personnalisé, un chemin, un sous-domaine workers.dev ou une URL de prévisualisation.
Auparavant, la configuration d’Access se faisait au niveau du nom d’hôte, ce qui impliquait de créer des politiques distinctes pour chaque domaine par lequel l’utilisateur pouvait accéder au Worker. L’ajout d’un nouveau domaine personnalisé nécessitait auparavant de mettre à jour la politique en premier ; dans le cas contraire, ce domaine devenait accessible sans authentification. Désormais, la politique est liée au Worker lui-même, ce qui protège automatiquement les domaines et les URL qui lui sont associés.
La portée de la protection peut être choisie selon les besoins :
- Protéger uniquement les URL de prévisualisation, notamment les URL workers.dev ou les domaines personnalisés utilisés pour les prévisualisations.
- Protéger tous les noms d’hôte associés à l’application, notamment les domaines personnalisés, les chemins, les domaines workers.dev et les URL de prévisualisation.
Une politique par défaut au niveau du compte
Les équipes qui gèrent un grand nombre d’applications Workers peuvent configurer une politique Access une seule fois au niveau du compte. Toutes les applications existantes et futures deviennent alors privées dès leur création, avec la possibilité de définir si la politique couvrira le trafic des URL de prévisualisation, le trafic de production ou les deux.
L’option limitée aux prévisualisations peut convenir aux applications que l’on souhaite maintenir publiques en production tout en empêchant l’exposition des versions en cours de développement. Cloudflare permet également de remplacer la politique du compte pour un Worker donné s’il est censé être public.
Les utilisateurs qui n’ont pas besoin d’une politique globale peuvent appliquer Access directement à un seul Worker. Le nouvel onglet Access de l’interface du Worker affiche les politiques en vigueur pour l’application. Lorsque plusieurs politiques sont présentes, la politique la plus spécifique est prioritaire, dans l’ordre suivant : politiques de nom d’hôte, puis politiques de Worker, puis politiques de compte.
L’identité de l’utilisateur dans le code de l’application
Access permet également de connaître l’identité de l’utilisateur qui envoie chaque requête à l’application, notamment son adresse e-mail, son nom et ses groupes. Cloudflare indique que ces données peuvent servir à personnaliser le contenu, à appliquer des autorisations ou à enregistrer l’activité de chaque utilisateur.
Les informations d’identité apparaissent dans l’objet de contexte ctx du Worker, plus précisément via ctx.access. L’application peut appeler ctx.access.getIdentity() pour obtenir l’identité de l’utilisateur authentifié, sans devoir vérifier manuellement le JSON Web Token, par exemple en analysant le jeton, en vérifiant sa signature et en extrayant ses revendications.
Access prend en charge la connexion au fournisseur d’identité actuel de l’organisation. Il est également possible de restreindre l’accès selon des adresses e-mail précises, des domaines de messagerie ou des groupes. Pour les agents, l’accès peut être accordé au moyen de jetons de service.
Tests locaux et plateformes internes
Le comportement de l’identité peut être testé localement avec wrangler dev en ajoutant la configuration Access au fichier wrangler.jsonc afin de simuler un utilisateur authentifié. Le développeur peut ainsi modifier l’adresse e-mail dans la configuration et vérifier l’affichage du contenu approprié pour chaque utilisateur avant le déploiement.
Cloudflare a également présenté un exemple open source de plateforme interne permettant de déployer des sites statiques par glisser-déposer, chaque Worker déployé étant privé par défaut. Cette architecture exploite Workers for Platforms, où le trafic des applications présentes dans l’espace de noms transite par un Worker distribué unique. En plaçant une politique Access sur ce Worker, les applications déployées par son intermédiaire deviennent privées par défaut.
Disponibilité et architecture technique
La fonctionnalité est désormais disponible pour tous via le tableau de bord, et la documentation Cloudflare Access for Workers est proposée pour commencer. Cette nouvelle capacité repose sur FL2, un proxy modulaire développé en Rust qui exécute l’infrastructure périphérique de Cloudflare.
Pour permettre l’application d’Access au niveau du Worker plutôt qu’au niveau du nom d’hôte, Cloudflare a séparé le routage des Workers de leur exécution et déplacé la logique de routage vers une étape précédant Access. L’entreprise explique que le système FL2, composé de modules définis et d’étapes ordonnées, l’a aidée à gérer ce changement : chaque composant déclare de manière stable ses entrées et ses sorties, ce qui a permis d’utiliser le compilateur pour détecter les interactions incorrectes entre les étapes pendant la restructuration.