Introducción
Un trabajo de resumen de soporte lee tickets de clientes y publica una síntesis breve. Alguien eliminó su clave de API del ejemplo más reciente del repositorio, pero las solicitudes con ese valor siguen funcionando. Eres la persona encargada de investigar la alerta.
Primero conocerás el flujo normal; después recuperarás las pruebas históricas, identificarás la credencial y la revocarás. Usarás un proveedor local sintético, dos roles de terminal preparados y Key Manager. Basta con familiaridad básica con la terminal: aquí se presentan Git, las solicitudes API y la revocación de claves.
Leer un ticket mediante la API
Selecciona la pestaña Workstation en la interfaz del laboratorio para comenzar este paso.
En este paso, enviarás una solicitud de lectura de tickets y aprenderás a reconocer su respuesta.
Antes de investigar la credencial, observa qué hace normalmente la integración de soporte. Un ticket es una petición de ayuda de un cliente. El trabajo de resumen es un programa preparado que lee un lote de tickets y devuelve una síntesis breve al servicio. Una integración consiste simplemente en un programa que trabaja con otro.
Este laboratorio utiliza un proveedor local de formación con clientes y claves sintéticos. Su API realiza autenticación y comprobaciones de permisos reales, pero no replica un proveedor de nube. No intervienen cuentas reales ni objetivos externos.
Utiliza los dos roles de terminal
Workstation es tu terminal de mantenimiento. Se abre en /home/labex/project/repository, que contiene ejemplos de configuración. Integration se ejecuta como keyworker, la cuenta propietaria de la configuración privada del trabajo. Usa la terminal indicada para cada comando; cambiar de directorio no cambia la cuenta. La pestaña Key Manager administra credenciales mediante un inicio de sesión de operador independiente.
En la pestaña Workstation, pwd imprime el directorio actual y ls muestra sus nombres de archivo:
Cambia a la pestaña Workstation antes de ejecutar el siguiente comando.
pwd
/home/labex/project/repository
ls
Deberías ver README.md y summary-example.ini. Son ejemplos del repositorio, no el archivo privado que lee el trabajo en ejecución.
Comprende la interfaz de solicitudes
Una API es la interfaz de un servicio para solicitudes de programas. Un endpoint combina una operación y una ruta. Aquí, GET /v1/tickets lee tickets y POST /v1/summaries publica un resumen. http://127.0.0.1:8000 identifica el servicio local de esta VM: 127.0.0.1 significa esta máquina y 8000 es el puerto de escucha.
Las solicitudes llevan una clave de API: un valor secreto que permite autenticar un programa. Se envía en la cabecera Authorization, un dato de solicitud con nombre. Este proveedor espera Bearer seguido del secreto. Mantén las claves sintéticas del ejercicio separadas de cualquier credencial real.
En la pestaña Workstation, realiza una lectura. curl envía una solicitud HTTP; -s oculta el progreso y -H proporciona una cabecera. Las comillas simples mantienen juntos los espacios y el separador de consulta ?. batch=demo selecciona los datos de práctica:
curl -s -H 'Authorization: Bearer lab_key_support_exposed' 'http://127.0.0.1:8000/v1/tickets?batch=demo'
La respuesta usa JSON, un formato de campos con nombre y valores. batch identifica el conjunto de datos; items es una lista y el ticket tiene id y subject. request_id es un identificador de auditoría variable, no un secreto. Busca el asunto Delivery question.
Publicar un resumen de demostración
Selecciona la pestaña Integration en la interfaz del laboratorio para comenzar este paso.
En este paso, usarás el worker preparado para convertir los tickets recién leídos en un resumen aceptado por el servicio. El paso anterior solo leyó datos; este programa también publica el resultado.
En la pestaña Integration, ejecuta el worker sobre el mismo lote de demostración. python3 ejecuta el programa Python proporcionado; la ruta lo identifica y demo es el argumento del lote. No necesitas escribir ni comprender Python para este curso:
Cambia a la pestaña Integration antes de ejecutar el siguiente comando.
python3 /opt/keylab/worker.py demo
Read batch: demo (1 items)
{"batch":"demo","count":1,"subjects":["Delivery question"]}
Received batch: demo
Receiving key ID: key_support_old
La primera solicitud leyó la entrada; la segunda publicó el resumen. Received batch indica que la API receptora lo aceptó. Un ID como key_support_old es una etiqueta no secreta, distinta del valor enviado en la cabecera. Esta ejecución muestra el funcionamiento normal y no completa el lote asignado del posterior laboratorio de recuperación.
Encontrar y revocar la clave histórica
Selecciona la pestaña Workstation en la interfaz del laboratorio para comenzar este paso.
En este paso, encontrarás la credencial histórica, relacionarás su ID con el registro del proveedor y revocarás esa clave exacta. Borrar una línea visible puede ocultarla del archivo actual sin invalidar la credencial.
Lee el presente antes del pasado
En la pestaña Workstation, imprime el ejemplo actual con cat. Un archivo INI agrupa ajustes bajo secciones entre corchetes, como [integration]; cada ajuste tiene nombre, signo igual y valor:
Cambia a la pestaña Workstation antes de ejecutar el siguiente comando.
cat summary-example.ini
[integration]
key_id = key_support_old
api_key = SET_AT_RUNTIME
El marcador es adecuado para un ejemplo compartible, pero no informa sobre copias anteriores ni sobre el estado de la clave en el servicio.
Git registra instantáneas del proyecto llamadas commits. Un repositorio incluye los archivos actuales y el historial de commits. git log los enumera del más reciente al más antiguo; --oneline produce una fila breve por commit. La opción global --no-pager imprime directamente en la terminal sin abrir un visor interactivo:
git --no-pager log --oneline
Verás Document prepared worker, Remove credential from current example y Add integration example. Los identificadores cortos de la izquierda pueden variar.
HEAD identifica el commit más reciente y HEAD~2 el situado dos commits antes. git show muestra un objeto histórico; los dos puntos separan la revisión del nombre de archivo:
git --no-pager show HEAD~2:summary-example.ini
[integration]
key_id = key_support_old
api_key = lab_key_support_exposed
El secreto original sigue siendo recuperable. Borrar el último ejemplo o reescribir el historial local no indica a la API que deje de confiar en copias ya obtenidas por otras personas.
Relaciona la credencial con su registro
Key Manager utiliza un token de operador, una credencial de mantenimiento independiente. Una clave de aplicación no puede administrar claves. En la pestaña Workstation, muestra el token local preparado:
cat /home/labex/.config/keylab/operator-token
Cambia a la pestaña Key Manager, pega el valor en Operator token, selecciona Sign in y después el enlace Open Key Manager. No guardes este token en archivos del repositorio. Si se rechaza el inicio de sesión, selecciona Return to Key Manager en esa misma pestaña, cambia a la pestaña Workstation para copiar otra vez el token de operador de esta VM y vuelve a la pestaña Key Manager para reintentar. Localiza la fila key_support_old y su estado Active. Sus ámbitos describen acciones permitidas; el siguiente laboratorio enseñará a elegirlos.
En Recent API requests, busca una solicitud exitosa de esta clave. El estado 200 significa que la API aceptó una lectura. El historial demuestra exposición y la solicitud demuestra que la credencial funciona; ninguno identifica a quien hizo solicitudes anteriores. No se requiere informe ni copia de registros.
Revoca la clave identificada
Revoca únicamente la clave comprometida. Probarás el rechazo y la disponibilidad independiente en el siguiente paso. La revocación cambia la decisión de aceptación del proveedor; no borra copias del secreto.
En la pestaña Workstation, solicita de nuevo los tickets de demostración mostrando el estado HTTP. -w añade un resultado formateado; \n crea una nueva línea y %{http_code} inserta el estado de respuesta:
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_support_exposed' 'http://127.0.0.1:8000/v1/tickets?batch=demo'
La respuesta termina en HTTP 200. En la pestaña Key Manager, selecciona Revoke en la fila key_support_old. Comprueba el ID: revocar todas las claves interrumpiría trabajos independientes. Ahora la fila debería indicar Revoked.
Probar la contención y la disponibilidad
Selecciona la pestaña Workstation en la interfaz del laboratorio para comenzar este paso.
En este paso, probarás el rechazo de la credencial antigua mientras la API y el monitor independiente siguen disponibles. El estado del gestor es útil, pero las solicitudes reales establecen el límite de acceso.
Repite la misma solicitud en la pestaña Workstation:
Cambia a la pestaña Workstation antes de ejecutar el siguiente comando.
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_support_exposed' 'http://127.0.0.1:8000/v1/tickets?batch=demo'
{"error":"Invalid or revoked key"}
HTTP 401
En esta API, 401 significa que la credencial no puede autenticarse. Este rechazo esperado confirma la contención. Un error de conexión significaría que no se puede alcanzar el servicio; detenerlo no es una solución.
En la pestaña Integration, ejecuta de nuevo el worker:
Cambia a la pestaña Integration antes de ejecutar el siguiente comando.
python3 /opt/keylab/worker.py demo
HTTP 401: {"error":"Invalid or revoked key"}
Este comando debe terminar con un estado de error. El trabajo sigue leyendo el valor revocado de su archivo privado, por lo que ya no puede leer la entrada. Se admite una pausa temporal durante la contención. El siguiente laboratorio parte de este estado para restaurarlo.
Vuelve a la pestaña Workstation y prueba el monitor independiente. Usa su propia credencial y el endpoint de salud:
Cambia a la pestaña Workstation antes de ejecutar el siguiente comando.
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_monitor_only' http://127.0.0.1:8000/v1/health
{"status":"ok","integration":"monitor"}
HTTP 200
Has eliminado el acceso de la credencial expuesta, manteniendo disponibles el servicio y la integración independiente. Puedes ir más allá de la contención; este laboratorio no rechaza una recuperación válida.
Resumen
Seguiste una integración operativa, distinguiste el ID de una clave de su secreto, recuperaste un secreto del historial de Git y revocaste la credencial correspondiente en el proveedor. Probaste el rechazo real y la disponibilidad independiente. Borrar una línea no invalidó la clave; revocarla sí. El siguiente laboratorio restaura el trabajo con una sustituta dedicada y restringida.
