Cloudflare anunció la disponibilidad de controles de acceso para cada Worker, de modo que se pueda conceder a un usuario, un agente de software o un token de API permiso para interactuar con una aplicación específica sin acceder al resto de los recursos de la cuenta. La medida llega con cuatro nuevos roles para la plataforma de desarrolladores, diseñados para separar la supervisión de la aplicación, la lectura de su contenido y su modificación o administración completa.
Los controles están disponibles para todos los clientes desde el 15 de septiembre de 2026, y pueden configurarse desde el panel de control de Cloudflare o mediante la API o Terraform. También pueden aplicarse a un usuario individual o a un User Group, de modo que todos los miembros del grupo hereden la misma política.
Cuatro niveles de permisos
- Metadata Read-Only: permite consultar listas de recursos, su configuración y datos de supervisión, como métricas, registros y trazas, sin acceder al contenido del producto ni al código. Es adecuado para investigar fallos cuando no se necesita leer el código fuente.
- Content Read-Only: permite leer el contenido del producto, como el código de un Worker o el contenido de una base de datos D1, sin modificar ni implementar cambios.
- Editor: permite leer y escribir contenido y actualizar la configuración, pero no permite crear ni eliminar recursos. Cloudflare lo presenta como una opción adecuada para sistemas de CI/CD que necesitan implementar cambios en un Worker específico.
- Admin: concede control total sobre el recurso, incluida su creación, cambio de nombre, eliminación y la concesión de acceso a otros usuarios, con la posibilidad de limitar este permiso a un único Worker en lugar de a toda la cuenta.
¿Qué cambia en la práctica?
El equipo de operaciones puede conceder a un ingeniero o agente el permiso Metadata Read-Only para revisar la configuración, las métricas, los registros y las trazas sin exponer el código. Del mismo modo, un agente puede revisar el código mediante Content Read-Only sin tener la capacidad de implementarlo ni cambiar la configuración de la aplicación.
En las canalizaciones de CI/CD, se puede crear un token de API con el rol Editor y limitarlo a un único Worker. Si la canalización se configura incorrectamente o el token queda expuesto, su capacidad seguirá restringida a implementar cambios en esa aplicación, sin poder eliminar el Worker ni modificar otras aplicaciones de la cuenta. Cloudflare explica que estos permisos se aplican en tres ámbitos: toda la plataforma de desarrolladores, un producto concreto como Workers o un recurso específico como un único Worker.
Limitaciones importantes sobre el ámbito y las conexiones
El acceso a un Worker por sí solo no basta para añadir, cambiar o eliminar una Route o un Custom Domain. Estas operaciones requieren el permiso Editor sobre el Worker, además del permiso específico de Workers Routes para la zona. Esta separación permite gestionar cómo se dirige el tráfico a la aplicación sin conceder permisos más amplios sobre la configuración del dominio.
Una vez configurada la ruta, el sistema de CI/CD puede seguir implementando nuevas versiones mientras la implementación no cambie la conexión existente, sin concederle acceso a los dominios, las bases de datos ni el almacenamiento asociado. Durable Objects también dependen de los permisos del Worker que los ejecuta: el rol Metadata Read-Only permite acceder a sus métricas, registros y trazas, pero no leer los datos almacenados en ellos. El acceso a Data Studio, que puede consultar y modificar datos, requiere el rol Editor.
Mensajes de error y versiones antiguas
Cloudflare actualizó las respuestas de la API cuando se rechazan operaciones, de modo que ya no se limitan al error general 403 Forbidden, sino que incluyen un enlace a la documentación que identifica el permiso requerido. Se espera que esto ayude a usuarios y agentes a configurar los permisos con precisión en lugar de ampliarlos al azar.
La empresa recomienda migrar a los nuevos roles en lugar de utilizar los permisos antiguos específicos de Workers, pero no ha anunciado una fecha para retirarlos, y las asignaciones actuales seguirán funcionando hasta que se comunique un aviso previo. Cloudflare planea ampliar el mismo modelo a otros productos, entre ellos D1, R2 y KV, para que sea posible limitar el acceso a una base de datos o un espacio de almacenamiento concretos.
Lectura de certi.news
El cambio real no consiste únicamente en añadir un nuevo rol administrativo, sino en trasladar el control del nivel de la cuenta o del producto al nivel del recurso, con una separación clara entre los datos de supervisión, el contenido y la ejecución. Esto es especialmente importante para los equipos que utilizan agentes de software o canalizaciones de implementación automatizadas, porque un error o la filtración del token puede quedar contenido en un único Worker. En cambio, la gestión de rutas y dominios sigue siendo un punto que requiere un permiso independiente, y la compatibilidad con D1, R2 y KV todavía se menciona como un plan futuro, no como una disponibilidad actual. En cuanto a la continuidad de los permisos antiguos sin una fecha de retirada anunciada, significa que las organizaciones tendrán que revisar gradualmente sus políticas en lugar de suponer una migración inmediata.