Введение
Доказательства безопасности цепочки поставок полезны только в том случае, если вы проверяете их перед развертыванием. Пакет релиза может содержать манифест Kubernetes, SBOM (спецификацию программного обеспечения), метаданные образа и файл контрольных сумм. Контрольная сумма подтверждает, что перечисленные файлы не были изменены. SBOM и метаданные образа помогают убедиться, что релиз содержит именно те образы и пакеты, которые заявлены.
В этой лабораторной работе вы проверите локальный пакет релиза с помощью sha256sum и jq, подтвердите, что SBOM и метаданные образа описывают утвержденную рабочую нагрузку, запишете компактный результат проверки в формате JSON и развернете только утвержденный манифест. Эта работа не требует внешних загрузок или инструментов подписи. Она фокусируется на ключевом навыке CKS: проверке локальных доказательств перед тем, как доверять артефакту релиза.
Изучение пакета релиза
На этом этапе вы изучите содержимое пакета релиза перед выполнением каких-либо команд проверки. Это важно, так как файлы контрольных сумм охватывают только те пути, которые в них указаны. Файл может присутствовать в пакете, но при этом не входить в утвержденный набор релиза.
Начните с перехода в директорию проекта и ознакомьтесь с примечаниями:
cd /home/labex/project
sed -n '1,180p' RELEASE_VALIDATION_NOTES.md
Выведите список файлов в пакете:
find release-bundle -path release-bundle/evidence -prune -o -type f -print | sort | tee release-bundle/evidence/bundle-files.txt
Перейдите в директорию пакета и изучите файл контрольных сумм:
cd /home/labex/project/release-bundle
cat checksums.sha256 | tee evidence/checksum-file-review.txt
Вы должны увидеть контрольные суммы для manifests/receipt-ledger-approved.yaml, sbom.json и image-metadata.json. Неуказанный манифест должен присутствовать в пакете, но его не должно быть в checksums.sha256.
Проверка контрольных сумм и отклонение неуказанного кандидата
На этом этапе вы проверите перечисленные артефакты с помощью sha256sum -c. Опция -c считывает ожидаемые хеши из файла контрольных сумм и сравнивает их с текущими файлами. Успешный результат означает, что файлы соответствуют утвержденным контрольным суммам.
Запустите проверку контрольных сумм:
sha256sum -c checksums.sha256 | tee evidence/checksum-verification.txt
Убедитесь, что неуказанный манифест не является частью утвержденных доказательств:
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
Первая команда должна вывести OK для трех перечисленных файлов. Вторая команда должна подтвердить, что неуказанный манифест отсутствует в списке утвержденных контрольных сумм.
Сопоставление метаданных SBOM с метаданными образа
На этом этапе вы изучите SBOM и метаданные образа. Контрольная сумма подтверждает, что файлы не изменились, но она не объясняет, описывает ли SBOM именно тот образ, который вы планируете развернуть. Для этого сравните имя образа и его дайджест в обоих файлах.
Извлеките метаданные компонента из SBOM:
jq '.metadata.component' sbom.json | tee evidence/sbom-component.json
Убедитесь, что SBOM содержит ожидаемую запись о пакете:
jq '.components[] | select(.name == "busybox")' sbom.json | tee evidence/sbom-required-package.json
Изучите метаданные образа:
jq . image-metadata.json | tee evidence/image-metadata-review.json
Теперь создайте компактный JSON-файл с результатами проверки на основе изученных данных. Переменные оболочки считывают контрольную сумму утвержденного манифеста и дайджест образа из пакета, вместо того чтобы прописывать их вручную.
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
Этот JSON — не просто отчет, а машиночитаемая запись фактов проверки, которые необходимо иметь перед развертыванием.
Развертывание только утвержденного манифеста
На этом этапе вы развернете только тот манифест, который прошел проверку контрольных сумм. Неуказанный кандидат присутствует в пакете, но так как он не был включен в файл утвержденных контрольных сумм, он не должен попасть в кластер.
Примените утвержденный манифест:
kubectl apply -f manifests/receipt-ledger-approved.yaml
Дождитесь завершения развертывания:
kubectl -n cks-prep-sbom rollout status deployment/receipt-ledger --timeout=120s
Убедитесь, что неуказанное развертывание (Deployment) не было создано:
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
Прочитайте статус выполнения из утвержденного пода:
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
Статус выполнения должен быть следующим:
release-status=approved
Резюме
Вы изучили локальный пакет релиза, проверили утвержденные контрольные суммы, подтвердили, что неуказанный кандидат не входит в утвержденный набор релиза, сопоставили метаданные SBOM с метаданными образа, записали компактные доказательства проверки в формате JSON и развернули только утвержденный манифест Kubernetes. Это основной рабочий процесс обеспечения безопасности цепочки поставок: проверка целостности и подлинности перед развертыванием.
