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:
- Criação de uma imagem de contêiner de amostra.
- Envie a imagem para o Container Registry
- 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:
- Verifica a imagem recém-criada com o Artifact Analysis e recupera uma lista de vulnerabilidades;
- verifica a lista de vulnerabilidades em relação às regras de assinatura de vulnerabilidades na política e:
- se todas as vulnerabilidades identificadas atenderem às regras de assinatura de vulnerabilidade, o Kritis Signer cria o atestado.
- 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:
- Configure o Kritis Signer como um criador personalizado do Cloud Build.
- Ver uma política que contém regras de assinatura de vulnerabilidade.
- Executar o Kritis Signer na criação de atestados com base nos resultados da verificação de vulnerabilidades.
- 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.
Configure o ambiente
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.
Defina o ID do projeto padrão para o projeto do Google Cloud:
gcloud config set project $PROJECT_ID
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)")
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:
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 Signer.
- 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.
Navegue até o diretório
kritis/
:cd kritis
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:
Em que:
maximumUnfixableSeverity
emaximumFixableSeverity
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
emaximumFixableSeverity
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
emaximumFixableSeverity
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.
Crie um novo keyring do Cloud KMS com o nome KEY_RING:
gcloud kms keyrings create KEY_RING \ --location global
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"
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:
- Uma etapa
docker build
que cria uma imagem de contêiner do Docker. - Uma etapa
docker push
que envia a imagem de contêiner recém-criada ao Container Registry. Uma etapa
vulnsign
que verifica e assina a imagem do contêiner:- Ao aguardar o Artifact Analysis retornar descobertas de vulnerabilidade da imagem de contêiner recém-criada;
- verificando as descobertas em relação às regras de assinatura de vulnerabilidades na política;
- 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.
(Opcional) Veja o arquivo de política de assinatura de vulnerabilidade para o caso de falha.
cat samples/signer/policy-strict.yaml
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"
Salve o ID da criação mais recente:
export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
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:
(Opcional) Veja o arquivo de política de assinatura de vulnerabilidade do caso de sucesso.
cat samples/signer/policy-loose.yaml
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
Salve o ID da criação mais recente:
export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
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
(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 comocheck-only
.Envie o build:
gcloud builds submit \ --config=samples/policy-check/cloudbuild-bad.yaml samples/policy-check
A criação falha.
Salve o ID da criação mais recente:
export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
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
(Opcional) Veja o arquivo de política de assinatura de vulnerabilidade do caso de sucesso.
cat samples/policy-check/policy-loose.yaml
Envie o build:
gcloud builds submit \ --config=samples/policy-check/cloudbuild-good.yaml samples/policy-check
Salve o ID da criação mais recente:
export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
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:
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 chaveKEY_RING
: é o nome do keyringOUTPUT_PATH
: um caminho de arquivo, por exemplo,my-key.pem
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.
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
- Documentação do Kritis Signer no GitHub
- Visão geral da autorização binária
- Crie atestadores pelo Console do Google Cloud ou pela ferramenta de linha de comando
- Configure uma política para exigir atestados pelo Console do Google Cloud ou pela command-line-tool
- Criar atestados com o Voucher
- Artifact Analysis e verificação de vulnerabilidades
- Comunidade do Cloud Build e cloud builder personalizados