Introduction
Une tâche de synthèse du support lit les tickets clients et publie un bref résumé. Quelqu’un a retiré sa clé API du dernier exemple du dépôt, mais les requêtes utilisant cette valeur réussissent toujours. Vous êtes responsable de l’enquête sur cette alerte.
Découvrez le fonctionnement normal, retrouvez les preuves historiques, identifiez l’identifiant puis révoquez-le. Vous utiliserez un fournisseur local fictif, deux rôles de terminal préparés et Key Manager. Une familiarité élémentaire avec le terminal suffit : Git, les requêtes API et la révocation sont expliqués ici.
Lire un ticket avec l’API
Dans cette étape, vous enverrez une requête de lecture de tickets et apprendrez à reconnaître sa réponse. Un ticket de support est une demande d’aide d’un client. La tâche de synthèse est un programme préparé qui lit un lot de tickets et renvoie un bref résumé au service. Une intégration est simplement un programme travaillant avec un autre.
Sélectionnez l’onglet Workstation dans l’interface du laboratoire pour commencer cette étape.
Ce laboratoire utilise un fournisseur local de formation avec des clients et clés fictifs. Son API réalise une véritable authentification et de vrais contrôles d’autorisation, sans reproduire un fournisseur cloud. Aucun compte réel ni cible externe n’intervient.
Utiliser les deux rôles de terminal
Workstation est votre terminal de maintenance. Il s’ouvre dans /home/labex/project/repository, qui contient des exemples de configuration. Integration s’exécute sous keyworker, le compte propriétaire de la configuration privée de la tâche. Utilisez le terminal indiqué pour chaque commande ; changer de répertoire ne change pas de compte. L’onglet Key Manager administre les identifiants avec une connexion opérateur distincte.
Dans Workstation, pwd affiche le répertoire courant et ls en liste les noms de fichiers :
Passez à l’onglet Workstation avant d’exécuter la commande suivante.
pwd
/home/labex/project/repository
ls
Vous devriez voir README.md et summary-example.ini. Ce sont des exemples du dépôt, pas le fichier privé lu par la tâche en cours.
Comprendre l’interface de requêtes
Une API est l’interface d’un service pour les requêtes des programmes. Un endpoint associe une opération à un chemin. Ici, GET /v1/tickets lit les tickets et POST /v1/summaries publie une synthèse. http://127.0.0.1:8000 désigne le service local de cette VM : 127.0.0.1 représente cette machine et 8000 le port d’écoute.
Les requêtes portent une clé API, valeur secrète permettant d’authentifier un programme. Elle est envoyée dans l’en-tête Authorization, une métadonnée de requête nommée. Ce fournisseur attend Bearer suivi du secret. Ne mélangez pas les clés fictives de l’exercice avec de véritables identifiants.
Passez à l’onglet Workstation et effectuez une lecture. curl envoie une requête HTTP ; -s masque la progression et -H fournit un en-tête. Les apostrophes conservent ensemble les espaces et le séparateur de paramètres ?. batch=demo sélectionne les données d’entraînement :
curl -s -H 'Authorization: Bearer lab_key_support_exposed' 'http://127.0.0.1:8000/v1/tickets?batch=demo'
La réponse utilise JSON, un format de champs nommés et de valeurs. batch nomme le jeu de données ; items est une liste dont le ticket possède id et subject. request_id est un identifiant d’audit variable, pas un secret. Repérez le sujet Delivery question.
Publier une synthèse de démonstration
Dans cette étape, vous utiliserez le worker fourni pour transformer les tickets lus en une synthèse acceptée par le service. L’étape précédente ne faisait qu’une lecture ; ce programme publie aussi le résultat.
Sélectionnez l’onglet Integration dans l’interface du laboratoire pour commencer cette étape.
Passez à l’onglet Integration et lancez le worker sur le même lot de démonstration. python3 exécute le programme Python fourni ; le chemin désigne ce programme et demo est son argument de lot. Il n’est pas nécessaire d’écrire ou de comprendre Python :
Passez à l’onglet Integration avant d’exécuter la commande suivante.
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 première requête a lu les données et la seconde a publié la synthèse. Received batch signifie que l’API destinataire l’a acceptée. Un ID tel que key_support_old est une étiquette non secrète, différente de la valeur secrète de l’en-tête. Cette exécution illustre le fonctionnement normal ; elle ne termine pas le lot assigné au futur laboratoire de rétablissement.
Retrouver et révoquer la clé historique
Dans cette étape, vous retrouverez l’identifiant historique, associerez son ID à l’enregistrement du fournisseur et révoquerez cette clé précise. Supprimer une ligne visible peut la masquer du dernier fichier sans invalider l’identifiant.
Sélectionnez l’onglet Workstation dans l’interface du laboratoire pour commencer cette étape.
Lire le présent avant le passé
Passez à l’onglet Workstation et affichez l’exemple courant avec cat. Un fichier INI regroupe les paramètres sous une section entre crochets, comme [integration] ; chaque paramètre comporte un nom, un signe égal et une valeur :
Passez à l’onglet Workstation avant d’exécuter la commande suivante.
cat summary-example.ini
[integration]
key_id = key_support_old
api_key = SET_AT_RUNTIME
Cette valeur de substitution convient à un exemple partageable, mais ne renseigne ni sur les copies antérieures ni sur l’état de la clé chez le fournisseur.
Git enregistre des instantanés du projet appelés commits. Un dépôt contient les fichiers actuels et cet historique. git log présente les commits du plus récent au plus ancien ; --oneline produit une ligne courte par commit. L’option globale --no-pager affiche directement le résultat dans le terminal, sans ouvrir de lecteur interactif :
git --no-pager log --oneline
Vous verrez Document prepared worker, Remove credential from current example et Add integration example. Les identifiants courts à gauche peuvent varier.
HEAD désigne le dernier commit et HEAD~2 celui situé deux commits auparavant. git show affiche un objet historique ; les deux-points séparent la révision du nom du fichier :
git --no-pager show HEAD~2:summary-example.ini
[integration]
key_id = key_support_old
api_key = lab_key_support_exposed
Le secret d’origine reste récupérable. Supprimer le dernier exemple ou réécrire l’historique local ne demande pas à l’API de cesser de faire confiance aux copies déjà obtenues ailleurs.
Retrouver l’enregistrement chez le fournisseur
Key Manager utilise un jeton opérateur, identifiant de maintenance distinct. Une clé applicative ne peut pas administrer les clés. Passez à l’onglet Workstation et affichez le jeton local préparé :
cat /home/labex/.config/keylab/operator-token
Passez à l’onglet Key Manager, collez la valeur dans Operator token, choisissez Sign in, puis Open Key Manager. Ne placez pas ce jeton dans le dépôt. Si la connexion est refusée, sélectionnez Return to Key Manager dans ce même onglet, passez à l’onglet Workstation pour recopier le jeton opérateur de cette VM, puis revenez à l’onglet Key Manager pour réessayer. Repérez la ligne key_support_old et son état Active. Ses scopes décrivent les actions autorisées ; le prochain laboratoire expliquera leur choix.
Dans Recent API requests, trouvez une requête réussie de cette clé. Le statut 200 indique une lecture acceptée. L’historique prouve l’exposition et la requête prouve le fonctionnement de l’identifiant ; aucun ne permet d’identifier l’auteur des requêtes précédentes. Aucun rapport ni copie de journaux n’est demandé.
Révoquer la clé identifiée
Révoquez uniquement la clé compromise. Vous testerez le rejet et la disponibilité indépendante à l’étape suivante. La révocation change la décision d’acceptation du fournisseur ; elle n’efface pas les copies du secret.
Passez à l’onglet Workstation et redemandez les tickets de démonstration avec le statut HTTP. -w ajoute un résultat formaté ; \n crée un saut de ligne et %{http_code} insère le statut de réponse :
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 réponse se termine par HTTP 200. Passez à l’onglet Key Manager et choisissez Revoke sur la ligne key_support_old. Vérifiez l’ID : tout révoquer interromprait d’autres tâches. La ligne doit désormais indiquer Revoked.
Tester le confinement et la disponibilité
Dans cette étape, vous testerez le rejet de l’ancien identifiant tout en conservant l’API et le moniteur indépendant disponibles. L’état du gestionnaire est utile, mais les requêtes réelles établissent la frontière d’accès.
Sélectionnez l’onglet Workstation dans l’interface du laboratoire pour commencer cette étape.
Répétez la même requête dans l’onglet Workstation :
Passez à l’onglet Workstation avant d’exécuter la commande suivante.
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
Pour cette API, 401 indique que l’identifiant fourni ne peut pas s’authentifier. Ce rejet attendu confirme le confinement. Une erreur de connexion signifierait plutôt que le service est inaccessible ; l’arrêter ne résout pas le problème.
Passez à l’onglet Integration et relancez le worker :
Passez à l’onglet Integration avant d’exécuter la commande suivante.
python3 /opt/keylab/worker.py demo
HTTP 401: {"error":"Invalid or revoked key"}
Cette commande doit échouer. La tâche lit encore la valeur révoquée dans son fichier privé et ne peut donc plus lire les données. Une pause temporaire du traitement est acceptable pendant le confinement. Le prochain laboratoire part de cet état pour rétablir la tâche.
Revenez à l’onglet Workstation et testez le moniteur indépendant. Il utilise sa propre clé et l’endpoint de santé :
Passez à l’onglet Workstation avant d’exécuter la commande suivante.
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
Vous avez retiré l’accès de l’identifiant exposé tout en préservant le service et l’intégration indépendante. Vous pouvez aussi rétablir la tâche ; une récupération valide n’est pas pénalisée dans ce laboratoire.
Résumé
Vous avez suivi une intégration fonctionnelle, distingué l’ID d’une clé de son secret, retrouvé ce secret dans l’historique Git et révoqué l’identifiant correspondant. Vous avez testé son rejet effectif et une disponibilité indépendante. Supprimer une ligne n’invalidait pas la clé ; la révocation l’a fait. Le prochain laboratoire rétablit la tâche avec une clé dédiée et restreinte.
