Введение
Полезный выпуск должен быть той версией, которая действительно прошла проверки. Отчёта со словом «passed» недостаточно, если пакет содержит другой образ или в промежуточной среде работает более старая версия.
Эта накопленная исходная версия DeskLite уже применяет изученные ранее меры контроля исходного кода, учётных данных, зависимостей, контейнеров, журналирования и контрольного барьера. Вы свяжете текущий коммит исходного кода, реальный проверенный образ, созданный отчёт, байты пакета и работающую локальную промежуточную среду. Единственные новые операции — предоставленный порядок выпуска, упаковка tar и проверка контрольной суммы.
Проверьте рабочую исходную версию с накопленными мерами защиты
На этом шаге вы определите версию исходного кода и рабочую основу, которую собираетесь выпустить.
cd /home/labex/project/ticket-release
git status
Ожидается чистое рабочее дерево. git rev-parse HEAD выводит полный идентификатор текущего коммита; HEAD обозначает текущую извлечённую версию:
git rev-parse HEAD
Идентификатор отличается между сеансами. Позже он должен совпадать с манифестом выпуска и версией работающего приложения.
cat Dockerfile
Найдите явное копирование бизнес-файлов, офлайн-установку зависимостей и USER nobody. Кэшированная база Python и wheel-пакеты подготовлены. Сборка пакетов при создании образа отделена от непривилегированной учётной записи итогового приложения при выполнении.
.venv/bin/python -m pip show requests
Ожидается 2.32.4. Те же закреплённые требования будут установлены в образ кандидата.
bash /srv/ticket-release-client/sender.sh
Ожидаются HTTP 200 и исходная заявка. Этот выделенный клиент уже читает свой защищённый файл заменяющего токена; старый токен отозван. Не копируйте ни одно значение в метаданные выпуска.
Запустите реальный барьер и его негативные контрольные сценарии
На этом шаге вы установите работоспособность кандидата и контрольного барьера перед упаковкой.
bash gate.sh
Подготовленные обёртки этапов выполняют реальные проверки секретов/истории, зависимостей и исходного кода, собирают приложение из коммита в образ Docker и запускают этого реального кандидата. Функциональные тесты проверяют его версию исходного кода, Requests 2.32.4, реальный непривилегированный UID 65534, исходную заявку и отклонение старого/отсутствующего/неверного токена.
Контрольный барьер пока не публикует итоговый пакет. Он записывает принятого кандидата только после того, как проверки и тесты согласуются по одному и тому же исходному коду и образу.
Теперь выполните доверенные негативные контрольные сценарии:
course-release gate-test
Это вспомогательное средство запускает тот же барьер с реальной находкой учётных данных по фиксированному правилу, а затем с настоящей ошибкой сканера из-за отсутствующего ввода. Ожидается блокировка обоих случаев до сборки/теста со статусами 1 и 2. После этого средство восстанавливает обычный режим контроля и оставляет работающую промежуточную среду без изменений.
Проверки по-прежнему охватывают фиксированные учебные правила токена/SQL и два выбранных уведомления об уязвимостях зависимостей; это не полная проверка рабочей системы.
Создайте метаданные, связанные с проверенным образом
На этом шаге вы создадите свидетельства выпуска из реальных принятых результатов вместо ввода заявления об успехе.
course-release manifest
Вспомогательное средство экспортирует реальный проверенный образ Docker и создаёт три файла в release: image.tar, checks.json и manifest.json. Это инженерные входные данные доставки, а не отдельный отчёт исследования учащегося.
cat release/manifest.json
source_commit должен равняться git rev-parse HEAD. image_id определяет точный собранный образ, а не перемещаемый тег. checks_sha256 связывает реальный отчёт проверок со скрытыми чувствительными значениями; image_sha256 связывает байты экспортированного образа. run_id связывает запись с этим реальным принятым запуском проверок.
cat release/checks.json
Ожидаются статус 0, статусы отдельных проверок, версии инструментов и тот же коммит исходного кода. Значений учётных данных здесь быть не должно. Манифест создаётся автоматически; не редактируйте поля, чтобы заявить, что другой артефакт прошёл проверку.
Упакуйте и проверьте байты выпуска
На этом шаге вы создадите реальный архив и его контрольную сумму.
tar объединяет файлы в архив. -c создаёт его, -f задаёт имя выходного файла, а -C release выбирает каталог, содержимое которого будет прочитано. Заключительная . означает всё содержимое этого каталога:
tar -cf release.tar -C release .
Архив находится вне входного каталога, поэтому не включает сам себя. -t перечисляет содержимое существующего архива, имя которого задано через -f:
tar -tf release.tar
Ожидаются три созданных файла, возможно с префиксом ./, и запись каталога.
SHA-256 вычисляет хеш из байтов файла. sha256sum выводит хеш и имя файла. Знакомое перенаправление > сохраняет этот результат:
sha256sum release.tar > release.tar.sha256
-c читает сохранённую запись контрольной суммы и сравнивает реальный файл:
sha256sum -c release.tar.sha256
Ожидается release.tar: OK. Это доказывает совпадение байтов с записанным хешем. Одна контрольная сумма не доказывает, кто опубликовал файл и были ли его проверки действительными.
Проверьте связь отчёта с артефактом
На этом шаге вы проверите больше, чем собственную заявленную контрольную сумму пакета.
course-release verify release.tar
Средство выпуска читает реальный архив, отклоняет неожиданные/повторяющиеся элементы, сравнивает манифест со своим реальным проверенным экспортом, проверяет исходный отчёт и хеширует содержащиеся внутри байты образа. Оно также требует совпадения текущего коммита исходного кода.
Ожидается PASS, связывающий исходный код, отчёт, образ и хеш полного пакета. Это регистрирует одобрение именно этих байтов пакета в локальном порядке выпуска курса. Редактирование checks.json для указания успеха или пересчёт контрольной суммы изменённого образа не создали бы соответствующий принятый запуск проверок.
Это учебный порядок работы с защищённой локальной записью. Доступ учащегося к sudo означает, что эта VM не является границей доверия рабочей системы. Мы тестируем предоставленную процедуру выпуска, а не заявляем о реализации подписей издателя или внешнего органа доверия.
Разверните именно этот пакет и проверьте выполнение
На этом шаге вы развернёте одобренные байты и сравните живое поведение с созданной записью.
course-release deploy release.tar
Вспомогательное средство снова проверяет пакет, загружает содержащийся в нём образ и запускает локальную промежуточную среду именно из этого идентификатора образа. Открываются только локальный порт сервиса и необходимый реестр системы выдачи только для чтения; приватные учётные данные не встраиваются в образ.
course-release state
Состояние включает те же идентификаторы исходного кода/образа и хеш полного пакета. Теперь проверьте само приложение:
curl http://127.0.0.1:8080/health
Ожидаются тот же source_commit, Requests 2.32.4 и UID 65534.
bash /srv/ticket-release-client/sender.sh
Ожидаются HTTP 200 и исходная заявка. Проверьте доступ без аутентификации:
curl -i http://127.0.0.1:8080/tickets
Ожидается 401. Барьер кандидата также проверил старый и неверный токены. Одного совпадающего манифеста было бы недостаточно для доказательства этого реального работающего поведения.
Отклоните пакет с изменёнными байтами
На этом шаге вы проверите обеспечение целостности без изменения работающего сервиса.
cp копирует файл. Сохраните побайтовую резервную копию действительного пакета:
cp release.tar release-original.tar
printf выводит этот известный маркер. >> дописывает в файл, а > заменил бы его. Допишите несколько байтов только к пакету упражнения:
printf 'changed' >> release.tar
sha256sum -c release.tar.sha256
Ожидаются release.tar: FAILED и ненулевой код завершения. Даже если средство чтения tar игнорирует данные в конце, полные байты пакета изменились.
course-release deploy release.tar
Ожидается RELEASE BLOCKED, потому что именно эти байты не были одобрены. Этот ненулевой результат намеренный. Новая написанная пользователем контрольная сумма не заменила бы связь исходного кода/отчёта/образа в порядке выпуска или одобрение исходного пакета.
curl http://127.0.0.1:8080/health
Ранее одобренная версия остаётся работающей. Следующий шаг восстановит действительный пакет перед итоговой проверкой.
Восстановите и подтвердите итоговую доставку
На этом шаге вы оставите исходный проверенный пакет и работающую промежуточную среду в сохранности.
cp release-original.tar release.tar
sha256sum -c release.tar.sha256
Снова ожидается release.tar: OK.
course-release verify release.tar
course-release state
Восстановленный пакет соответствует реально проверенным исходному коду/образу и уже работающей промежуточной среде. Проверка курса независимо тестирует контрольные сценарии неудачи барьера, отклоняет изменённые байты, проверяет реальные слои образа на целевые учётные данные и проверяет живое позитивное поведение и отказы.
У вас есть архив выпуска, контрольная сумма, созданный манифест и реальный отчёт, а также соответствующая работающая версия. Исследование, написанное вручную, не требуется. Доставка в рабочую среду дополнительно потребовала бы таких мер, как идентификация издателя, внешняя авторизация и более широкое покрытие безопасности; этот курс не выводит их из локальной контрольной суммы.
Резюме
Вы связали реальный проверенный коммит исходного кода, протестированный непривилегированный образ, исходный созданный отчёт, байты пакета выпуска и живую версию локальной промежуточной среды. Позитивное поведение и отказы остались корректными, а изменённые байты были отклонены. Контрольные суммы поддерживают целостность; этот локальный порядок работы не заявляет о подписях издателя или внешней авторизации рабочей среды.
