Introdução
As evidências da cadeia de suprimentos só são úteis quando você as verifica antes da implantação. Um pacote de lançamento pode conter um manifesto do Kubernetes, um SBOM, metadados de imagem e um arquivo de checksum. O checksum prova que os arquivos listados não foram alterados. O SBOM e os metadados da imagem ajudam a confirmar quais evidências de imagem e pacote o lançamento afirma conter.
Neste laboratório, você validará um pacote de lançamento local com sha256sum e jq, confirmará que o SBOM e os metadados da imagem descrevem a carga de trabalho aprovada, registrará um resultado de validação em JSON compacto e implantará apenas o manifesto aprovado. Este laboratório não requer downloads externos ou ferramentas de assinatura. Ele foca no hábito central do CKS: verificar as evidências locais antes de confiar no artefato de lançamento.
Inspecionar o Pacote de Lançamento
Nesta etapa, você inspecionará o pacote de lançamento antes de executar qualquer comando de validação. Isso é importante porque os arquivos de checksum cobrem apenas os caminhos listados dentro deles. Um arquivo pode existir no pacote e ainda estar fora do conjunto de lançamento aprovado.
Comece no diretório do projeto e leia as notas:
cd /home/labex/project
sed -n '1,180p' RELEASE_VALIDATION_NOTES.md
Liste os arquivos do pacote:
find release-bundle -path release-bundle/evidence -prune -o -type f -print | sort | tee release-bundle/evidence/bundle-files.txt
Entre no pacote e inspecione o arquivo de checksum:
cd /home/labex/project/release-bundle
cat checksums.sha256 | tee evidence/checksum-file-review.txt
Você deve ver os checksums para manifests/receipt-ledger-approved.yaml, sbom.json e image-metadata.json. O manifesto não listado deve existir no pacote, mas não deve aparecer em checksums.sha256.
Verificar Checksums e Rejeitar o Candidato Não Listado
Nesta etapa, você verificará os artefatos listados com sha256sum -c. A opção -c lê os hashes esperados de um arquivo de checksum e os compara com os arquivos atuais. Um resultado bem-sucedido significa que os arquivos listados ainda correspondem aos checksums aprovados.
Execute a verificação de checksum:
sha256sum -c checksums.sha256 | tee evidence/checksum-verification.txt
Confirme que o manifesto não listado não faz parte da evidência de checksum aprovada:
if grep -q 'receipt-ledger-unlisted.yaml' checksums.sha256; then
echo "unlisted manifest is unexpectedly approved" | tee evidence/unlisted-check.txt
else
echo "unlisted manifest is not in the approved checksum list" | tee evidence/unlisted-check.txt
fi
O primeiro comando deve imprimir OK para os três arquivos listados. O segundo comando deve indicar que o manifesto não listado não está na lista de checksums aprovados.
Corresponder Metadados de SBOM aos Metadados de Imagem
Nesta etapa, você inspecionará o SBOM e os metadados da imagem. O checksum informa que os arquivos não foram alterados, mas não explica se o SBOM descreve a imagem que você planeja implantar. Para isso, compare o nome da imagem e o digest em ambos os arquivos.
Extraia os metadados do componente SBOM:
jq '.metadata.component' sbom.json | tee evidence/sbom-component.json
Confirme que o SBOM contém a entrada de pacote esperada:
jq '.components[] | select(.name == "busybox")' sbom.json | tee evidence/sbom-required-package.json
Inspecione os metadados da imagem:
jq . image-metadata.json | tee evidence/image-metadata-review.json
Agora, crie um JSON de validação compacto a partir das evidências que você acabou de inspecionar. As variáveis de shell leem o checksum do manifesto aprovado e o digest da imagem do pacote, em vez de codificá-los manualmente.
approved_sha="$(awk '$2=="manifests/receipt-ledger-approved.yaml" {print $1}' checksums.sha256)"
image_digest="$(jq -r '.digest' image-metadata.json)"
cat > evidence/validation.json <<EOF
{
"checksum_status": "verified",
"approved_manifest": "manifests/receipt-ledger-approved.yaml",
"approved_manifest_sha256": "${approved_sha}",
"sbom_name": "receipt-ledger",
"sbom_version": "1.8.4",
"sbom_image": "busybox:1.36",
"sbom_package": "busybox",
"image_digest": "${image_digest}",
"rejected_manifest": "manifests/receipt-ledger-unlisted.yaml",
"rejection_reason": "not-listed-in-checksums"
}
EOF
jq -M . evidence/validation.json
Este JSON não é um relatório em prosa. É um pequeno registro legível por máquina dos fatos de verificação que você desejaria ter antes da implantação.
Implantar Apenas o Manifesto Aprovado
Nesta etapa, você implantará apenas o manifesto que passou na validação de checksum. O candidato não listado está presente no pacote, mas não foi listado no arquivo de checksum aprovado, portanto, deve permanecer fora do cluster.
Aplique o manifesto aprovado:
kubectl apply -f manifests/receipt-ledger-approved.yaml
Aguarde a implantação (Deployment):
kubectl -n cks-prep-sbom rollout status deployment/receipt-ledger --timeout=120s
Confirme que a implantação não listada não foi criada:
if kubectl -n cks-prep-sbom get deployment receipt-ledger-unlisted >/dev/null 2>&1; then
echo "unlisted deployment exists" | tee evidence/unlisted-deployment-check.txt
else
echo "unlisted deployment is absent" | tee evidence/unlisted-deployment-check.txt
fi
Leia o status de tempo de execução do Pod aprovado:
pod="$(kubectl -n cks-prep-sbom get pod -l app=receipt-ledger --field-selector=status.phase=Running -o jsonpath='{.items[0].metadata.name}')"
kubectl -n cks-prep-sbom exec "$pod" -- cat /release/status.txt | tee evidence/runtime-status.txt
O status de tempo de execução deve ser:
release-status=approved
Resumo
Você inspecionou um pacote de lançamento local, verificou os checksums aprovados, confirmou que um candidato não listado estava fora do conjunto de lançamento aprovado, correspondeu os metadados do SBOM aos metadados da imagem, registrou evidências de validação em JSON compacto e implantou apenas o manifesto do Kubernetes aprovado. Este é o fluxo de trabalho central de evidências da cadeia de suprimentos: verificar a integridade e a identidade antes da implantação.
