Proteger la integración de envíos

Introducción

Una integración de envíos lee pedidos pendientes y publica actualizaciones de expedición. Su ejemplo actual parece limpio, pero una clave eliminada podría seguir dando acceso. Eres responsable de contener la exposición y recuperar la ejecución pendiente de despacho.

Aplica la investigación de Git, revocación selectiva, elección de ámbitos, configuración privada y verificación empresarial practicadas en los laboratorios guiados. Completa el resultado de envíos preservando el monitor independiente. El desafío comienza en su propio entorno preparado.

Recuperar la integración de envíos

Situación actual

El equipo de despacho utiliza un worker preparado para leer pedidos pendientes y publicar actualizaciones de envío. Por ejemplo, el pedido O-201 debe recibir el estado ready al procesar el lote. Se eliminó una clave del ejemplo actual, pero una alerta indica que sigue recuperable en el historial. El lote dispatch está pendiente. Un monitor de disponibilidad independiente debe seguir funcionando; se admite una pausa temporal del despacho durante la contención.

El entorno utiliza el mismo proveedor local de formación, métodos de Git, interfaz de gestión, formato INI y dos roles de terminal de los laboratorios guiados. Es sintético y no necesita cuenta externa.

Usa las credenciales de esta VM, no las de un laboratorio anterior. Como en los laboratorios guiados, este proveedor usa 401 para claves inválidas o revocadas, 403 para claves válidas sin el ámbito requerido y 200 para lecturas aceptadas. El worker lee el archivo privado en cada invocación; no requiere reinicio.

Alcance

• Workstation se abre en /home/labex/project/repository. Sus tres commits y shipping-example.ini contienen las pruebas históricas. El ejemplo actual no es la configuración de ejecución.
• Integration se ejecuta como keyworker en /home/labex/project. La configuración privada es runtime/job.ini; el worker sin modificar es /opt/keylab/worker.py y acepta un nombre de lote como argumento.
• La API está en http://127.0.0.1:8000. Key Manager administra credenciales usando el token de /home/labex/.config/keylab/operator-token.
• El monitor independiente usa lab_key_monitor_only con GET /v1/health.

Tu objetivo

La credencial expuesta históricamente ya no concede acceso a la API. El worker de envíos sin modificar utiliza una sustituta dedicada y distinta en su configuración privada, y el servicio receptor contiene el resultado completo de dispatch bajo esa sustituta. Esta no puede acceder al directorio de clientes y el monitor independiente sigue sano.

Criterios de aceptación

• La clave histórica está revocada y obtiene 401 al acceder a pedidos, mientras la API sigue accesible.
• La sustituta configurada está activa, tiene exactamente los dos ámbitos empresariales de envíos y es distinta de la clave expuesta.
• /home/labex/project/runtime/job.ini pertenece a keyworker, tiene modo 600 y es legible por esa cuenta de servicio. El nuevo secreto no aparece en archivos ni commits del repositorio.
• El worker sin modificar leyó el lote asignado dispatch con la sustituta configurada; la API aceptó los pedidos O-201 y O-202, ambos con estado ready, bajo el mismo ID sustituto.
• La sustituta recibe 403 al acceder al directorio de clientes. La credencial del monitor sin modificar sigue recibiendo 200 del endpoint de salud.

Pistas

Resumen

Trasladaste la respuesta a incidentes de un trabajo de soporte a una integración de envíos. Una respuesta completa invalida el secreto histórico, restaura la operación real con una credencial dedicada y restringida, mantiene los secretos fuera del control de versiones y preserva el acceso independiente al servicio.