Verificação de vulnerabilidades baseada na lista de permissões com o Container Analysis

Neste tutorial, descrevemos como criar e usar o Kritis Signer com o Container Analysis para verificar vulnerabilidades em imagens de contêiner criadas com o Cloud Build. O Kritis Signer verifica as vulnerabilidades identificadas em relação a uma política de vulnerabilidade. A etapa de criação do Cloud Build falhará se uma vulnerabilidade identificada violar a política de vulnerabilidade.

Visão geral

Ao proteger sua cadeia de suprimentos de software baseada em contêiner, pode ser extremamente importante evitar que uma imagem de contêiner vulnerável seja implantada. O Container Analysis oferece serviços de verificação de vulnerabilidades para imagens de contêiner. Kritis Signer é um builder personalizado de código aberto para o Cloud Build que é executado como uma etapa da criação e usa o Container Analysis para identificar vulnerabilidades em uma imagem de contêiner. Em seguida, ele verifica essas vulnerabilidades em relação a uma política de vulnerabilidades. Se alguma vulnerabilidade identificada violar a política de vulnerabilidade de Kritis Signer, a versão falhará. No contexto da autorização binária, você pode adicionar uma etapa de versão do Kritis Signer a um pipeline de criação de imagem de contêiner para que uma violação de política falhe na criação antes de um atestado ser criado.

Neste tutorial, você aprenderá como:

  1. Clonar o repositório Kritis.
  2. Criar o builder personalizado do Kritis Signer que verifica se há vulnerabilidades com o Container Analysis.
  3. Ver uma política de vulnerabilidade.
  4. Enviar versões de amostra para o Cloud Build que criam uma imagem de contêiner e verificam se há vulnerabilidades.

    • A primeira criação da imagem de contêiner de amostra, cloudbuild-bad.yaml, é um caso de falha. Nesse caso, o Kritis Signer encontra vulnerabilidades na imagem do contêiner que viola a política de vulnerabilidade. A etapa de criação falha, encerrando o pipeline de criação.

    • A segunda criação de imagem de contêiner de amostra, cloudbuild-good.yaml, é um caso de sucesso. Nesse caso, o Kritis Signer não pode encontrar uma vulnerabilidade na imagem do contêiner que viole sua política de vulnerabilidade. A etapa de versão precisa ser bem-sucedida.

Produtos usados neste tutorial

Neste tutorial, usamos o Google Cloud e os produtos de código aberto a seguir:

  • O Cloud Build é um produto que executa suas versões na infraestrutura do Google Cloud. O Cloud Build executa a compilação como uma série de etapas de compilação, em que cada uma delas é executada em um contêiner do Docker. Neste tutorial, o Kritis Signer é integrado a um builder personalizado do Cloud Build que pode ser usado posteriormente nos pipelines de compilação. O Cloud Build também é usado para criar os exemplos de casos de sucesso e falha, demonstrando como incluir verificação de vulnerabilidades nos pipelines de criação.

  • O Kritis é uma solução de código aberto para proteger sua cadeia de suprimentos de software para aplicativos do Kubernetes. O Kritis Signer é um builder personalizado do Cloud Build que verifica as vulnerabilidades identificadas pelo Container Analysis em relação a uma política de vulnerabilidade.

  • O Container Registry é um registro de imagens de contêiner particular executado no Google Cloud. Neste tutorial, o builder personalizado do Kritis Signer e as imagens de contêiner de amostra são armazenados no Container Registry.

  • O Container Analysis é um produto do Google Cloud que fornece verificação de vulnerabilidades e armazenamento de metadados para artefatos de software. O serviço realiza verificações de vulnerabilidade em artefatos de software criados, como as imagens no Container Registry. Em seguida, armazena os metadados resultantes e os disponibiliza para consumo por meio de uma API. Neste tutorial, o Kritis Signer chama o Container Analysis para identificar vulnerabilidades em imagens de contêiner.

Configurar

Nesta seção, você fará uma configuração única do sistema. Isso inclui as seguintes etapas:

  1. Configurar o ambiente.
  2. Ativar APIs.
  3. Definir permissões na conta de serviço que o Cloud Build usa para ler o Container Analysis.
  4. Clonar o repositório do Kritis.
  5. Criar o builder personalizado do Cloud Build do Kritis Signer.
  6. Editar uma política de vulnerabilidade.

Na próxima seção, você executará pipelines de compilação de amostra com o Cloud Build.

Configurar o ambiente

Primeiro, defina PROJECT_ID como seu projeto do Google Cloud. Esse projeto é usado em todo o tutorial.

export PROJECT_ID=PROJECT-ID

em que PROJECT-ID é o ID do projeto do Google Cloud.

export PROJECT_NUMBER=$(gcloud projects list --filter="${PROJECT_ID}" --format="value(PROJECT_NUMBER)")

Ativar APIs

gcloud --project=$PROJECT_ID services enable cloudbuild.googleapis.com
gcloud --project=$PROJECT_ID services enable containerregistry.googleapis.com
gcloud --project=$PROJECT_ID services enable containeranalysis.googleapis.com
gcloud --project=$PROJECT_ID services enable containerscanning.googleapis.com

Configurar permissões

Execute o comando a seguir para conceder à conta de serviço do Cloud Build acesso de leitura às informações de vulnerabilidade do Container Analysis.

gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/containeranalysis.notes.occurrences.viewer

