Sécuriser l’intégration d’expédition

Introduction

Une intégration d’expédition lit les commandes en attente et publie leurs mises à jour. L’exemple courant du dépôt paraît propre, mais une clé supprimée pourrait toujours donner accès au service. Vous devez contenir cette exposition et rétablir l’exécution d’expédition en attente.

Appliquez l’enquête Git, la révocation ciblée, le choix des scopes, la configuration privée et la vérification métier des laboratoires guidés. Terminez le résultat d’expédition tout en préservant le moniteur indépendant. Le défi démarre dans son propre environnement préparé.

Rétablir l’intégration d’expédition

Situation actuelle

L’équipe d’expédition utilise un worker préparé pour lire les commandes en attente et publier leurs mises à jour. Par exemple, la commande O-201 doit obtenir l’état ready après traitement du lot. Une clé a été supprimée de l’exemple courant, mais une alerte indique qu’elle reste récupérable dans l’historique. Le lot dispatch est en attente. Un moniteur indépendant doit rester opérationnel ; une pause temporaire des expéditions est acceptable pendant le confinement.

Le fournisseur local de formation, les méthodes Git, le gestionnaire, le format INI et les deux rôles de terminal sont ceux des laboratoires guidés. L’environnement est fictif et ne demande aucun compte externe.

Utilisez les identifiants de cette VM, pas ceux d’un laboratoire précédent. Comme dans les laboratoires guidés, ce fournisseur utilise 401 pour une clé invalide ou révoquée, 403 pour une clé valide sans le scope requis et 200 pour une lecture acceptée. Le worker relit le fichier privé à chaque appel ; aucun redémarrage n’est requis.

Périmètre

• Workstation s’ouvre dans /home/labex/project/repository. Ses trois commits et shipping-example.ini contiennent les preuves historiques. L’exemple courant n’est pas la configuration d’exécution.
• Integration s’exécute sous keyworker dans /home/labex/project. Le fichier privé est runtime/job.ini ; le worker à conserver inchangé est /opt/keylab/worker.py, qui prend un nom de lot en argument.
• L’API est sur http://127.0.0.1:8000. Key Manager administre les identifiants grâce au jeton de /home/labex/.config/keylab/operator-token.
• Le moniteur indépendant utilise lab_key_monitor_only avec GET /v1/health.

Votre objectif

L’identifiant historiquement exposé ne donne plus accès à l’API. Le worker inchangé utilise un remplacement distinct et dédié dans sa configuration privée ; le destinataire possède le résultat complet de dispatch reçu sous ce remplacement. Celui-ci ne peut pas lire le répertoire clients et le moniteur indépendant reste opérationnel.

Critères d’acceptation

• La clé historique est révoquée et reçoit 401 pour les commandes, alors que l’API reste accessible.
• Le remplacement configuré est actif, distinct de l’ancienne clé et doté exactement des deux scopes métier d’expédition.
• /home/labex/project/runtime/job.ini appartient à keyworker, a le mode 600 et peut être lu par ce compte de service. Le nouveau secret n’apparaît ni dans les fichiers ni dans les commits du dépôt.
• Le worker inchangé a lu le lot assigné dispatch avec le remplacement configuré ; l’API a reçu les commandes O-201 et O-202, toutes deux à l’état ready, sous le même ID de remplacement.
• Le remplacement reçoit 403 pour le répertoire clients. Le moniteur inchangé obtient toujours 200 sur l’endpoint de santé.

Indices

Résumé

Vous avez transféré la réponse aux incidents d’une tâche de support à une intégration d’expédition. Une réponse complète invalide le secret historique, rétablit l’activité réelle avec un identifiant dédié et restreint, garde les secrets hors du contrôle de versions et préserve les accès indépendants.