Einführung
Nachweise in der Lieferkette sind nur dann nützlich, wenn sie vor der Bereitstellung verifiziert werden. Ein Release-Paket kann ein Kubernetes-Manifest, eine SBOM (Software Bill of Materials), Image-Metadaten und eine Prüfsummendatei enthalten. Die Prüfsumme belegt, dass die aufgeführten Dateien nicht verändert wurden. Die SBOM und die Image-Metadaten helfen Ihnen dabei, zu bestätigen, welche Image- und Paketnachweise das Release laut eigener Aussage enthält.
In diesem Lab validieren Sie ein lokales Release-Paket mit sha256sum und jq, bestätigen, dass die SBOM und die Image-Metadaten die genehmigte Workload beschreiben, zeichnen ein kompaktes JSON-Validierungsergebnis auf und stellen ausschließlich das genehmigte Manifest bereit. Dieses Lab erfordert keine externen Downloads oder Signierungstools. Es konzentriert sich auf die grundlegende CKS-Praxis: Überprüfen Sie die lokalen Nachweise, bevor Sie dem Release-Artefakt vertrauen.
Das Release-Paket untersuchen
In diesem Schritt untersuchen Sie das Release-Paket, bevor Sie Validierungsbefehle ausführen. Dies ist wichtig, da Prüfsummendateien nur die darin aufgeführten Pfade abdecken. Eine Datei kann im Paket vorhanden sein und dennoch außerhalb des genehmigten Release-Sets liegen.
Beginnen Sie im Projektverzeichnis und lesen Sie die Hinweise:
cd /home/labex/project
sed -n '1,180p' RELEASE_VALIDATION_NOTES.md
Listen Sie die Dateien im Paket auf:
find release-bundle -path release-bundle/evidence -prune -o -type f -print | sort | tee release-bundle/evidence/bundle-files.txt
Wechseln Sie in das Paketverzeichnis und untersuchen Sie die Prüfsummendatei:
cd /home/labex/project/release-bundle
cat checksums.sha256 | tee evidence/checksum-file-review.txt
Sie sollten die Prüfsummen für manifests/receipt-ledger-approved.yaml, sbom.json und image-metadata.json sehen. Das nicht aufgeführte Manifest sollte zwar im Paket vorhanden sein, darf jedoch nicht in checksums.sha256 erscheinen.
Prüfsummen verifizieren und den nicht aufgeführten Kandidaten ablehnen
In diesem Schritt verifizieren Sie die aufgeführten Artefakte mit sha256sum -c. Die Option -c liest die erwarteten Hashes aus einer Prüfsummendatei und vergleicht sie mit den aktuellen Dateien. Ein erfolgreiches Ergebnis bedeutet, dass die aufgeführten Dateien weiterhin mit den genehmigten Prüfsummen übereinstimmen.
Führen Sie die Prüfsummenverifizierung aus:
sha256sum -c checksums.sha256 | tee evidence/checksum-verification.txt
Bestätigen Sie, dass das nicht aufgeführte Manifest nicht Teil der genehmigten Prüfsummen-Nachweise ist:
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
Der erste Befehl sollte für die drei aufgeführten Dateien OK ausgeben. Der zweite Befehl sollte bestätigen, dass das nicht aufgeführte Manifest nicht in der Liste der genehmigten Prüfsummen enthalten ist.
SBOM-Metadaten mit Image-Metadaten abgleichen
In diesem Schritt untersuchen Sie die SBOM und die Image-Metadaten. Die Prüfsumme besagt zwar, dass die Dateien nicht verändert wurden, erklärt jedoch nicht, ob die SBOM das Image beschreibt, das Sie bereitstellen möchten. Vergleichen Sie dazu den Imagenamen und den Digest in beiden Dateien.
Extrahieren Sie die Komponenten-Metadaten der SBOM:
jq '.metadata.component' sbom.json | tee evidence/sbom-component.json
Bestätigen Sie, dass die SBOM den erwarteten Paketeintrag enthält:
jq '.components[] | select(.name == "busybox")' sbom.json | tee evidence/sbom-required-package.json
Untersuchen Sie die Image-Metadaten:
jq . image-metadata.json | tee evidence/image-metadata-review.json
Erstellen Sie nun ein kompaktes Validierungs-JSON aus den Nachweisen, die Sie gerade untersucht haben. Die Shell-Variablen lesen die Prüfsumme des genehmigten Manifests und den Image-Digest aus dem Paket, anstatt sie fest zu kodieren.
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
Dieses JSON ist kein ausführlicher Bericht, sondern ein kompakter, maschinenlesbarer Datensatz der Verifizierungsfakten, die Sie vor der Bereitstellung benötigen.
Nur das genehmigte Manifest bereitstellen
In diesem Schritt stellen Sie nur das Manifest bereit, das die Prüfsummenvalidierung bestanden hat. Der nicht aufgeführte Kandidat ist zwar im Paket vorhanden, wurde jedoch nicht in der genehmigten Prüfsummendatei aufgeführt und sollte daher nicht im Cluster landen.
Wenden Sie das genehmigte Manifest an:
kubectl apply -f manifests/receipt-ledger-approved.yaml
Warten Sie auf das Deployment:
kubectl -n cks-prep-sbom rollout status deployment/receipt-ledger --timeout=120s
Bestätigen Sie, dass das nicht aufgeführte Deployment nicht erstellt wurde:
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
Lesen Sie den Laufzeitstatus vom genehmigten Pod:
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
Der Laufzeitstatus sollte wie folgt lauten:
release-status=approved
Zusammenfassung
Sie haben ein lokales Release-Paket untersucht, die genehmigten Prüfsummen verifiziert, bestätigt, dass ein nicht aufgeführter Kandidat außerhalb des genehmigten Release-Sets lag, SBOM-Metadaten mit Image-Metadaten abgeglichen, kompakte JSON-Validierungsnachweise aufgezeichnet und nur das genehmigte Kubernetes-Manifest bereitgestellt. Dies ist der grundlegende Workflow für Nachweise in der Lieferkette: Integrität und Identität vor der Bereitstellung verifizieren.
