Criar atestados com o Kritis Signer

Neste tutorial, explicamos como criar o Kritis Signer e usá-lo para verificar vulnerabilidades em imagens de contêiner antes de criar atestados de autorização binária.

Visão geral

O Kritis Signer é uma ferramenta de linha de comando de código aberto que pode criar atestados de autorização binária com base em uma política configurada por você. Também é possível usar o Kritis Signer para criar atestados após verificar as vulnerabilidades de uma imagem identificadas pelo Artifact Analysis.

Além disso, o Cloud Build pode executar o Kritis Signer como um builder personalizado em um pipeline de criação.

Neste tutorial, você executa uma criação única do builder personalizado do Kritis Signer e, em seguida, executa os pipelines de criação de amostra. Cada pipeline de amostra contém as seguintes etapas de criação:

  1. Criação de uma imagem de contêiner de amostra.
  2. Envie a imagem para o Container Registry
  3. Verificação e assinatura da imagem: use o Kritis Signer para criar um atestado com base na política.

Na etapa de criação de verificação e assinatura de cada pipeline, o Kritis Signer:

  1. Verifica a imagem recém-criada com o Artifact Analysis e recupera uma lista de vulnerabilidades;
  2. verifica a lista de vulnerabilidades em relação às regras de assinatura de vulnerabilidades na política e:
    1. se todas as vulnerabilidades identificadas atenderem às regras de assinatura de vulnerabilidade, o Kritis Signer cria o atestado.
    2. se alguma das vulnerabilidades identificadas violar as regras de assinatura de vulnerabilidades, o Kritis Signer não cria o atestado.

No momento da implantação, o aplicador de autorização binária verifica se há um atestado verificável. Sem um, o aplicador impede a implantação da imagem.

Neste tutorial, também explicamos como executar o Kritis Signer no modo somente verificação em um pipeline do Cloud Build. Nesse modo, o Kritis Signer não cria um atestado, ele só verifica se os resultados de vulnerabilidade atendem às regras de assinatura de vulnerabilidades na política. Em caso afirmativo, a etapa de criação do Kritis Signer será bem-sucedida e o pipeline continuará em execução, caso contrário, a etapa falhará e o pipeline será encerrado.

Objetivos

Neste tutorial, você realizará as seguintes ações:

  1. Configure o Kritis Signer como um criador personalizado do Cloud Build.
  2. Ver uma política que contém regras de assinatura de vulnerabilidade.
  3. Executar o Kritis Signer na criação de atestados com base nos resultados da verificação de vulnerabilidades.
  4. Executar o Kritis Signer no modo somente verificação.

Custos

Neste tutorial, usamos os seguintes produtos do Google Cloud.

  • Container Registry
  • Artifact Analysis
  • Cloud Build
  • Cloud Key Management Service

Use a Calculadora de preços para gerar uma estimativa de custo com base no uso previsto.

Antes de começar

Nesta seção, você fará uma configuração única do sistema.

Configurar o ambiente

  1. Armazene o projeto do Google Cloud em uma variável de ambiente.

    export PROJECT_ID=PROJECT_ID

    Substitua PROJECT_ID pelo ID do projeto do Google Cloud.

  2. Defina o ID do projeto padrão para o projeto do Google Cloud:

    gcloud config set project $PROJECT_ID

  3. Armazene o número do projeto em uma variável de ambiente para etapas futuras:

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

  4. Ative APIs:

    Para garantir que os serviços necessários para este guia estejam ativados, execute o seguinte comando:

    gcloud services enable \
  cloudbuild.googleapis.com \
  containerregistry.googleapis.com \
  containerscanning.googleapis.com \
  cloudkms.googleapis.com

Configurar papéis do IAM

Execute os seguintes comandos para configurar a conta de serviço do Cloud Build com os seguintes papéis:

  • containeranalysis.notes.editor: adiciona o papel de Editor de notas do Artifact Analysis para o gerenciamento do atestador.
  • containeranalysis.notes.occurrences.viewer: adiciona o papel de Ocorrências do Artifact Analysis para notas para o gerenciamento das ocorrências de vulnerabilidade e de atestado.
  • roles/containeranalysis.occurrences.editor: adiciona o papel de Editor de ocorrências do Artifact Analysis para a criação de ocorrências de atestado no Artifact Analysis.

  • cloudkms.signer: adiciona o papel Signatário de CryptoKey do Cloud KMS que permite que a conta de serviço acesse o serviço de assinatura do Cloud KMS.

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

Configurar o criador personalizado do Kritis Signer

Nesta seção, você realiza uma configuração única do criador personalizado do Kritis Signer. Depois de receber, criar e enviar o Kritis Signer, ele pode ser usado em qualquer pipeline do Cloud Build.

Esta seção mostra como:

  • Clonar o repositório Kritis.
  • Criar o builder personalizado do Cloud Build do Kritis Signer.
  • Envie o Kritis Signer para o Container Registry e disponibilize-o para uso como uma etapa de versão do Cloud Build.

