GCP - Cloud Build Enum
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Google Cloud Build é uma plataforma de CI/CD gerenciada que automatiza o build e os processos de liberação de software, integrando-se com repositórios de código-fonte e suportando uma ampla gama de linguagens de programação. Ela permite que os desenvolvedores construam, testem e implantem código automaticamente enquanto fornece flexibilidade para personalizar etapas de build e fluxos de trabalho.
Cada Trigger do Cloud Build é relacionado a um Repositório Cloud ou conectado diretamente a um repositório externo (Github, Bitbucket e Gitlab).
Não consegui ver nenhuma maneira de roubar o token do Github/Bitbucket daqui ou dos Repositórios Cloud porque, quando o repositório é baixado, ele é acessado via uma URL https://source.cloud.google.com/ e o Github não é acessado pelo cliente.
O Cloud Build pode ser acionado se:
Push para um branch: Especifique o branch
Push de uma nova tag: Especifique a tag
Pull request: Especifique o branch que recebe o PR
Invocação Manual
Mensagem Pub/Sub: Especifique o tópico
Evento Webhook: Exporá uma URL HTTPS e a solicitação deve ser autenticada com um segredo
Existem 3 opções:
Um yaml/json especificando os comandos a serem executados. Normalmente: /cloudbuild.yaml
Apenas um que pode ser especificado “inline” no console da web e na CLI
Opção mais comum
Relevante para acesso não autenticado
Um Dockerfile para construir
Um Buildpack para construir
A Conta de Serviço tem o escopo cloud-platform
, então pode usar todos os privilégios. Se nenhuma SA for especificada (como ao fazer submit), a SA padrão <proj-number>@cloudbuild.gserviceaccount.com
será usada.
Por padrão, nenhuma permissão é dada, mas é bastante fácil conceder algumas:
É possível configurar um Cloud Build para exigir aprovações para execuções de build (desativado por padrão).
Quando o trigger é PR porque qualquer um pode realizar PRs em repositórios públicos, seria muito perigoso apenas permitir a execução do trigger com qualquer PR. Portanto, por padrão, a execução será automática apenas para proprietários e colaboradores, e para executar o trigger com PRs de outros usuários, um proprietário ou colaborador deve comentar /gcbrun
.
Conexões podem ser criadas sobre:
GitHub: Ele mostrará um prompt OAuth pedindo permissões para obter um token do Github que será armazenado dentro do Secret Manager.
GitHub Enterprise: Pedirá para instalar um GithubApp. Um token de autenticação do seu host GitHub Enterprise será criado e armazenado neste projeto como um segredo do Secret Manager.
GitLab / Enterprise: Você precisa fornecer o token de acesso da API e o token de acesso da API de leitura que será armazenado no Secret Manager.
Uma vez que uma conexão é gerada, você pode usá-la para vincular repositórios aos quais a conta do Github tem acesso.
Esta opção está disponível através do botão:
Observe que repositórios conectados com este método estão disponíveis apenas em Triggers usando a 2ª geração.
Isso não é o mesmo que uma connection
. Isso permite diferentes maneiras de obter acesso a um repositório do Github ou Bitbucket, mas não gera um objeto de conexão, mas gera um objeto de repositório (da 1ª geração).
Esta opção está disponível através do botão:
Às vezes, o Cloud Build irá gerar um novo armazenamento para armazenar os arquivos para o trigger. Isso acontece, por exemplo, no exemplo que o GCP oferece com:
Um bucket de armazenamento chamado security-devbox_cloudbuild é criado para armazenar um .tgz
com os arquivos a serem usados.
Instale o gcloud dentro do cloud build:
Você pode encontrar informações sensíveis em configurações de build e logs.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)