Introdução
Uma versão útil para lançamento deve ser aquela que realmente passou pelas verificações. Um relatório dizendo "aprovado" é insuficiente se o pacote contiver uma imagem diferente ou se a homologação executar uma versão antiga.
Este estado inicial cumulativo do DeskLite já aplica os controles anteriores de código-fonte, credenciais, dependências, contêineres, logs e entrega. Você vinculará o commit atual do código-fonte, a imagem realmente verificada, o relatório gerado, os bytes do pacote e o ambiente local em execução. As únicas operações novas são o fluxo de lançamento fornecido, o empacotamento com tar e a verificação de checksum.
Revise o estado inicial cumulativo funcional
Nesta etapa, você identificará a versão do código-fonte e o estado inicial funcional que está prestes a lançar.
cd /home/labex/project/ticket-release
git status
Espere uma árvore de trabalho limpa. git rev-parse HEAD imprime o identificador completo do commit atual; HEAD nomeia a versão atualmente selecionada no checkout:
git rev-parse HEAD
O identificador varia por sessão. Mais adiante, ele deverá corresponder ao manifesto de lançamento e à versão do aplicativo em execução.
cat Dockerfile
Localize as cópias explícitas de arquivos de negócio, a instalação offline de dependências e USER nobody. A base Python em cache e os wheels estão preparados. Construir pacotes como parte da construção da imagem é separado da identidade não root do aplicativo final em execução.
.venv/bin/python -m pip show requests
Espere 2.32.4. Os mesmos requisitos com versões fixadas serão instalados na imagem candidata.
bash /srv/ticket-release-client/sender.sh
Espere HTTP 200 e o ticket original. Este cliente dedicado já lê seu arquivo protegido de token substituto; o token antigo está revogado. Não copie nenhum dos valores para os metadados de lançamento.
Execute o controle real e seus controles negativos
Nesta etapa, você comprovará que o candidato e o controle de entrega funcionam antes do empacotamento.
bash gate.sh
Os scripts preparados dos estágios executam verificações reais de segredos/histórico, dependências e código-fonte, constroem o aplicativo do commit em uma imagem Docker e iniciam esse candidato real. Os testes funcionais verificam sua versão do código-fonte, Requests 2.32.4, UID não root real 65534, ticket original e rejeição dos tokens antigo/ausente/incorreto.
O controle ainda não publica o pacote final. Ele registra um candidato aceito apenas depois que as verificações e os testes concordam sobre o mesmo código-fonte e a mesma imagem.
Agora exercite os controles negativos confiáveis:
course-release gate-test
Este auxiliar executa seu mesmo controle com uma detecção real de credencial pela regra fixa e depois com um erro real de scanner por entrada inexistente. Espere que ambos bloqueiem antes da construção/teste, com status 1 e 2. Ele restaura o modo normal de controle depois e mantém o ambiente em execução inalterado.
As verificações ainda cobrem as regras fixas de token de prática/SQL e dois avisos selecionados de dependências do curso; elas não constituem uma revisão completa de produção.
Gere metadados vinculados à imagem verificada
Nesta etapa, você gerará evidências de lançamento a partir de resultados reais aceitos, em vez de digitar uma alegação de aprovação.
course-release manifest
O auxiliar exporta a imagem Docker realmente verificada e cria três arquivos em release: image.tar, checks.json e manifest.json. Eles são entradas de entrega de engenharia, não um relatório separado de investigação do aluno.
cat release/manifest.json
source_commit deve ser igual a git rev-parse HEAD. image_id identifica a imagem exata construída, em vez de uma tag que pode mudar. checks_sha256 vincula o relatório real de verificações com valores sensíveis ocultados; image_sha256 vincula os bytes da imagem exportada. run_id relaciona o registro a esta execução real aceita das verificações.
cat release/checks.json
Espere status 0, status individuais das verificações, versões das ferramentas e o mesmo commit de código-fonte. Nenhum valor de credencial deve estar aqui. O manifesto é gerado automaticamente; não edite os campos para alegar que um artefato diferente passou.
Empacote e verifique os bytes do lançamento
Nesta etapa, você criará um arquivo de pacote real e seu checksum.
tar agrupa arquivos em um pacote. -c cria um, -f nomeia seu arquivo de saída e -C release seleciona o diretório cujo conteúdo será lido. O . final significa todo o conteúdo desse diretório:
tar -cf release.tar -C release .
O pacote fica fora do diretório de entrada, portanto não inclui a si próprio. -t lista um pacote existente, com -f indicando seu nome:
tar -tf release.tar
Espere os três arquivos gerados, possivelmente prefixados por ./, além de uma entrada de diretório.
SHA-256 calcula um resumo a partir dos bytes do arquivo. sha256sum imprime o resumo e o nome do arquivo. O redirecionamento já conhecido > salva esse resultado:
sha256sum release.tar > release.tar.sha256
-c lê o registro de checksum salvo e o compara com o arquivo real:
sha256sum -c release.tar.sha256
Espere release.tar: OK. Isso comprova que os bytes correspondem àquele resumo registrado. Um checksum, por si só, não comprova quem publicou o arquivo nem se suas verificações eram válidas.
Verifique a vinculação entre relatório e artefato
Nesta etapa, você verificará mais do que o checksum informado pelo próprio pacote.
course-release verify release.tar
O auxiliar de lançamento lê o pacote real, rejeita membros inesperados/duplicados, compara o manifesto com sua exportação real verificada, confere o relatório original e calcula o hash dos bytes da imagem contida. Ele também exige que o commit atual do código-fonte corresponda.
Espere um PASS vinculando o código-fonte, o relatório, a imagem e o resumo do pacote completo. Isso registra a aprovação desses bytes exatos do pacote no fluxo local de lançamento do curso. Editar checks.json para dizer que passou ou recalcular um checksum para uma imagem alterada não criaria uma execução aceita correspondente das verificações.
Este é um fluxo de ensino com um registro local protegido. O acesso sudo do aluno significa que esta VM não é um limite de confiança de produção. Estamos testando o procedimento de lançamento fornecido, não alegando implementar assinaturas de publicadores nem uma autoridade externa.
Implante esse pacote exato e inspecione a execução
Nesta etapa, você implantará os bytes aprovados e comparará o comportamento em execução com o registro gerado.
course-release deploy release.tar
O auxiliar verifica o pacote novamente, carrega a imagem contida e inicia a homologação local a partir daquele ID exato de imagem. Apenas a porta do serviço local e o registro obrigatório do emissor em modo somente leitura são expostos; credenciais privadas não são incorporadas à imagem.
course-release state
O estado inclui os mesmos identificadores de código-fonte/imagem e o resumo do pacote completo. Agora inspecione o próprio aplicativo:
curl http://127.0.0.1:8080/health
Espere o mesmo source_commit, Requests 2.32.4 e UID 65534.
bash /srv/ticket-release-client/sender.sh
Espere HTTP 200 e o ticket original. Verifique o acesso sem autenticação:
curl -i http://127.0.0.1:8080/tickets
Espere 401. O controle do candidato também testou tokens antigos e incorretos. Apenas um manifesto correspondente não teria comprovado esse comportamento real em execução.
Rejeite um pacote com bytes alterados
Nesta etapa, você testará a aplicação da integridade sem alterar o serviço em execução.
cp copia um arquivo. Mantenha uma cópia de segurança byte a byte do pacote válido:
cp release.tar release-original.tar
printf imprime este marcador conhecido. >> acrescenta a um arquivo, enquanto > o substituiria. Acrescente alguns bytes apenas ao pacote do exercício:
printf 'changed' >> release.tar
sha256sum -c release.tar.sha256
Espere release.tar: FAILED e um código de saída diferente de zero. Mesmo que um leitor tar ignore dados no final, os bytes do pacote completo mudaram.
course-release deploy release.tar
Espere RELEASE BLOCKED porque esses bytes exatos não foram aprovados. Esse resultado diferente de zero é intencional. Um novo checksum escrito pelo usuário não substituiria a vinculação código-fonte/relatório/imagem do fluxo nem sua aprovação do pacote original.
curl http://127.0.0.1:8080/health
A versão anteriormente aprovada permanece em execução. A próxima etapa restaura o pacote válido antes da verificação final.
Restaure e confirme a entrega final
Nesta etapa, você deixará o pacote original verificado e o ambiente funcional de homologação intactos.
cp release-original.tar release.tar
sha256sum -c release.tar.sha256
Espere release.tar: OK novamente.
course-release verify release.tar
course-release state
O pacote restaurado corresponde ao código-fonte/imagem realmente verificados e ao ambiente já em execução. A verificação do curso testa independentemente os controles de falha do gate, rejeita bytes alterados, verifica as camadas reais da imagem em busca das credenciais alvo e confere o comportamento positivo/de rejeição em execução.
Você tem um pacote de lançamento, checksum, manifesto gerado e relatório real, além de uma versão correspondente em execução. Não é necessário escrever uma investigação manualmente. A entrega em produção exigiria adicionalmente controles como identidade do publicador, autorização externa e cobertura de segurança mais ampla; este curso não afirma obtê-los a partir de um checksum local.
Resumo
Você vinculou um commit de código-fonte realmente verificado, uma imagem não root testada, o relatório original gerado, os bytes do pacote de lançamento e a versão local de homologação em execução. Os comportamentos positivo e de rejeição permaneceram corretos, enquanto os bytes modificados foram rejeitados. Checksums sustentam a integridade; este fluxo local não afirma fornecer assinaturas de publicadores nem autorização externa de produção.
