O Cloud Build é um serviço que executa seus builds no Google Cloud.
O Cloud Build pode importar o código-fonte de vários repositórios ou do Cloud Storage, executar um build de acordo com suas especificações e produzir artefatos, como contêineres do Docker ou arquivos Java. Também é possível usar o Cloud Build para ajudar a proteger sua cadeia de suprimentos de software. Os recursos do Cloud Build atendem aos requisitos do nível 3 dos Níveis da cadeia de suprimentos para artefatos de software (SLSA, na sigla em inglês). Para orientações sobre como proteger seus processos de build, consulte Proteger builds.Configuração do build e etapas de compilação
Você pode gravar uma configuração da versão para fornecer instruções ao Cloud Build sobre quais tarefas executar. Você pode configurar versões para buscar dependências, executar testes de unidade, análises estáticas e testes de integração e criar artefatos com ferramentas de versão, como docker, gradle, maven, bazel e gulp.
O Cloud Build executa sua versão como uma série de etapas de versão, em que cada uma delas é executada em um contêiner do Docker. Executar etapas de versão é análogo à execução de comandos em um script.
É possível usar as etapas de versão fornecidas pelo Cloud Build e pela comunidade dele ou gravar suas próprias etapas de versão personalizadas:
- Etapas de versão fornecidas pelo Cloud Build: o Cloud Build publicou um conjunto de etapas de versão de código aberto compatíveis com linguagens e tarefas comuns.
- Etapas de versão com contribuições da comunidade: a comunidade de usuários do Cloud Build elaborou etapas de versão de código aberto build steps.
- Etapas de versão personalizadas: é possível criar suas próprias etapas de versão para uso nas suas versões.
Cada etapa de versão é executada com o respectivo contêiner anexado a uma rede local do Docker chamada cloudbuild. Isso permite que as etapas de versão se comuniquem entre si e compartilhem dados. Para mais informações sobre a rede cloudbuild, consulte
Rede do Cloud Build.
É possível usar imagens Docker Hub padrão no Cloud Build, como Ubuntu e Gradle.
Como iniciar versões
É possível iniciar versões manualmente no Cloud Build usando a Google Cloud CLI ou a API Cloud Build, ou usar os acionadores de versão do Cloud Build para criar um fluxo de trabalho automatizado de integração/entrega contínua (CI/CD, na sigla em inglês) que inicia novas versões em resposta a alterações de código. É possível integrar acionadores de versão com muitos repositórios de código, incluindo Cloud Source Repositories, GitHub e Bitbucket.Como ver os resultados do build
Veja os resultados do build usando a CLI gcloud, a API Cloud Build ou a página Histórico do build na seção "Cloud Build" do Google Cloud console, que mostra detalhes e registros de cada build que o Cloud Build executa. Para instruções, consulte Como ver os resultados da criação.
Como funciona a versão
Nas etapas a seguir, descrevemos, de modo geral, o ciclo de vida de uma versão do Cloud Build:
- Prepare o código do seu aplicativo e os recursos necessários.
- Crie um arquivo de solicitação de versão, no formato YAML ou JSON, que contenha instruções para o Cloud Build.
- Envie a versão para o Cloud Build.
- O Cloud Build executa sua versão com base na solicitação de versão que você forneceu.
- Se aplicável, todos os artefatos criados são enviados para o Artifact Registry.
Docker
O Cloud Build usa o Docker
para executar builds. Para cada etapa da criação, o Cloud Build executa um contêiner de Docker como uma instância de docker run. Atualmente, o Cloud Build está executando o Docker Engine versão 20.10.24.
Interfaces do Cloud Build
Use o Cloud Build com o Google Cloud console, gcloud
ferramenta de linha de comando ou a API REST do Cloud Build.
Use a CLI gcloud para criar e gerenciar builds. Também é possível executar comandos para realizar tarefas como enviar uma versão, listar versões, e cancelar uma versão.
Você pode solicitar versões usando a API REST Cloud Build.
Igual a outras APIs do Cloud Platform, você precisa autorizar o acesso usando OAuth2. Depois de autorizar o acesso, você pode usar a API para iniciar novas versões, ver o status e os detalhes da versão, listar versões por projeto e cancelar versões em execução.
Para saber mais informações, consulte a documentação da API.
Pools padrão e particulares
Por padrão, quando você executa uma versão no Cloud Build, ela é executada em um ambiente hospedado e seguro com acesso à Internet pública. Cada versão é executada no próprio worker e está isolada de outras cargas de trabalho. É possível personalizar seu build de várias maneiras, incluindo aumentando o tamanho do tipo de máquina ou alocando mais espaço em disco. O pool padrão tem limites de personalização do ambiente, especialmente em torno do acesso à rede privada.
Pools particulares são pools particulares e dedicados de workers que oferecem maior personalização no ambiente de build, incluindo a capacidade de acessar recursos em uma rede particular. Os pools particulares, semelhantes aos pools padrão, são hospedados e totalmente gerenciados pelo Cloud Build e escalonar verticalmente e para baixo até zero, sem infraestrutura para configurar, fazer upgrade ou escalonar. Como os pools particulares são recursos específicos do cliente, é possível configurá-los de outras maneiras.Para saber mais sobre os pools particulares e a diferença de recursos entre o pool padrão e o pool particular, consulte Visão geral do pool particular.
Segurança do build
O Cloud Build oferece vários recursos para proteger seus builds, incluindo:
-
Builds automatizados
Um build automatizado ou com script define todas as etapas do build no script ou na configuração do build, incluindo as etapas para recuperar o código-fonte e as etapas para criar o código. O único comando manual, se houver, é o comando para executar o build. O Cloud Build usa um arquivo de configuração do build para fornecer etapas de build ao Cloud Build.
Os builds automatizados oferecem consistência nas etapas do build. No entanto, também é importante executar builds em um ambiente consistente e confiável.
Embora os builds locais possam ser úteis para fins de depuração, a liberação software de builds locais pode introduzir muitas preocupações de segurança, inconsistências e ineficiências no processo de build.
- Permitir builds locais oferece uma maneira para um invasor com intenção maliciosa modificar o processo de build.
- As inconsistências nos ambientes locais e nas práticas dos desenvolvedores dificultam a reprodução de builds e o diagnóstico de problemas de build.
Nos requisitos da estrutura SLSA, os builds automatizados são um requisito para o nível 1 do SLSA, e o uso de um serviço de build em vez de ambientes de desenvolvedor para builds é um requisito para o nível 2 do SLSA.
-
Procedência do build
A procedência do build é uma coleção de dados verificáveis sobre um build.
Os metadados de procedência incluem detalhes como os resumos das imagens criadas , os locais da origem de entrada, a cadeia de ferramentas e a duração do build.
Gerar a procedência do build ajuda você a:
- Verificar se um artefato criado foi gerado por um local de origem confiável e por um sistema de build confiável.
- Identificar o código injetado de um local de origem ou sistema de build não confiável.
É possível usar mecanismos de alerta e política para usar proativamente os dados de procedência do build Por exemplo, é possível criar políticas que permitam apenas implantações de código criado a partir de fontes verificadas.
O Cloud Build pode gerar a procedência do build para imagens de contêiner que fornecem garantia de nível 3 do SLSA. Para mais informações, consulte Como ver a procedência do build.
-
Ambiente de build temporário
Os ambientes temporários são ambientes temporários destinados a durar uma única invocação de build. Após o build, o ambiente é limpo ou excluído. Os builds temporários garantem que o serviço de build e as etapas de build sejam executados em um ambiente temporário, como um contêiner ou uma máquina virtual (VM). Em vez de reutilizar um ambiente de build atual, o serviço de build provisiona um novo ambiente para cada build e o destrói após a conclusão do processo de build.
Os ambientes temporários garantem builds limpos, já que não há arquivos residuais ou configurações de ambiente de builds anteriores que possam interferir no processo de build Um ambiente não temporário oferece uma oportunidade para invasores injetarem arquivos e conteúdo maliciosos. Um ambiente temporário também reduz sobrecarga de manutenção e reduz inconsistências no ambiente de build environment.
O Cloud Build configura um novo ambiente de VM para cada build e o destrói após o build.
-
Políticas de implantação
É possível integrar o Cloud Build à autorização binária para verificar os atestados de build e bloquear implantações de imagens que não são geradas pelo Cloud Build. Esse processo pode reduzir o risco de implantação de software não autorizado.
-
Chaves de criptografia gerenciadas pelo cliente
O Cloud Build oferece conformidade com chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês) por padrão. Os usuários não precisam configurar nada especificamente. O Cloud Build oferece conformidade com CMEK criptografando o disco permanente (DP) com tempo de build com uma chave temporária gerada para cada build. A chave é gerada exclusivamente para cada build.
Assim que o build é concluído, a chave é apagada da memória e destruída. Ela não é armazenada em lugar algum, não pode ser acessada por engenheiros do Google nem pela equipe de suporte e não pode ser restaurada. Os dados que foram protegidos usando essa chave estão permanentemente inacessíveis. Para mais informações, consulte Conformidade com CMEK no Cloud Build.
-
Painel de insights de segurança
O Cloud Build inclui um painel Insights de segurança no console que mostra uma visão geral de alto nível de várias métricas de segurança. Google Cloud É possível usar esse painel para identificar e mitigar riscos no processo de build.
Esse painel mostra as seguintes informações:
- Nível dos Níveis da cadeia de suprimentos para artefatos de software (SLSA, na sigla em inglês): identifica o nível de maturidade do processo de build do software de acordo com a especificação do SLSA.
- Vulnerabilidades: uma visão geral de todas as vulnerabilidades encontradas nos seus artefatos e do nome da imagem verificada pelo Artifact Analysis. Clique no nome da imagem para visualizar os detalhes da vulnerabilidade detalhes.
- Detalhes do build: detalhes do build, como o builder e o link para visualizar registros.
- Procedência do build: procedência do build.
Para saber como usar o Cloud Build com outros Google Cloud produtos e recursos para proteger sua cadeia de suprimentos de software, consulte Segurança da cadeia de suprimentos de software.