Introducción
Una entrega útil debe ser la versión que realmente superó sus comprobaciones. Un informe que diga «superadas» es insuficiente si el paquete contiene una imagen diferente o el entorno de preproducción ejecuta una versión anterior.
Este estado base acumulativo de DeskLite ya aplica los controles anteriores de código fuente, credenciales, dependencias, contenedores, registros y entrega. Vincularás el commit actual del código fuente, la imagen real comprobada, el informe generado, los bytes del paquete y el entorno local de preproducción en ejecución. Las únicas operaciones nuevas son el flujo de publicación suministrado, el empaquetado con tar y la verificación de sumas de comprobación.
Revisar el Estado Base Acumulativo Operativo
En este paso identificarás la versión del código fuente y el estado base operativo que estás a punto de publicar.
cd /home/labex/project/ticket-release
git status
Espera un árbol de trabajo limpio. git rev-parse HEAD imprime el identificador completo del commit actual; HEAD designa la versión actualmente extraída:
git rev-parse HEAD
El identificador varía según la sesión. Más adelante deberá coincidir con el manifiesto de publicación y la versión de la aplicación en ejecución.
cat Dockerfile
Busca las copias explícitas de archivos de negocio, la instalación de dependencias sin conexión y USER nobody. La imagen base de Python de la caché y los wheels están preparados. Construir paquetes como parte de la construcción de la imagen es independiente de la identidad de ejecución final de la aplicación, que no es root.
.venv/bin/python -m pip show requests
Espera 2.32.4. Los mismos requisitos con versiones fijadas se instalarán en la imagen candidata.
bash /srv/ticket-release-client/sender.sh
Espera HTTP 200 y el ticket original. Este cliente dedicado ya lee su archivo protegido de token de reemplazo; el token anterior está revocado. No copies ninguno de los dos valores en los metadatos de publicación.
Ejecutar el Control Real y sus Casos Negativos
En este paso comprobarás que tanto el candidato como el control funcionan antes de empaquetar.
bash gate.sh
Los scripts envoltorio preparados de las etapas ejecutan comprobaciones reales de secretos e historial, dependencias y código fuente, construyen la aplicación del commit en una imagen Docker e inician ese candidato real. Las pruebas funcionales comprueban su versión del código fuente, Requests 2.32.4, el UID real distinto de root 65534, el ticket original y el rechazo de tokens anteriores, ausentes e incorrectos.
El control todavía no publica el paquete final. Solo registra un candidato aceptado después de que las comprobaciones y las pruebas coincidan sobre el mismo código fuente y la misma imagen.
Ahora prueba los controles negativos de confianza:
course-release gate-test
Esta herramienta auxiliar ejecuta tu mismo control con un hallazgo real de credenciales mediante regla fija y después con un error real de analizador por entrada inexistente. Espera que ambos se bloqueen antes de la construcción y las pruebas, con estados 1 y 2. Después restaura el modo de control normal y deja sin cambios el entorno en ejecución.
Las comprobaciones siguen cubriendo las reglas fijas del curso de tokens de práctica y SQL y dos avisos de dependencias seleccionados; no son una revisión completa de producción.
Generar Metadatos Vinculados a la Imagen Comprobada
En este paso generarás pruebas de publicación a partir de resultados realmente aceptados en lugar de escribir una afirmación de éxito.
course-release manifest
La herramienta auxiliar exporta la imagen Docker real comprobada y crea tres archivos en release: image.tar, checks.json y manifest.json. Son entradas de entrega de ingeniería, no un informe de investigación separado del alumno.
cat release/manifest.json
source_commit debe ser igual a git rev-parse HEAD. image_id identifica la imagen exacta construida en lugar de una etiqueta que puede cambiar. checks_sha256 vincula el informe real de comprobaciones con los valores sensibles ocultos; image_sha256 vincula los bytes de la imagen exportada. run_id conecta el registro con esta ejecución real aceptada de comprobaciones.
cat release/checks.json
Espera el estado 0, los estados de comprobaciones individuales, las versiones de herramientas y el mismo commit del código fuente. Aquí no debe haber valores de credenciales. El manifiesto se genera automáticamente; no edites campos para afirmar que un artefacto distinto superó las comprobaciones.
Empaquetar y Comprobar los Bytes de Publicación
En este paso crearás un archivo real y su suma de comprobación.
tar agrupa archivos en un archivo contenedor. -c lo crea, -f indica su archivo de salida y -C release selecciona el directorio cuyo contenido se leerá. El . final significa todo el contenido de ese directorio:
tar -cf release.tar -C release .
El archivo contenedor queda fuera del directorio de entrada, de modo que no se incluye a sí mismo. -t enumera el contenido de un archivo contenedor existente y -f indica su nombre:
tar -tf release.tar
Espera los tres archivos generados, posiblemente con el prefijo ./, además de una entrada de directorio.
SHA-256 calcula un resumen a partir de los bytes de un archivo. sha256sum imprime el resumen y el nombre del archivo. La redirección conocida > guarda ese resultado:
sha256sum release.tar > release.tar.sha256
-c lee el registro guardado de la suma de comprobación y lo compara con el archivo real:
sha256sum -c release.tar.sha256
Espera release.tar: OK. Esto demuestra que los bytes coinciden con ese resumen registrado. Una suma de comprobación por sí sola no demuestra quién publicó el archivo ni si sus comprobaciones eran válidas.
Verificar la Vinculación entre Informe y Artefacto
En este paso comprobarás más que la suma de comprobación declarada por el propio paquete.
course-release verify release.tar
La herramienta auxiliar de publicación lee el archivo contenedor real, rechaza entradas inesperadas o duplicadas, compara el manifiesto con su exportación real comprobada, comprueba el informe original y calcula el hash de los bytes de la imagen contenida. También exige que coincida el commit actual del código fuente.
Espera un PASS que vincule el código fuente, el informe, la imagen y el resumen del paquete completo. Esto registra la aprobación de estos bytes exactos del paquete en el flujo local de publicación del curso. Editar checks.json para indicar éxito o recalcular una suma de comprobación para una imagen modificada no crearía una ejecución aceptada de comprobaciones que coincidiera.
Este es un flujo didáctico con un registro local protegido. El acceso sudo del alumno significa que esta VM no es un límite de confianza de producción. Estamos probando el procedimiento de publicación suministrado, sin afirmar que implementemos firmas del publicador ni una autoridad externa.
Desplegar Ese Paquete Exacto e Inspeccionar la Ejecución
En este paso desplegarás los bytes aprobados y compararás el comportamiento en ejecución con el registro generado.
course-release deploy release.tar
La herramienta auxiliar vuelve a verificar el paquete, carga la imagen que contiene e inicia el entorno local de preproducción desde ese ID exacto de imagen. Solo se exponen el puerto del servicio local y el registro necesario del emisor en modo de solo lectura; las credenciales privadas no están incorporadas en la imagen.
course-release state
El estado incluye los mismos identificadores de código fuente e imagen y el resumen del paquete completo. Ahora inspecciona la propia aplicación:
curl http://127.0.0.1:8080/health
Espera el mismo source_commit, Requests 2.32.4 y UID 65534.
bash /srv/ticket-release-client/sender.sh
Espera HTTP 200 y el ticket original. Comprueba el acceso sin autenticar:
curl -i http://127.0.0.1:8080/tickets
Espera 401. El control del candidato también probó tokens anteriores e incorrectos. Un manifiesto coincidente por sí solo no habría demostrado este comportamiento real en ejecución.
Rechazar un Paquete con Bytes Modificados
En este paso probarás la aplicación de la integridad sin cambiar el servicio en ejecución.
cp copia un archivo. Conserva una copia de seguridad idéntica byte a byte del paquete válido:
cp release.tar release-original.tar
printf imprime este marcador conocido. >> añade contenido a un archivo, mientras que > lo reemplazaría. Añade unos pocos bytes únicamente al paquete del ejercicio:
printf 'changed' >> release.tar
sha256sum -c release.tar.sha256
Espera release.tar: FAILED y un código de salida distinto de cero. Aunque un lector de tar ignore datos finales adicionales, los bytes del paquete completo han cambiado.
course-release deploy release.tar
Espera RELEASE BLOCKED porque esos bytes exactos no estaban aprobados. Este resultado distinto de cero es intencionado. Una nueva suma de comprobación escrita por el usuario no reemplazaría la vinculación del flujo entre código fuente, informe e imagen ni su aprobación del paquete original.
curl http://127.0.0.1:8080/health
La versión aprobada anteriormente sigue en ejecución. El siguiente paso restaura el paquete válido antes de la verificación final.
Restaurar y Confirmar la Entrega Final
En este paso dejarás intactos el paquete original verificado y el entorno operativo.
cp release-original.tar release.tar
sha256sum -c release.tar.sha256
Espera de nuevo release.tar: OK.
course-release verify release.tar
course-release state
El paquete restaurado coincide con el código fuente y la imagen reales comprobados y con el entorno que ya está en ejecución. La comprobación del curso prueba de forma independiente los controles de fallo del control, rechaza bytes modificados, comprueba las capas reales de la imagen en busca de las credenciales objetivo y verifica el comportamiento positivo y de rechazo en vivo.
Tienes un archivo de publicación, una suma de comprobación, un manifiesto generado y un informe real, y una versión coincidente en ejecución. No se requiere una investigación escrita manualmente. La entrega en producción necesitaría además controles como la identidad del publicador, autorización externa y una cobertura de seguridad más amplia; este curso no afirma obtenerlos de una suma de comprobación local.
Resumen
Vinculaste un commit real de código fuente comprobado, una imagen probada que se ejecuta sin root, el informe original generado, los bytes del paquete de publicación y la versión local de preproducción en ejecución. El comportamiento positivo y de rechazo siguió siendo correcto, mientras que los bytes modificados se rechazaron. Las sumas de comprobación respaldan la integridad; este flujo local no afirma proporcionar firmas del publicador ni autorización externa de producción.