Crie o builder personalizado do Kritis Signer

Execute os comandos a seguir para conseguir os arquivos de código e configuração usados neste tutorial.

  1. Clone o repositório Kritis

    git clone --branch policy-check-v1.0.0 https://github.com/grafeas/kritis.git
    

    Esse repositório contém o seguinte:

    • Código aberto para Kritis.
    • Arquivos de configuração da compilação usados pelo Cloud Build para criar o builder personalizado do Kritis Signer.
    • Um exemplo de política de vulnerabilidade.
    • Exemplos de arquivos de configuração da compilação do Cloud Build que demonstram a verificação de vulnerabilidades do Kritis Signer em um pipeline de versão.
  2. Navegar até o diretório /kritis:

    cd kritis
    
  3. Enviar o builder personalizado do Kritis Signer para o projeto

    Esta etapa única cria um builder personalizado que é usado nos pipelines de vulnerabilidade.

    gcloud --project=$PROJECT_ID builds submit . --config deploy/kritis-signer/cloudbuild.yaml
    

Editar a política de assinatura de vulnerabilidades

Nesta seção, descrevemos a política de vulnerabilidade aplicada pelo Kritis Signer. Editar esta política para determinar os níveis de gravidade permitidos e listar vulnerabilidades específicas permitidas.

Para ver a política de vulnerabilidade:

cat samples/policy-check/policy.yaml

A aparência será semelhante a esta:

apiVersion: kritis.grafeas.io/v1beta1
kind: VulnzSigningPolicy
metadata:
  name: my-vsp
spec:
  imageVulnerabilityRequirements:
    maximumFixableSeverity: MEDIUM
    maximumUnfixableSeverity: MEDIUM
    allowlistCVEs:
    - projects/goog-vulnz/notes/CVE-2020-10543
    - projects/goog-vulnz/notes/CVE-2020-10878
    - projects/goog-vulnz/notes/CVE-2020-14155

Em que:

  • allowlistCVEs é uma lista de vulnerabilidades. Cada entrada precisa ser uma correspondência exata do nome da nota.
  • maximumUnfixableSeverity e maximumFixableSeverity podem ser um destes:

    • CRITICAL
    • HIGH
    • MEDIUM
    • LOW
    • BLOCK_ALL - Falha se alguma vulnerabilidade for identificada
    • ALLOW_ALL - É sempre bem-sucedido

Testar o builder personalizado do Kritis Signer

Nesta seção, você enviará exemplos de versões para o Cloud Build.

Nas etapas a seguir, duas versões de imagem de contêiner são enviadas para o Cloud Build:

  • Caso de falha: a primeira compilação cria uma imagem de contêiner que contém uma vulnerabilidade que aciona uma violação da política de vulnerabilidade. Essa versão vai falhar.
  • Caso de sucesso: a segunda versão cria uma imagem de contêiner que contém vulnerabilidades que precisam ser permitidas pela política de vulnerabilidade. Esta versão precisa ser bem-sucedida.

Os dois exemplos de arquivos de configuração da compilação contêm as seguintes etapas:

  1. A etapa build cria uma imagem de contêiner do Docker.
  2. A etapa push envia a imagem de contêiner recém-criada ao Container Registry.
  3. A etapa vulnsign analisa a imagem do contêiner:
    1. Como aguardar o Container Analysis retornar resultados de vulnerabilidade na imagem de contêiner recém-criada.
    2. Como verificar as descobertas em relação à política de vulnerabilidade.
    3. Sucesso ou falha com base na conformidade com a política.

Enviar a amostra da compilação do caso de falha

Este exemplo cria uma imagem de contêiner com base no Debian 9. No momento, o contêiner tem uma vulnerabilidade que não é permitida pela política de vulnerabilidade descrita acima. O builder personalizado do Kritis Signer falhará na etapa de criação de vulnsign.

Para ver o conteúdo do arquivo de compilação, digite o seguinte comando:

cat samples/policy-check/cloudbuild-bad.yaml

Execute o pipeline de criação

gcloud  --project=$PROJECT_ID builds submit --config=samples/policy-check/cloudbuild-bad.yaml samples/policy-check

Você verá um resultado parecido com o seguinte:

ERROR: (gcloud.builds.submit) build [BUILD-ID] completed with status "FAILURE"

Observe o valor [BUILD-ID] e defina a variável de ambiente $BUILD_ID para a próxima etapa.

export BUILD_ID=BUILD-ID

Como alternativa, você pode encontrar o ID da versão mais recente executando o seguinte comando:

gcloud builds list --limit 1

O ID da versão é o primeiro campo retornado. Altere o valor --limit para ver mais versões ou remova completamente a sinalização para ver todas as versões.

Verifique o resultado

gsutil cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "does not pass VulnzSigningPolicy"

Envie a amostra da compilação do caso de sucesso

Para enviar a amostra da compilação do caso de sucesso para o Cloud Build, faça o seguinte:

gcloud --project=$PROJECT_ID builds submit --config=samples/policy-check/cloudbuild-good.yaml samples/policy-check

Novamente, anote o ID da versão e armazene-o na variável de ambiente $BUILD_ID:

export BUILD_ID=BUILD-ID

Por fim, para verificar o resultado, digite o seguinte comando:

gcloud --project=$PROJECT_ID builds describe $BUILD_ID | grep status

A seguir