Execute os seguintes comandos para conseguir os arquivos de código e configuração usados neste guia:

  1. Clonar o repositório Kritis.

    git clone https://github.com/grafeas/kritis.git

    Esse repositório contém o seguinte:

    • Código-fonte de Kritis, que também inclui o Kritis.
    • Um arquivo de configuração do Cloud Build usado pelo Cloud Build para produzir o criador personalizado do Kritis Signer.
    • Um exemplo de política que contém regras de assinatura de vulnerabilidades.
    • Exemplo de arquivos de configuração do Cloud Build. Cada arquivo de configuração usa o Kritis Signer em um pipeline de verificação de vulnerabilidades.

  2. Navegue até o diretório kritis/:

    cd kritis

  3. Construa e registre o criador personalizado do Kritis Signer.

    Esta etapa única de configuração cria o criador personalizado do Kritis Signer e o registra com o Cloud Build. Depois de registrado, o builder personalizado estará disponível para uso em qualquer pipeline do Cloud Build.

    gcloud builds submit . --config deploy/kritis-signer/cloudbuild.yaml

Ver uma política existente

Nesta seção, mostramos um exemplo de política do Kritis Signer.

Esta política configura o Kritis Signer para solicitar ao Artifact Analysis a verificação de vulnerabilidades da imagem. Após a verificação, o Kritis Signer retornou resultados de vulnerabilidade em relação às regras de assinatura de vulnerabilidade da política.

É possível editar as regras de assinatura de vulnerabilidades nesta política para criar um atestado com base em:

  • níveis de gravidade das vulnerabilidades identificadas;
  • vulnerabilidades específicas.

Também é possível definir a política para criar um atestado incondicionalmente (ALLOW_ALL) ou não (BLOCK_ALL).

Para ver a política do Kritis Signer, execute o seguinte comando:

cat samples/signer/policy-strict.yaml

A política é 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-2021-20305

Em que:

  • maximumUnfixableSeverity e maximumFixableSeverity definem limites de gravidade comuns de vulnerabilidades e exposições (CVE, na sigla em inglês) em que o Kritis Signer cria atestados. maximumUnfixableSeverity define o limite de gravidade em que uma correção não está disponível no momento. maximumFixableSeverity define o limite da gravidade da correção disponível no momento. maximumUnfixableSeverity e maximumFixableSeverity podem ser definidos como um dos seguintes níveis de gravidade:

    • CRITICAL
    • HIGH
    • MEDIUM
    • LOW

    Para saber mais sobre os níveis de gravidade, consulte Níveis de gravidade.

    Como alternativa, defina maximumUnfixableSeverity e maximumFixableSeverity como:

    • BLOCK_ALL: o atestado não será criado se alguma vulnerabilidade for identificada.
    • ALLOW_ALL: o atestado é sempre criado.

  • allowlistCVEs é uma lista de CVEs específicas para colocar na lista de permissões. O Kritis Signer ignora CVEs nesta lista ao avaliar se é necessário criar um atestado. Cada entrada na lista de permissões precisa corresponder exatamente ao nome da nota do Artifact Analysis para a CVE. Saiba mais sobre as origens de vulnerabilidade do Artifact Analysis. Para mais informações sobre observações, consulte Armazenamento de metadados.

Criar uma chave de assinatura do Cloud KMS

As chaves do Cloud Key Management Service são usadas para criar o atestado.

  1. Crie um novo keyring do Cloud KMS com o nome KEY_RING:

    gcloud kms keyrings create KEY_RING \
   --location global

  2. Crie uma nova chave do Cloud KMS chamada KEY_NAME no keyring:

    gcloud kms keys create KEY_NAME \
    --keyring KEY_RING \
    --location global \
    --purpose "asymmetric-signing" \
    --default-algorithm "rsa-sign-pkcs1-2048-sha256"

  3. Armazene o algoritmo de resumo e o Cloud KMS em uma variável de ambiente para etapas futuras:

    export KMS_DIGEST_ALG=SHA256
export KMS_KEY_NAME=projects/$PROJECT_ID/locations/global/keyRings/KEY_RING/cryptoKeys/KEY_NAME/cryptoKeyVersions/1

Definir o nome de uma nota

Todos os atestados indicam uma nota do Artifact Analysis. A Kritis Signer cria automaticamente uma nota para um determinado nome. Também é possível reutilizar os nomes de notas existentes.

export NOTE_ID=my-signer-note
export NOTE_NAME=projects/${PROJECT_ID}/notes/${NOTE_ID}

Criar atestados com Kritis Signer em um pipeline do Cloud Build

Nesta seção, demonstramos como usar o criador de nuvem personalizado do Kritis Signer para criar atestados de autorização binária com base nos resultados da verificação de vulnerabilidades.

