Permisos Cloudflare Workers: aísle el despliegue de cada cliente

Los cuatro roles de Worker de Cloudflare convierten una credencial de despliegue compartida en un límite específico para cada cliente. Desde el 15 de septiembre de 2026, una agencia puede permitir que la tarea de CI de un cliente despliegue un Worker existente sin concederle también el derecho a eliminarlo ni acceso a todos los demás Workers de la cuenta, siempre que ninguna política más amplia extienda esos permisos Cloudflare Workers.

El cambio importante en los permisos Cloudflare Workers es el alcance

Un permiso tiene dos componentes. El rol determina qué puede hacer una identidad. El alcance establece dónde puede hacerlo.

Cloudflare ahora permite combinar un rol de Worker con el alcance de un Worker individual para un miembro del equipo, un User Group, un agente o un token de API. El mismo rol todavía puede abarcar todos los Workers, pero ya no es obligatorio.

Puede parecer una función administrativa menor. Para un estudio o una agencia que gestiona varios clientes dentro de una sola cuenta de Cloudflare, cambia por completo la entrega: la credencial de despliegue del Cliente A puede detenerse en el Worker del Cliente A.

El lanzamiento del 15 de septiembre está disponible para todos los clientes y funciona desde el dashboard, la API o Terraform.

Este es el conjunto completo de roles de la referencia de roles de Workers:

Esta separación resulta útil porque depurar, revisar código, publicar código y eliminar el servicio son cuatro tareas distintas. No deberían heredar todas la misma credencial.

Los permisos anteriores de Cloudflare para Workers se aplicaban a toda la cuenta. El modelo que los sustituye puede abarcar Developer Platform, todos los Workers o un único Worker existente. Una política de Workers a nivel de producto cubre todos los Workers actuales y futuros. Una política por Worker solo cubre los que se seleccionen.

Existe un límite estructural: no se puede conceder acceso específico a un Worker que todavía no existe. Crear uno nuevo sigue requiriendo el rol Admin a nivel de producto.

Qué cambia al entregar un Worker a un cliente

Pensemos en una agencia pequeña que aloja un Worker para cada cliente. Su flujo de despliegue necesita publicar versiones nuevas de client-a-api. No necesita crear Workers, eliminar ese Worker ni intervenir en client-b-checkout.

Antes de este lanzamiento, los permisos habituales de CI para Workers —que Cloudflare ahora clasifica como heredados— abarcaban toda la cuenta. Eso dejaba dos opciones claras: aceptar una credencial amplia o separar al cliente en otra cuenta. El alcance por Worker añade una tercera: conservar la estructura de la cuenta, pero conceder al token de despliegue el rol Editor únicamente sobre client-a-api.

El cálculo de la suscripción no cambia porque los controles por Worker están disponibles para todos los clientes. Lo que cambia es el costo operativo.

El modelo omite una contrapartida importante. Doce credenciales específicas para clientes implican más secretos que emitir, almacenar y rotar que un único token compartido. La ventaja no está en tener menos credenciales, sino en reducir el conjunto de proyectos que deben investigarse cuando una credencial falla o se filtra.

Un fundador que trabaja solo, con un Worker y sin acceso compartido al despliegue, apenas notará el cambio. Tampoco lo hará un equipo que conceda deliberadamente a su grupo de plataforma el control de todos los Workers. Esta novedad importa cuando varias personas, clientes o tareas automatizadas comparten una cuenta de Cloudflare, pero no deberían compartir el mismo radio de impacto.

Cómo dar acceso suficiente a una tarea de despliegue de un cliente

La primera entrega más limpia parte de un Worker existente con una Route o un Custom Domain estables. Así, la tarea de despliegue no necesita crear el Worker ni modificar dominios.

1. 1

   Defina la tarea antes de elegir el rol

   Empiece con una frase: «Este flujo despliega versiones nuevas del Worker existente client-a-api».

   Esa frase apunta al rol Editor con alcance de Worker individual. Si la tarea debe crear un Worker nuevo, necesita Admin a nivel de producto. Si debe añadir, cambiar o quitar una Route o un Custom Domain, también necesita Workers Routes Write para cada zona afectada.

2. 2

   Cree un token de API propiedad de la cuenta

   En Cloudflare, vaya a Manage Account > Account API Tokens y cree un token propiedad de la cuenta. Configure el alcance como Specified Workers, seleccione client-a-api y después elija Editor.

   Para este flujo, utilice un token propiedad de la cuenta, no el token de usuario de una persona. Cloudflare presenta estos tokens como identidades de servicio para integraciones duraderas, de modo que el despliegue no se detenga cuando se marche quien lo creó. Para crear o actualizar uno se necesita el permiso Super Administrator.

3. 3

   Ejecute Wrangler con ese token

   Guarde el token en el almacén de secretos del sistema de despliegue. Cloudflare documenta estas variables de entorno para Wrangler:

   export CLOUDFLARE_API_TOKEN="<YOUR_API_TOKEN>"
   export CLOUDFLARE_ACCOUNT_ID="<YOUR_ACCOUNT_ID>"
   npx wrangler deploy

   Ejecute el comando desde el proyecto configurado para el Worker existente. wrangler login no sirve como sustituto en este caso porque su flujo OAuth todavía no admite autorización granular.

