Introducción
La clave expuesta de soporte ya está revocada. El servicio está disponible, pero el trabajo de resumen no puede autenticarse porque su configuración privada aún contiene el valor anterior. El lote pendiente daily sigue necesitando su resumen.
Aprenderás los ámbitos de permisos, emitirás una clave sustituta, actualizarás la configuración privada del worker y completarás una ejecución empresarial real. También probarás que el acceso al directorio de clientes siga prohibido y que el monitor independiente continúe funcionando. Este laboratorio proporciona su propio entorno posterior a la contención; no reutiliza la VM anterior.
Probar una credencial de solo lectura
En este paso, distinguirás una credencial inválida de otra válida con permisos insuficientes. Este entorno nuevo comienza después de la contención: key_support_old está revocada, el trabajo sigue usando su secreto y el lote daily no está procesado. No necesitas archivos ni la VM del laboratorio anterior. Las claves y los tokens de operador pertenecen a esta VM; obtén aquí sus valores en vez de reutilizar credenciales de otro entorno.
Workstation es la terminal de mantenimiento en /home/labex/project/repository. Integration se ejecuta como keyworker en /home/labex/project. Key Manager es la interfaz de mantenimiento del proveedor. La API local de formación está en http://127.0.0.1:8000; su comportamiento sintético es específico de este curso.
Un ámbito es permiso para una operación con nombre. El privilegio mínimo concede las operaciones necesarias para el trabajo y deja fuera las demás. El programa lee tickets y publica resúmenes; no lee el directorio de clientes.
| Operación | Ámbito requerido | ¿Lo necesita el trabajo? |
|---|---|---|
GET /v1/tickets |
tickets:read |
Sí: entrada |
POST /v1/summaries |
summaries:write |
Sí: salida |
GET /v1/customers |
customers:read |
No |
GET /v1/health |
health:read |
No: monitor independiente |
GET /v1/results |
tickets:read |
Consultar resúmenes recibidos |
Reconoce un fallo de permisos
La clave de demostración de solo lectura es válida, pero no permite publicar. En Workstation, envíale una solicitud de publicación. curl -X POST selecciona la operación de escritura; -H proporciona cabeceras, -d el cuerpo JSON, -s oculta el progreso y -w imprime el estado. Basta el objeto vacío {} porque el proveedor rechaza el permiso antes de validar el cuerpo: La cabecera Content-Type: application/json indica al servicio que el cuerpo utiliza JSON.
curl -s -w '\nHTTP %{http_code}\n' -X POST -H 'Authorization: Bearer lab_demo_read_only' -H 'Content-Type: application/json' -d '{}' http://127.0.0.1:8000/v1/summaries
{"error":"Missing scope","required":"summaries:write"}
HTTP 403
En esta API, 403 significa que la credencial se autenticó, pero carece del ámbito requerido. Compáralo con 401, que rechaza la propia credencial. Una clave de solo lectura no completa un trabajo de lectura y escritura; una de acceso total permite demasiado. Tu sustituta necesita los dos ámbitos empresariales de la tabla.
Emitir una sustituta dedicada
En este paso, emitirás una sustituta dedicada con los dos ámbitos elegidos anteriormente. Guardarás su secreto privadamente en el siguiente paso. El nombre es una etiqueta útil; solo los ámbitos controlan los permisos.
Emite una credencial dedicada
En Workstation, imprime el token de operador con cat, que muestra un archivo:
cat /home/labex/.config/keylab/operator-token
En Key Manager, introduce el valor en Operator token, selecciona Sign in y sigue Open Key Manager. La autenticación del operador es independiente de las claves de aplicación. Confirma que key_support_old ya está Revoked.
En Issue a key, introduce Support summary replacement como Name. Marca únicamente tickets:read y summaries:write, y selecciona Issue key. La interfaz muestra un ID no secreto y Secret shown once. Copia el valor secreto, que comienza por lab_key_, antes de abandonar la página. El proveedor guarda un hash, no un secreto recuperable. Un hash es una huella unidireccional: permite comparar un valor suministrado sin mostrar el original almacenado.
Si pierdes el valor, revoca esa clave sin usar por su ID y emite otra. No reutilices el valor expuesto ni amplíes permisos para resolver un error de copia.
Guardar la configuración privada de ejecución
En este paso, guardarás la sustituta en el archivo privado de la cuenta de servicio y comprobarás sus permisos. Usa Integration para todos los comandos siguientes.
La configuración de ejecución es el archivo que lee el programa al funcionar. Este worker lee /home/labex/project/runtime/job.ini en cada invocación, por lo que no requiere reinicio. El ejemplo del repositorio no es ese archivo. En Integration, inspecciona la configuración actual:
cat /home/labex/project/runtime/job.ini
[integration]
api_key = lab_key_support_exposed
Mantén los secretos fuera del repositorio y del historial de comandos. read de Bash acepta un valor en un indicador: -r conserva caracteres literales, -s oculta la entrada y -p imprime el mensaje. API_KEY es una variable temporal del shell. Ejecuta este comando en Integration, pega el nuevo secreto cuando se solicite y pulsa Enter. La entrada no se muestra:
read -r -s -p 'Replacement key: ' API_KEY
printf escribe texto formateado. Aquí \n crea saltos de línea, %s inserta el valor de la variable, las comillas dobles lo mantienen como un argumento y > reemplaza el archivo indicado. El archivo privado existente pertenece a keyworker, la cuenta de esta terminal:
printf '[integration]\napi_key = %s\n' "$API_KEY" > /home/labex/project/runtime/job.ini
Usa chmod para establecer permisos. El modo 600 permite leer y escribir únicamente al propietario; ni el grupo ni otras cuentas tienen acceso:
chmod 600 /home/labex/project/runtime/job.ini
ls -l muestra propietario y permisos sin imprimir el secreto:
ls -l /home/labex/project/runtime/job.ini
Busca -rw------- y el propietario keyworker. El tamaño y la fecha pueden variar. Una variable del shell por sí sola no actualiza el archivo; guardarlo hace que la siguiente invocación use la nueva credencial.
Mantén abierta esta terminal Integration. API_KEY pertenece a este shell, no a todas las terminales. El siguiente paso la usa para solicitudes independientes y luego la elimina. Si cierras o reconectas la terminal, repite este paso con el secreto actual de job.ini, visible mediante el comando cat anterior.
Completar y verificar la ejecución empresarial
En este paso, procesarás el lote pendiente daily y probarás comportamientos permitidos y prohibidos. El worker está preparado: no modifiques /opt/keylab/worker.py. La tarea es recuperar credenciales, no alterar el programa para eludir la autenticación.
En Integration, ejecuta el lote asignado:
python3 /opt/keylab/worker.py daily
Read batch: daily (3 items)
{"batch":"daily","count":3,"subjects":["Reset password","Invoice copy","Delivery question"]}
Received batch: daily
Receiving key ID: ...
El ID receptor debe coincidir con el de tu sustituta en Key Manager. Si recibes 401, comprueba que el secreto guardado corresponde a la sustituta activa. Si recibes 403, compara sus ámbitos con la tabla. Si hace falta, revoca la sustituta con ámbitos incorrectos, emite una correcta, actualiza el archivo privado y repite el lote. Repetirlo reemplaza el registro recibido en vez de crear resúmenes duplicados.
Inspecciona el servicio receptor real
Continúa en la misma terminal Integration. La variable API_KEY del paso anterior sigue disponible; no necesitas volver a introducir el secreto mostrado una sola vez.
Usa el endpoint de resultados de solo lectura. Una tubería | pasa la respuesta al siguiente programa; python3 -m json.tool ejecuta el formateador JSON de Python para mostrar una sangría legible:
curl -s -H "Authorization: Bearer $API_KEY" http://127.0.0.1:8000/v1/results | python3 -m json.tool
Busca daily, sus tres asuntos dentro de payload y el key_id de tu sustituta. El registro procede de la API receptora, no de un archivo local de éxito. El backend también registra qué credencial leyó los datos de origen.
Prueba ahora una solicitud prohibida al directorio de clientes:
curl -s -w '\nHTTP %{http_code}\n' -H "Authorization: Bearer $API_KEY" http://127.0.0.1:8000/v1/customers
{"error":"Missing scope","required":"customers:read"}
HTTP 403
Este rechazo esperado confirma la restricción. Usa unset para eliminar la variable temporal cuando ya no la necesites; el archivo de ejecución guardado no cambia:
unset API_KEY
En Workstation, confirma que la clave antigua sigue inutilizable y el monitor continúa sano:
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_support_exposed' http://127.0.0.1:8000/v1/tickets
{"error":"Invalid or revoked key"}
HTTP 401
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
Por último, git status --short enumera de forma compacta archivos modificados o no rastreados del repositorio:
git status --short
La ruta guiada no produce salida porque solo modificaste el archivo privado de ejecución. Nunca guardes la nueva clave en un ejemplo ni en un commit. Como mostró el primer laboratorio, el historial puede conservar secretos después de desaparecer sus líneas visibles.
Resumen
Distinguiste el fallo de autenticación de la falta de permisos, elegiste un par de ámbitos de lectura y escritura, guardaste privadamente un secreto mostrado una sola vez y completaste el resumen pendiente. Comprobaste el registro recibido, el rechazo de la clave antigua, la prohibición de acceso a clientes y la disponibilidad del monitor. Una rotación útil restaura el trabajo legítimo y elimina el acceso de la credencial expuesta.
