Rétablir une tâche avec une clé restreinte

Introduction

La clé de support exposée a été révoquée. Le service reste disponible, mais la tâche de synthèse ne peut plus s’authentifier : son fichier privé contient encore l’ancienne valeur. Le lot daily attend toujours sa synthèse.

Vous apprendrez les scopes, émettrez une clé de remplacement, modifierez la configuration privée du worker et réaliserez une exécution métier. Vous testerez aussi le refus d’accès au répertoire clients et la bonne santé du moniteur indépendant. Ce laboratoire fournit son propre état après confinement, sans réutiliser la VM précédente.

Tester un identifiant en lecture seule

Dans cette étape, vous distinguerez un identifiant invalide d’un identifiant valide mais insuffisamment autorisé. Cet environnement neuf commence après confinement : key_support_old est révoquée, la tâche conserve son ancien secret et le lot daily n’est pas traité. Aucun fichier ni VM du laboratoire précédent n’est nécessaire. Les clés et jetons opérateur appartiennent à cette VM ; obtenez leurs valeurs ici plutôt que de réutiliser celles d’un autre environnement.

Workstation est le terminal de maintenance dans /home/labex/project/repository. Integration s’exécute sous keyworker dans /home/labex/project. Key Manager est l’interface de maintenance du fournisseur. L’API locale se trouve sur http://127.0.0.1:8000 ; son comportement fictif est propre à ce cours.

Un scope autorise une opération nommée. Le moindre privilège accorde les opérations nécessaires à la tâche et laisse les autres indisponibles. La synthèse lit les tickets et publie des résumés, sans consulter le répertoire clients.

Reconnaître un refus d’autorisation

Une clé de démonstration en lecture seule est valide mais ne peut pas publier. Dans Workstation, envoyez une demande de publication. curl -X POST choisit l’écriture ; -H fournit les en-têtes, -d le corps JSON, -s masque la progression et -w affiche le statut. L’objet vide {} suffit : le fournisseur refuse l’autorisation avant de vérifier le corps : L’en-tête Content-Type: application/json indique au service que le corps utilise 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

Ici, 403 signifie que l’identifiant est authentifié mais manque du scope requis. À l’inverse, 401 rejette l’identifiant lui-même. Une clé en lecture seule ne termine pas un travail de lecture et d’écriture ; une clé universelle autorise trop d’actions. Le remplacement exige les deux scopes métier du tableau.

Émettre un remplacement dédié

Dans cette étape, vous émettrez un remplacement dédié avec les deux scopes choisis précédemment. Vous enregistrerez son secret de façon privée à l’étape suivante. Le nom sert d’étiquette ; seuls les scopes contrôlent les droits.

Émettre un identifiant dédié

Dans Workstation, affichez le jeton opérateur avec cat, qui lit un fichier :

cat /home/labex/.config/keylab/operator-token

Dans Key Manager, saisissez-le dans Operator token, choisissez Sign in, puis Open Key Manager. L’authentification opérateur est distincte des clés applicatives. Vérifiez que key_support_old indique déjà Revoked.

Sous Issue a key, donnez Name égal à Support summary replacement. Cochez seulement tickets:read et summaries:write, puis choisissez Issue key. L’interface affiche un ID non secret et Secret shown once. Copiez la valeur commençant par lab_key_ avant de quitter cette page. Le fournisseur conserve un hachage plutôt qu’un secret récupérable. Un hachage est une empreinte à sens unique : il permet de comparer une valeur fournie sans afficher l’original conservé.

Si vous perdez la valeur, révoquez cette clé inutilisée par son ID et émettez-en une autre. Ne réutilisez pas le secret exposé et n’élargissez pas les droits pour résoudre une erreur de copie.

Enregistrer la configuration privée d’exécution

Dans cette étape, vous enregistrerez le remplacement dans le fichier privé du compte de service et vérifierez ses permissions. Utilisez Integration pour toutes les commandes ci-dessous.

La configuration d’exécution est le fichier lu par le programme lorsqu’il fonctionne. Le worker lit /home/labex/project/runtime/job.ini à chaque appel : aucun redémarrage n’est requis. L’exemple du dépôt n’est pas ce fichier. Dans Integration, affichez la configuration actuelle :

cat /home/labex/project/runtime/job.ini

[integration]
api_key = lab_key_support_exposed

