Cloudflare ha anunciado el lanzamiento de Cloudflare Access for Workers, un conjunto de herramientas que permite vincular una política de Access directamente a un Worker o a todas las aplicaciones de Workers de una cuenta. Con esta vinculación, las aplicaciones quedan detrás del inicio de sesión de la empresa de forma predeterminada, sin depender de que cada desarrollador recuerde configurar por separado los controles de acceso.
La medida se produce en un contexto en el que los empleados, con el apoyo de herramientas de inteligencia artificial, pueden crear y desplegar aplicaciones con mayor rapidez. Cloudflare considera que esta velocidad también puede provocar que aplicaciones internas o datos privados se publiquen accidentalmente en la Internet pública, por lo que ha diseñado las nuevas herramientas para que la protección de las aplicaciones alojadas en Workers forme parte del propio proceso de despliegue.
Protección de la aplicación independientemente del método de acceso
Al activar Access en un Worker, Cloudflare impone la autenticación antes de que cualquier solicitud llegue al código de la aplicación. Esto se aplica tanto si el usuario accede a la aplicación mediante un dominio personalizado, una ruta, un subdominio en workers.dev o una URL de vista previa.
Anteriormente, Access se configuraba a nivel de nombre de host, lo que implicaba crear políticas separadas para cada dominio desde el que el usuario pudiera acceder al Worker. Añadir un nuevo dominio personalizado requería actualizar primero la política; de lo contrario, ese dominio quedaba accesible sin autenticación. Ahora, la política se vincula al propio Worker, lo que protege automáticamente los dominios y las URL asociados.
El ámbito de protección puede elegirse según las necesidades:
- Proteger únicamente las URL de vista previa, incluidas las URL de workers.dev o los dominios personalizados utilizados para las vistas previas.
- Proteger todos los nombres de host asociados a la aplicación, incluidos los dominios personalizados, las rutas, los dominios de workers.dev y las URL de vista previa.
Política predeterminada a nivel de cuenta
Los equipos que administran un gran número de aplicaciones de Workers pueden configurar una política de Access una sola vez a nivel de cuenta. De este modo, todas las aplicaciones actuales y futuras pasan a ser privadas desde el momento de su creación, con la posibilidad de determinar si la política cubrirá el tráfico de las URL de vista previa, el tráfico de producción o ambos.
La opción de proteger únicamente las vistas previas puede ser adecuada para las aplicaciones que deben mantenerse públicas en el entorno de producción, evitando al mismo tiempo exponer las versiones en desarrollo. Cloudflare también permite anular la política de cuenta para un Worker específico si se supone que debe ser público.
Quienes no necesiten una política general pueden aplicar Access directamente a un único Worker. La nueva pestaña de Access dentro de la interfaz del Worker muestra las políticas aplicables a la aplicación. Cuando existe más de una política, tiene prioridad la política más específica, en el siguiente orden: políticas de nombre de host, después políticas de Worker y, por último, políticas de cuenta.
Identidad del usuario dentro del código de la aplicación
Access también permite conocer la identidad del usuario que envía cada solicitud a la aplicación, incluidos su correo electrónico, nombre y grupos. Cloudflare afirma que estos datos pueden utilizarse para personalizar el contenido, aplicar permisos o registrar la actividad de cada usuario.
La información de identidad aparece dentro del objeto de contexto ctx del Worker, concretamente mediante ctx.access. La aplicación puede invocar ctx.access.getIdentity() para obtener la identidad del usuario autenticado, sin tener que implementar manualmente la verificación de un JSON Web Token, como analizar el token, comprobar su firma y extraer sus reclamaciones.
Access admite la conexión con el proveedor de identidad actual de la organización, y también permite restringir el acceso según direcciones de correo electrónico específicas, dominios de correo o grupos. En el caso de los agentes, el acceso puede concederse mediante tokens de servicio.
Pruebas locales y plataformas internas
El comportamiento de la identidad puede probarse localmente mediante wrangler dev, añadiendo la configuración de Access al archivo wrangler.jsonc para simular a un usuario autenticado. Así, el desarrollador puede cambiar el correo electrónico en la configuración y comprobar que se muestra el contenido adecuado para cada usuario antes del despliegue.
Cloudflare también ha presentado un ejemplo de código abierto de una plataforma interna que permite publicar sitios estáticos mediante arrastrar y soltar, haciendo que cada Worker publicado sea privado de forma predeterminada. Esta arquitectura aprovecha Workers for Platforms, donde el tráfico de las aplicaciones ubicadas dentro del espacio de nombres pasa por un único Worker distribuido. Al colocar una política de Access en ese Worker, las aplicaciones publicadas a través de él pasan a ser privadas de forma predeterminada.
Disponibilidad y arquitectura técnica
La función ya está disponible para todos a través del panel de control, junto con la documentación de Cloudflare Access for Workers para comenzar. La nueva capacidad se basa en FL2, un proxy modular creado con Rust que ejecuta la infraestructura perimetral de Cloudflare.
Para permitir aplicar Access a nivel de Worker en lugar de a nivel de nombre de host, Cloudflare separó el enrutamiento de Workers de su ejecución y trasladó la lógica de enrutamiento a una fase anterior a Access. La empresa explica que el sistema FL2, con módulos definidos y fases ordenadas, la ayudó a gestionar este cambio, ya que cada componente declara sus entradas y salidas de forma estable, lo que permitió utilizar el compilador para detectar interacciones incorrectas entre las fases durante la reestructuración.