Até agora, muitas equipes precisavam conceder acesso amplo à conta para que uma pessoa, pipeline ou agente alterasse um único Cloudflare Worker. A Cloudflare passou a permitir autorização por aplicação, com quatro papéis distintos. É uma mudança menos chamativa que uma API nova, mas bem mais importante para aplicar privilégio mínimo.
Os quatro papéis
- Metadata Read-Only: consulta configurações e observabilidade, sem ler o código ou conteúdo do Worker.
- Content Read-Only: inclui acesso de leitura ao conteúdo.
- Editor: lê e altera código e configurações, mas não cria nem exclui a aplicação.
- Admin: controle completo, incluindo criação e exclusão.
A separação entre metadados e conteúdo é especialmente útil para suporte e observabilidade. Nem todo mundo que investiga latência ou erros precisa ler código, variáveis e artefatos associados à aplicação.
CI e agentes deixam de carregar a chave do reino
Tokens de API podem ser limitados a um Worker específico. Um pipeline de deploy recebe papel Editor naquele recurso, sem poder apagar a aplicação e sem ganhar escrita sobre todos os demais Workers. Um agente de diagnóstico pode receber apenas metadados ou conteúdo em modo de leitura.
O recurso está disponível no painel, na API e no Terraform para todos os planos. Isso importa porque autorização manual tende a se degradar. Gerenciar grants como código permite revisão, histórico e reprodução entre ambientes.
Durable Objects seguem o Worker
O acesso a Durable Objects vinculados é herdado do Worker. É uma conveniência, mas também um limite de granularidade: conceder conteúdo ou edição ao Worker implica considerar os objetos que fazem parte dele. O inventário de dados precisa acompanhar o inventário de código.
D1, R2 e KV ainda não receberam o mesmo modelo individual neste anúncio. A Cloudflare diz que pretende expandir a autorização granular. Portanto, um Worker com acesso a esses serviços pode continuar sendo uma rota indireta para dados que exigem controles adicionais.
Como migrar sem criar caos de permissões
- Liste usuários e tokens que hoje têm permissão ampla sobre Workers.
- Mapeie cada identidade a aplicações e ações realmente necessárias.
- Crie tokens separados para deploy, observabilidade e automação.
- Teste respostas 403 e documente como pedir elevação temporária.
- Revogue grants antigos somente depois de confirmar o novo fluxo.
As permissões legadas continuam funcionando e não há data de descontinuação anunciada. Isso reduz o risco de quebra imediata, mas também facilita adiar a migração para sempre. O maior ganho vem justamente de remover credenciais amplas antes que elas apareçam em um log, pipeline comprometido ou agente com escopo maior que a tarefa.