Nas etapas a seguir, demonstramos como o Kritis Signer funciona com os arquivos de configuração de criação de exemplo no repositório do Kritis Signer. Cada arquivo de configuração de exemplo contém as seguintes etapas de criação:

  1. Uma etapa docker build que cria uma imagem de contêiner do Docker.
  2. Uma etapa docker push que envia a imagem de contêiner recém-criada ao Container Registry.

  3. Uma etapa vulnsign que verifica e assina a imagem do contêiner:

    1. Ao aguardar o Artifact Analysis retornar descobertas de vulnerabilidade da imagem de contêiner recém-criada;
    2. verificando as descobertas em relação às regras de assinatura de vulnerabilidades na política;
    3. criando o atestado se os resultados satisfizerem as regras de vulnerabilidade.

Você envia cada um dos exemplos de compilação para o Cloud Build. Cada compilação produz um resultado de vulnerabilidade:

  • Caso de falha: o resultado da vulnerabilidade viola as regras de assinatura de vulnerabilidade. Este build falha e nenhum atestado é criado.
  • Caso de sucesso: o resultado da vulnerabilidade atende às regras de assinatura de vulnerabilidade. Esta versão é bem-sucedida e um atestado é criado.

Enviar a amostra de amostra do caso de falha

Nesta seção, você cria uma imagem de contêiner e a verifica em busca de vulnerabilidades. O build falha porque a imagem do contêiner é baseada em um snapshot específico do Debian 10, que contém várias vulnerabilidades com o nível de gravidade HIGH. Essas vulnerabilidades violam a regra de assinatura de vulnerabilidade. Como resultado, o builder não produz um atestado.

  1. (Opcional) Veja o arquivo de política de assinatura de vulnerabilidade para o caso de falha.

    cat samples/signer/policy-strict.yaml

  2. Envie o build:

    gcloud builds submit \
  --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
  --config=samples/signer/cloudbuild-bad.yaml samples/signer

    A saída será exibida assim:

    "ERROR: (gcloud.builds.submit) build BUILD_ID completed with status "FAILURE"

  3. Salve o ID da criação mais recente:

    export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")

  4. Verificar o resultado:

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

Envie a amostra de amostra do caso de sucesso

Nesta seção, você cria uma imagem de contêiner que contém vulnerabilidades que não violam as regras de assinatura de vulnerabilidade. Nesse caso, o builder personalizado do Kritis Signer cria um atestado.

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

  1. (Opcional) Veja o arquivo de política de assinatura de vulnerabilidade do caso de sucesso.

    cat samples/signer/policy-loose.yaml

  2. Envie o build:

    gcloud builds submit \
  --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
  --config=samples/signer/cloudbuild-good.yaml samples/signer

  3. Salve o ID da criação mais recente:

    export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")

  4. Verificar o resultado:

    gcloud builds describe $BUILD_ID | grep status

Usar o Kritis Signer no modo somente verificação

Nesta seção, mostramos como usar o Kritis Signer no modo check-only. Nesse modo, o Kritis Signer não cria um atestado. Ele apenas verifica a imagem em busca de vulnerabilidades antes de sucesso ou falha na etapa de criação, com base nas regras de assinatura de vulnerabilidades.

Enviar a amostra de amostra do caso de falha

  1. (Opcional) Veja o arquivo de política de assinatura de vulnerabilidade para o caso de falha.

    cat samples/policy-check/policy-strict.yaml

    Na etapa de criação do Kritis Signer, observe que a sinalização mode está definida como check-only.

  2. Envie o build:

    gcloud builds submit \
  --config=samples/policy-check/cloudbuild-bad.yaml samples/policy-check

    A criação falha.

  3. Salve o ID da criação mais recente:

    export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")

  4. Verificar o resultado:

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

Envie a amostra de amostra do caso de sucesso

  1. (Opcional) Veja o arquivo de política de assinatura de vulnerabilidade do caso de sucesso.

    cat samples/policy-check/policy-loose.yaml

  2. Envie o build:

    gcloud builds submit \
 --config=samples/policy-check/cloudbuild-good.yaml samples/policy-check

  3. Salve o ID da criação mais recente:

    export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")

  4. Verificar o resultado:

    gcloud builds describe $BUILD_ID | grep status

Crie um atestador

Para criar uma política que exija os atestados criados usando o método descrito neste guia, primeiro você precisa criar um atestador.

Para criar um atestador, faça o seguinte:

  1. Recupere o material de chave pública da chave do Cloud KMS criada anteriormente neste guia:

    gcloud kms keys versions get-public-key 1 \
--key KEY_NAME \
--keyring KEY_RING \
--location global \
--output-file OUTPUT_PATH
    • KEY_NAME: o nome da chave
    • KEY_RING: é o nome do keyring
    • OUTPUT_PATH: um caminho de arquivo, por exemplo, my-key.pem

  2. Crie um atestador usando o material da chave pública no arquivo e a observação que você criou anteriormente neste guia. É possível criar um atestador usando o Console do Google Cloud ou a CLI gcloud.

  3. Crie uma política que exija atestados e forneça o atestador que você criou nesta seção. É possível criar uma política usando o console do Google Cloud ou da CLI gcloud

Criar um atestado

Para criar um atestado usando o atestador, consulte Criar um atestado usando o Cloud KMS.

Limpar

Para limpar os recursos usados neste documento, exclua o projeto:

gcloud projects delete ${PROJECT_ID}

A seguir