Gardez les secrets hors du dépôt et de l’historique des commandes. read de Bash reçoit une valeur à l’invite : -r conserve les caractères littéraux, -s masque la saisie et -p affiche un message. API_KEY est une variable temporaire du shell. Exécutez ceci dans Integration, collez le nouveau secret à l’invite et appuyez sur Enter. La saisie est invisible :

read -r -s -p 'Replacement key: ' API_KEY

printf écrit du texte formaté. \n crée des sauts de ligne, %s insère la valeur, les guillemets doubles la conservent en un argument et > remplace le fichier indiqué. Le fichier privé existant appartient à keyworker, le compte de ce terminal :

printf '[integration]\napi_key = %s\n' "$API_KEY" > /home/labex/project/runtime/job.ini

chmod définit les permissions. Le mode 600 autorise uniquement le propriétaire à lire et écrire ; le groupe et les autres comptes n’ont aucun accès :

chmod 600 /home/labex/project/runtime/job.ini

ls -l montre propriétaire et permissions sans afficher le secret :

ls -l /home/labex/project/runtime/job.ini

Repérez -rw------- et le propriétaire keyworker. La taille et la date peuvent varier. Une variable seule ne modifie pas ce fichier ; son enregistrement fait utiliser le nouvel identifiant au prochain appel du worker.

Gardez ce terminal Integration ouvert. API_KEY appartient à ce shell, pas à tous les terminaux. L’étape suivante l’utilise pour des requêtes indépendantes, puis la supprime. Si vous fermez ou reconnectez le terminal, répétez cette étape avec le secret actuel de job.ini, affiché par la commande cat ci-dessus.

Terminer et vérifier l’exécution métier

Dans cette étape, vous traiterez le lot daily et testerez les accès autorisés et interdits. Le worker est fourni : conservez /opt/keylab/worker.py inchangé. Il faut rétablir les identifiants, pas modifier le programme pour contourner l’authentification.

Dans Integration, lancez le lot assigné :

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: ...

L’ID de réception doit correspondre à votre clé de remplacement dans Key Manager. En cas de 401, vérifiez que le secret enregistré est celui du remplacement actif. En cas de 403, comparez ses scopes au tableau. Si nécessaire, révoquez le remplacement mal autorisé, émettez-en un correct, modifiez le fichier privé et relancez le lot. Répéter ce lot remplace son enregistrement, sans créer de synthèses en double.

Examiner le véritable service destinataire

Restez dans le même terminal Integration. La variable API_KEY de l’étape précédente est encore disponible ; inutile de saisir à nouveau le secret affiché une seule fois.

Utilisez l’endpoint de résultats en lecture seule. Le tube | transmet la réponse au programme suivant ; python3 -m json.tool lance le formateur JSON de Python pour une indentation lisible :

curl -s -H "Authorization: Bearer $API_KEY" http://127.0.0.1:8000/v1/results | python3 -m json.tool

Repérez daily, ses trois sujets dans payload et le key_id du remplacement. Cet enregistrement provient de l’API destinataire, pas d’un fichier local de réussite. Le backend conserve aussi l’identifiant ayant lu les données sources.

Testez maintenant l’accès interdit au répertoire clients :

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

Ce rejet attendu confirme la restriction. Utilisez unset pour supprimer la variable temporaire lorsque vous n’en avez plus besoin ; le fichier d’exécution enregistré reste inchangé :

unset API_KEY

Dans Workstation, confirmez que l’ancienne clé reste inutilisable et que le moniteur fonctionne :

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

Enfin, git status --short liste de manière compacte les fichiers modifiés ou non suivis du dépôt :

git status --short

Le parcours guidé ne produit aucune sortie : seul le fichier privé a été modifié. Ne placez jamais le remplacement dans un exemple ou un commit. Comme l’a montré le premier laboratoire, l’historique peut conserver les secrets après la disparition de leurs lignes visibles.

Résumé

Vous avez distingué l’échec d’authentification du manque d’autorisation, choisi les scopes de lecture et d’écriture, enregistré un secret affiché une seule fois de manière privée et terminé la synthèse attendue. Vous avez vérifié l’enregistrement reçu, le rejet de l’ancienne clé, l’interdiction d’accès aux clients et la disponibilité du moniteur. Une rotation utile rétablit le travail légitime et retire l’accès de l’identifiant exposé.