4. 4

   Cambie al token nuevo y retire el acceso amplio

   Despliegue una versión inocua con el token nuevo y confirme que se actualiza el Worker previsto. Compruebe que el token no tenga ningún rol de Workers a nivel de producto ni alcance sobre recursos ajenos.

   Después, elimine de ese flujo el antiguo secreto de despliegue con permisos amplios. Mantener ambas credenciales durante la prueba es razonable; conservarlas después anula el límite que se acaba de crear.

Esa es toda la entrega necesaria para un despliegue rutinario. La tarea del cliente puede actualizar, cargar, desplegar, revertir, cambiar el nombre y administrar secretos de ese Worker porque esas acciones están incluidas en Editor. No puede eliminar el Worker y la política por Worker no le da acceso a otros Workers.

Cuatro tareas y cuatro políticas razonables

Un agente de soporte que solo necesita pruebas

Conceda a un agente de depuración el rol Metadata Read-Only sobre el Worker afectado. Podrá consultar configuración, métricas, logs y trazas sin leer el código fuente ni cambiar el servicio.

El resultado es un flujo de soporte capaz de recopilar pruebas sin convertirse discretamente en un flujo de revisión de código o despliegue. El mismo rol basta para ejecutar wrangler tail sobre ese Worker.

Un desarrollador externo que revisa el proyecto de un cliente

Conceda al contratista Content Read-Only sobre el Worker del cliente. Podrá inspeccionar el código desplegado y la configuración, pero no modificarlos ni desplegar cambios.

Así se obtiene un límite de revisión más claro. No hace falta conceder Editor solo porque la persona que revisa necesite entender qué está en ejecución.

Un pipeline de CI específico para un cliente

Conceda al token propiedad de la cuenta el rol Editor sobre un solo Worker existente. Podrá publicar y revertir versiones sin eliminar el Worker ni alcanzar otros Workers.

Este es el caso que mejor encaja con la entrega de una agencia porque la credencial pertenece al flujo, no a un miembro del personal. Si también utiliza agentes de navegador en proyectos de clientes, los controles de hosts aprobados de Cloudflare resuelven otra mitad del límite: a dónde puede ir el navegador. Este lanzamiento controla qué Worker puede modificar la identidad de despliegue.

Un responsable de plataforma que gestiona cambios de ciclo de vida

Reserve Admin para la persona o la automatización que realmente necesite permisos de eliminación. Mantenga Admin a nivel de producto en manos de quien crea los Workers y, una vez terminado cada Worker, entréguelo a las políticas más limitadas del trabajo diario.

La ventaja es una separación visible entre las tareas de ciclo de vida y las entregas rutinarias. Una tarea de despliegue no necesita la misma autoridad que quien crea y retira los servicios de los clientes.

El límite es más estrecho, pero no equivale a un aislamiento completo

La ventaja principal es real, pero resumirla como «solo un Worker» puede ser peligrosamente simplista.

Los Durable Objects exigen el mismo cuidado. No tienen roles ni alcances independientes, sino que heredan el acceso del Worker que los implementa. Metadata Read-Only incluye las métricas, los logs y las trazas de Durable Objects sin acceso a los datos almacenados, pero Editor también alcanza el umbral documentado para usar Data Studio y consultar o modificar datos en un Durable Object respaldado por SQLite.

Las Routes constituyen otro límite independiente. Editor basta para desplegar una versión nueva si no cambia una Route ni un Custom Domain existentes. Modificar esa conexión también requiere Workers Routes Write para cada zona afectada. Cloudflare señala además que los Custom Domains no admiten actualmente roles por Worker.

Por último, los permisos de Cloudflare son acumulativos. Una política directa y limitada no anula otra más amplia heredada mediante un User Group. La vista Members muestra los permisos directos, mientras que las políticas heredadas de grupos deben revisarse en la pestaña Groups. Si se omite esa comprobación, la pantalla puede mostrar la política limitada que se pretendía aplicar aunque el conjunto efectivo de permisos siga siendo amplio.

Quién debería actuar ahora

Conviene actuar esta semana si una cuenta contiene Workers de varios clientes y alguna persona, agente o tarea de CI todavía conserva permisos sobre todos los Workers para realizar una tarea que solo necesita uno. La ventaja es más evidente cuando el Worker ya existe y las conexiones de dominio no cambian durante los despliegues rutinarios.

Espere antes de restringir el token si el flujo crea Workers, modifica Routes o Custom Domains, o depende del acceso directo a productos de datos vinculados. Trace primero esas acciones o el siguiente despliegue fallará a mitad del proceso.

El cambio no le afecta si nunca comparte el acceso a Workers, opera un solo Worker o mantiene deliberadamente el despliegue bajo un equipo de plataforma con responsabilidad sobre toda la cuenta.

La medida para el lunes

Empiece por cambiar la política de permisos que utiliza el despliegue de CI de un cliente existente. Configure un token propiedad de la cuenta con Editor, limite su alcance a ese Worker, enumere cada binding y Durable Object heredado que pueda afectar, revise las políticas directas y de grupo, y luego despliegue sin cambiar la Route ni el Custom Domain.

Cuando la ejecución funcione, elimine el antiguo secreto con acceso a todos los Workers. Ese único cambio crea un límite real y un patrón que puede repetirse con el siguiente cliente.

Si busca más notas operativas y claras sobre cambios en plataformas, suscríbase al boletín.