A Cloudflare anunciou o lançamento do Cloudflare Access for Workers, um conjunto de ferramentas que permite conectar uma política do Access diretamente a um Worker ou a todos os aplicativos Workers dentro da conta. Com essa conexão, os aplicativos ficam atrás de um login da empresa por padrão, sem depender de que cada desenvolvedor se lembre de configurar os controles de acesso separadamente.
A iniciativa ocorre em um contexto no qual os funcionários, com o apoio de ferramentas de inteligência artificial, conseguem criar e implantar aplicativos com mais rapidez. A Cloudflare considera que essa velocidade também pode levar à publicação acidental de aplicativos internos ou dados privados na internet pública. Por isso, a empresa projetou as novas ferramentas para tornar a proteção dos aplicativos hospedados no Workers parte do próprio processo de implantação.
Proteção do aplicativo independentemente da forma de acesso
Quando o Access é ativado em um Worker, a Cloudflare aplica a autenticação antes que qualquer solicitação chegue ao código do aplicativo. Isso se aplica independentemente de o usuário acessar o aplicativo por meio de um domínio personalizado, de um caminho, de um subdomínio em workers.dev ou de uma URL de visualização.
Anteriormente, a configuração do Access era feita no nível do nome do host, o que significava criar políticas separadas para cada domínio pelo qual o usuário pudesse acessar um Worker. Adicionar um novo domínio personalizado exigia atualizar primeiro a política; caso contrário, esse domínio poderia ser acessado sem autenticação. Agora, a política é vinculada ao próprio Worker, protegendo automaticamente os domínios e URLs associados a ele.
É possível escolher o escopo da proteção conforme a necessidade:
- Proteger apenas as URLs de visualização, incluindo URLs de workers.dev ou domínios personalizados usados para visualizações.
- Proteger todos os nomes de host associados ao aplicativo, incluindo domínios personalizados, caminhos, domínios workers.dev e URLs de visualização.
Política padrão no nível da conta
Equipes que gerenciam um grande número de aplicativos Workers podem configurar uma política do Access uma única vez no nível da conta. Nesse caso, todos os aplicativos atuais e futuros se tornam privados desde o momento de sua criação, com a possibilidade de definir se a política abrangerá o tráfego das URLs de visualização, o tráfego de produção ou ambos.
A opção de proteger apenas as visualizações pode ser adequada para aplicativos que devem permanecer públicos no ambiente de produção, impedindo a exposição das versões em desenvolvimento. A Cloudflare também permite substituir a política da conta para um Worker específico caso ele deva ser público.
Quem não precisa de uma política abrangente pode aplicar o Access diretamente a um único Worker. A nova guia do Access na interface do Worker exibe as políticas aplicáveis ao aplicativo. Quando existe mais de uma política, a política mais específica tem prioridade, na seguinte ordem: políticas de nome do host, depois políticas de Worker e, por fim, políticas de conta.
Identidade do usuário no código do aplicativo
O Access também permite saber a identidade do usuário que envia cada solicitação ao aplicativo, incluindo seu e-mail, nome e grupos. Segundo a Cloudflare, esses dados podem ser usados para personalizar o conteúdo, aplicar permissões ou registrar a atividade de cada usuário.
As informações de identidade aparecem no objeto de contexto ctx do Worker, especificamente por meio de ctx.access. O aplicativo pode chamar ctx.access.getIdentity() para obter a identidade do usuário autenticado, sem precisar executar manualmente a verificação de um JSON Web Token, como analisar o token, verificar sua assinatura e extrair suas declarações.
O Access permite conectar o provedor de identidade atual da organização e também restringir o acesso com base em endereços de e-mail específicos, domínios de e-mail ou grupos. Para agentes, o acesso pode ser concedido por meio de tokens de serviço.
Testes locais e plataformas internas
O comportamento da identidade pode ser testado localmente usando wrangler dev, adicionando a configuração do Access ao arquivo wrangler.jsonc para simular um usuário autenticado. Assim, o desenvolvedor pode alterar o e-mail na configuração e verificar a exibição do conteúdo adequado para cada usuário antes da implantação.
A Cloudflare também apresentou um exemplo de código aberto de uma plataforma interna que permite publicar sites estáticos por meio de arrastar e soltar, mantendo cada Worker publicado como privado por padrão. Essa arquitetura aproveita o Workers for Platforms, no qual o tráfego dos aplicativos dentro do espaço de nomes passa por um único Worker distribuído. Ao colocar uma política do Access nesse Worker, os aplicativos publicados por meio dele se tornam privados por padrão.
Disponibilidade e arquitetura técnica
O recurso já está disponível para todos por meio do painel de controle, com a documentação do Cloudflare Access for Workers disponível para começar. A nova capacidade baseia-se no FL2, um proxy modular intermediário desenvolvido em Rust que executa a infraestrutura de borda da Cloudflare.
Para permitir a aplicação do Access no nível do Worker, em vez de no nome do host, a Cloudflare separou o roteamento dos Workers de sua execução e transferiu a lógica de roteamento para uma etapa anterior ao Access. A empresa explica que o sistema FL2, com módulos definidos e etapas ordenadas, ajudou a gerenciar essa mudança, pois cada componente declara suas entradas e saídas de forma estável, permitindo que o compilador detectasse interações inadequadas entre as etapas durante a reestruturação.