Shopify Overexposed varre Ingresses do GKE e serviços do Cloud Run em busca de exposição

O Overexposed, scanner interno da Shopify, procura Ingresses do GKE e serviços do Cloud Run acessíveis pela internet sem autenticação. A primeira versão lia arquivos de configuração do repositório de infraestrutura e falhou de três jeitos: gerou falsos positivos quando times configuravam anotações de autenticação por proxy diretamente, errou quando admission controllers (que reescrevem configurações na admissão, mas não rodam em todos os clusters) anulavam uma config aparentemente correta, e nunca enxergou Ingresses criados por outros repositórios ou ferramentas de plataforma. A lição dos autores: o repositório mostra a intenção, o cluster mostra o que é aplicado.

A versão atual consulta o GCP Cloud Asset Inventory em ciclos agendados, o que traz os Ingresses aceitos pelo GKE após a admissão, além de Cloud Run e load balancers. Uma segunda busca recupera políticas de acesso sem precisar de credenciais do cluster. Cada candidato recebe uma requisição anônima (HEAD, com fallback para GET, até três redirecionamentos, e variações de caminho como /ADMIN). Os resultados caem em seis veredictos: exposed, expected, protected, not found, unreachable e inconclusive. No Cloud Run, um 404 pode vir do front end do Google antes da aplicação, então vira inconclusivo, e um 403 não prova proteção. O serviço só é público se allUsers tiver o papel de invoker ou se a checagem de invoker estiver desativada. Com isso, a Shopify reduziu em cerca de 80% os veredictos inconclusivos para Ingresses em poucas semanas de ajuste. Em uma execução de julho, cerca de três em cada quatro resultados eram inconclusivos.

Para quem opera plataforma em GCP, o recado é tratar o inventário da nuvem como fonte de verdade e a análise de configuração no CI como sinal precoce. Regras que olham só allUsers dizem o que alguém quis fazer, não o que está rodando. E um scanner que faz requisições a hostnames arbitrários vira superfície de ataque: validação de IP, proteção contra DNS rebinding e restrição de egress, inclusive para endpoints de metadados, entram no projeto desde o início.