A Cloudflare anunciou a disponibilidade de controles de acesso no nível de cada Worker, permitindo conceder a um usuário, agente de software ou token de API permissão para interagir com um aplicativo específico sem acessar os demais recursos da conta. A medida vem acompanhada de quatro novas funções para a plataforma de desenvolvedores, projetadas para separar o monitoramento do aplicativo, a leitura de seu conteúdo e sua modificação ou administração completa.
Os controles estão disponíveis para todos os clientes a partir de 15 de setembro de 2026 e podem ser configurados pelo painel da Cloudflare, pela API ou pelo Terraform. Eles também podem ser aplicados a um usuário individual ou a um User Group, fazendo com que todos os membros do grupo herdem a mesma política.
Quatro níveis de permissões
- Metadata Read-Only: permite consultar listas de recursos, suas configurações e dados de monitoramento, como métricas, logs e traces, sem acesso ao conteúdo do produto ou ao código. É adequado para investigar falhas quando a leitura do código-fonte não é necessária.
- Content Read-Only: permite ler o conteúdo do produto, como o código de um Worker ou o conteúdo de um banco de dados D1, sem modificar ou implantar alterações.
- Editor: permite ler e escrever conteúdo e atualizar configurações, mas não permite criar ou excluir recursos. A Cloudflare o apresenta como uma opção adequada para sistemas de CI/CD que precisam implantar alterações em um Worker específico.
- Admin: concede controle total sobre o recurso, incluindo criação, renomeação, exclusão e concessão de acesso a outros usuários, com a possibilidade de limitar essa permissão a um único Worker em vez de toda a conta.
O que muda na prática?
A equipe de operações pode conceder a um engenheiro ou agente a permissão Metadata Read-Only para verificar configurações, métricas, logs e traces sem expor o código. Da mesma forma, um agente de revisão de código pode usar Content Read-Only sem ter capacidade de implantá-lo ou alterar as configurações do aplicativo.
Nos fluxos de CI/CD, é possível criar um token de API com a função Editor e restringi-lo a um único Worker. Se o fluxo for configurado incorretamente ou o token for exposto, sua capacidade continuará limitada à implantação de alterações nesse aplicativo, sem excluir o Worker ou modificar outros aplicativos da conta. A Cloudflare explica que essas permissões são aplicadas em três escopos: toda a plataforma de desenvolvedores, um produto específico, como Workers, ou um recurso específico, como um único Worker.
Limitações importantes de escopo e conexões
O acesso a um Worker, por si só, não é suficiente para adicionar, alterar ou excluir uma Route ou um Custom Domain. Essas operações exigem a permissão Editor no Worker, além da permissão específica de Workers Routes para a zona. Essa separação permite administrar como o tráfego é direcionado ao aplicativo sem conceder permissões mais amplas sobre as configurações do domínio.
Depois que a rota é configurada, o sistema de CI/CD pode continuar implantando novas versões desde que a implantação não altere a conexão existente, sem receber acesso aos domínios, bancos de dados ou armazenamento associados. Os Durable Objects também dependem das permissões do Worker que os executa; a função Metadata Read-Only permite acessar suas métricas, logs e traces, mas não permite ler os dados armazenados neles. O acesso ao Data Studio, que pode consultar e modificar dados, exige a função Editor.
Mensagens de erro e versões antigas
A Cloudflare atualizou as respostas da API quando as operações são rejeitadas. Em vez de se limitarem ao erro geral 403 Forbidden, elas incluem um link para a documentação que especifica a permissão necessária. A expectativa é que isso ajude usuários e agentes a configurar as permissões com precisão, em vez de ampliá-las aleatoriamente.
A empresa recomenda migrar para as novas funções em vez das permissões antigas específicas de Workers, mas não anunciou uma data para descontinuá-las; as atribuições atuais continuarão funcionando até que seja fornecido um aviso prévio. A Cloudflare planeja ampliar o mesmo modelo para outros produtos, incluindo D1, R2 e KV, permitindo restringir o acesso a um banco de dados ou espaço de armazenamento específico.
Leitura da certi.news
A mudança efetiva aqui não é apenas a adição de uma nova função administrativa, mas a transferência do controle do nível da conta ou do produto para o nível do recurso, com uma separação clara entre dados de monitoramento, conteúdo e execução. Isso é especialmente importante para equipes que usam agentes de software ou pipelines de implantação automatizados, pois um erro ou vazamento de token pode ser contido em um único Worker. Por outro lado, o gerenciamento de rotas e domínios continua sendo um ponto que exige uma permissão independente, e o suporte a D1, R2 e KV ainda é mencionado como um plano futuro, não como uma disponibilidade atual. Já a continuidade das permissões antigas sem uma data de descontinuação anunciada significa que as organizações precisarão revisar gradualmente suas políticas, em vez de presumir uma migração imediata.