Primeiros passos com o Software Delivery Shield

Este documento descreve como ativar as APIs do Software Delivery Shield e as permissões necessárias para visualizar os insights de segurança. O Software Delivery Shield é uma solução de segurança da cadeia de suprimentos de software totalmente gerenciada no Google Cloud.

Ativar as APIs necessárias para insights

Para coletar e visualizar insights da cadeia de suprimentos de software, as seguintes APIs são necessárias:

API Container Analysis para armazenar metadados que outros serviços do Google Cloud geram e usam.
API Container Scanning para verificar vulnerabilidades e outros metadados nas imagens de contêiner armazenadas no Artifact Registry. Ao ativar essa API, a API Container Analysis é ativada automaticamente.
Artifact Registry para armazenar artefatos de build. ¹
O Cloud Build para gerar metadados de procedência do build.
(Somente no GKE) API Container Security para verificar vulnerabilidades de carga de trabalho em execução.

Execute a API Container Scanning no mesmo projeto do Google Cloud que o Artifact Registry. Você pode executar outros serviços do Google Cloud que usam o registro em projetos separados.

¹ O Container Registry é ativado automaticamente pela API Container Scanning. O Software Delivery Shield fornece dados limitados para recursos existentes e não é compatível com alguns recursos na visualização particular. Se você estiver usando o Container Registry, considere fazer a transição para o Artifact Registry.

Para ativar as APIs necessárias para gerar e ver insights:

Console

Usar todos os serviços no mesmo projeto

Ative as APIs necessárias juntas.

Ative as APIs

Usar projetos separados

Ativar o Container Scan e o Artifact Registry no projeto em que você quer executar o Artifact Registry.

Ative as APIs
Ativar a API Cloud Build em projetos em que você está executando o Cloud Build.

Ativar o Cloud Build
Ativar a API Container Security em projetos em que você está executando o GKE.

Ativar a segurança do contêiner

Google Cloud CLI

Usar todos os serviços no mesmo projeto

Ative as APIs necessárias juntas.

gcloud services enable containerscanning.googleapis.com \
    cloudbuild.googleapis.com \
    artifactregistry.googleapis.com \
    containersecurity.googleapis.com

Usar projetos separados

Ativar o Container Scan e o Artifact Registry no projeto em que você quer executar o Artifact Registry. Substitua AR_PROJECT pelo ID do projeto do Google Cloud apropriado.
```
gcloud services enable containerscanning.googleapis.com \
    artifactregistry.googleapis.com \
    --project=AR_PROJECT
```
Ativar a API Cloud Build em projetos em que você está executando o Cloud Build. Substitua BUILD_PROJECT pelo ID do projeto do Google Cloud apropriado.
```
gcloud services enable cloudbuild.googleapis.com \
    --project=BUILD_PROJECT
```
Ativar a API Container Security em projetos em que você está executando o GKE. Substitua GKE_PROJECT pelo ID do projeto do Google Cloud apropriado.
```
gcloud services enable containersecurity.googleapis.com \
     --project=BUILD_PROJECT
```

Você ativou as APIs mínimas necessárias para gerar e visualizar insights nos painels do Shield para entrega de software e no painel de postura de segurança do GKE no Console do Google Cloud.

É possível ativar APIs para outros serviços na biblioteca de APIs ou no comando gcloud services enable.

Concessão de permissões para visualizar insights

Para visualizar insights do Software Delivery Shield no Console do Google Cloud, é necessário ter os seguintes papéis ou um com permissões equivalentes:

Leitor do Cloud Build (roles/cloudbuild.builds.viewer): visualizar insights de um build.
Leitor de ocorrências do Container Analysis (roles/containeranalysis.occurrences.viewer): visualizar vulnerabilidades, versão de compilação e outras informações de dependência.
Leitor do Cloud Run (roles/run.viewer): veja insights de uma revisão do Cloud Run.
Leitor de cluster do Kubernetes Engine (roles/container.clusterViewer): visualizar insights de um cluster do GKE.

Essas permissões fornecem acesso a insights, mas não para executar outras ações, como a execução de versões no Cloud Build.

Veja mais detalhes sobre as permissões necessárias para um serviço específico na documentação desse serviço.
Para saber mais sobre como conceder permissões, consulte a documentação do Identity and Access Management sobre como conceder permissões a projetos.

Por padrão, muitos serviços têm permissões padrão para outros serviços no mesmo projeto, mas não podem acessar recursos em outro projeto. Se você estiver executando serviços em diferentes projetos do Google Cloud ou usando papéis personalizados do IAM ou contas de serviço personalizadas, precisará conceder as permissões apropriadas por conta própria.

Exemplo 1

Cloud Build, Artifact Registry, Container Analysis e Cloud Run estão em execução no mesmo projeto. Cada serviço usa a conta de serviço padrão para agir em nome do serviço, e as permissões padrão não são alteradas. Os serviços podem funcionar juntos sem alterar as permissões, mas você precisa conceder permissões aos usuários que precisam ver insights no projeto.

Permissões entre serviços

Nenhuma alteração é necessária:

A conta de serviço padrão do Cloud Build tem permissões para fazer upload e download com o Artifact Registry e ler dados de insights do Container Analysis. Dessa forma, o serviço pode assinar imagens de contêiner com procedência de build e enviá-las para o Artifact Registry.
As revisões do Cloud Run usam a conta de serviço padrão do Compute Engine para implantações, que tem permissões para fazer o download de imagens do Artifact Registry e ler dados de insights do Container Analysis.

Permissões do usuário para visualizar insights

É preciso conceder aos usuários do Cloud Build e do Cloud Run os papéis necessários para ver insights.

Exemplo 2

Quando o Artifact Registry e o Container Analysis estão em execução em projeto separado de outros serviços do Google Cloud, é necessário conceder explicitamente permissões para todas as atividades do projeto. Considere a seguinte configuração do projeto:

O Cloud Build é executado no projeto A
O Artifact Registry e o Container Analysis são executados no projeto B
O Cloud Run é executado no projeto C

Permissões entre serviços

O Cloud Build e o Cloud Run não podem acessar recursos em outros projetos sem conceder explicitamente acesso às contas de serviço que atuam em nome desses serviços. É necessário conceder as permissões adequadas do Artifact Registry e do Container Analysis no projeto B em que os artefatos e os metadados de artefatos são armazenados.

Para o Cloud Build, é necessário conceder os papéis no projeto B:

O Gravador do Artifact Registry (roles/artifactregistry.writer) concede permissões para fazer upload e download.
O visualizador de ocorrências do Container Analysis (roles/containeranalysis.occurrences.viewer) concede permissões para exibir insights.

Para o Cloud Run, é necessário conceder estes papéis no projeto B:

O Artifact Registry (roles/artifactregistry.reader) concede permissões de download para implantações.
O visualizador de ocorrências do Container Analysis (roles/containeranalysis.occurrences.viewer) concede permissões para exibir insights.

Permissões do usuário para visualizar insights

No projeto B, é necessário conceder aos usuários do Cloud Build e do Cloud Run os insights de visualização dos papéis necessários.

A seguir

Saiba mais sobre os serviços do Software Delivery Shield na visão geral
Saiba mais sobre as práticas de segurança da cadeia de suprimentos de software e como o Software Delivery Shield pode ajudar você a implementá-lo.