Introduction
Meadow Supply dispose d’un petit catalogue et d’un calcul de devis de panier fonctionnel. Sa page publique demande la disponibilité à la Shop API. API signifie Application Programming Interface, ou interface de programmation d’application : ici, c’est l’interface de requêtes de l’application entre la page client et le service de stock interne. Cette API lit le stock pour la page. Actuellement, le processus client et un visiteur distinct peuvent aussi lire directement le stock, y compris des détails de rayonnage dont le catalogue public n’a pas besoin.
Gardez le parcours client normal fonctionnel tout en limitant les connexions au stock au rôle API approuvé dans l’espace de noms approuvé. Votre résultat réutilisable est une NetworkPolicy enregistrée et la limite d’accès active correspondante, étayées par de vraies requêtes plutôt que par un schéma au vert.
Vous devez déjà connaître les chemins de base du terminal, les bases de YAML, les espaces de noms, les Pods, les Deployments, les Services et les labels. Ce lab explique les champs de politique, la commande de diagnostic fournie et les résultats des requêtes avant de les utiliser. Un véritable cluster Kubernetes à un seul nœud avec Calico, l’application et des données synthétiques sont préparés. Aucune installation de cluster, construction d’image ni programmation d’application n’est requise. Le temps est une estimation de l’auteur incluant la lecture et les erreurs courantes. Ce sont des devis d’entraînement : aucune commande, réservation ni aucun paiement n’est effectué.
Garder le stock sur le chemin approuvé
Dans cette étape, vous autoriserez la Shop API à atteindre le stock tout en empêchant les processus client et visiteur de la contourner.
Commencez dans l’onglet Shop. Meadow Supply doit afficher Good things for everyday et trois produits. Ouvrez Glass water bottle, notez son prix $18.00 et Available · 6 in stock, puis choisissez Try a basket quote avec Quantity réglé sur 1. Le résultat doit indiquer Ready for collection, afficher $18.00 et préciser explicitement que rien n’a été réservé, commandé ni payé. Utilisez Back to product, puis Back to collection.
Le véritable chemin de requête est :
Page client → Shop API → Service de stock
La page client s’exécute dans son propre Pod. Ouvrir le site ne transforme pas votre navigateur en Pod du cluster ; les requêtes au stock proviennent des processus d’application préparés. L’API lit le stock par une nouvelle connexion réseau et le combine aux prix du catalogue approuvés. Elle ne dispose d’aucune solution de repli statique pour le stock. Un onglet Reference distinct affiche les notes de retrait de Meadow Dispatch. Ouvrez-le, lisez P-104 et P-108, puis passez à Workspace. Ce service distinct doit continuer à fonctionner.
Le terminal démarre dans /home/labex/project/stock-policy. pwd affiche le répertoire courant ; ls liste ses entrées. Utilisez la commande cd absolue si vous devez revenir ici :
pwd
ls
cd /home/labex/project/stock-policy
Vous devez trouver scope.json, starter et tools. cat affiche le fichier de périmètre préparé. Celui-ci utilise JSON (JavaScript Object Notation), un format texte de valeurs nommées et de listes. Il indique de véritables noms de ressources et cibles de requêtes, plutôt qu’un état de topologie inventé :
cat scope.json
--context=labex-v135 sélectionne le véritable cluster préparé. --show-labels affiche les labels des objets. Un espace de noms regroupe les objets, mais ne bloque pas à lui seul leurs connexions réseau. Lisez les identités des espaces de noms :
kubectl --context=labex-v135 get namespaces meadow-shop meadow-stock meadow-visitors --show-labels
Chacun possède un label intégré kubernetes.io/metadata.name égal à son nom. -n sélectionne un espace de noms. Lisez les Pods et leurs labels :
kubectl --context=labex-v135 -n meadow-shop get pods --show-labels
kubectl --context=labex-v135 -n meadow-stock get pods --show-labels
kubectl --context=labex-v135 -n meadow-visitors get pods --show-labels
Le processus client a role=customer, l’API a role=shop-api et le stock a role=inventory. Le service d’expédition distinct a role=dispatch. Le visiteur se trouve dans meadow-visitors, mais possède délibérément le même label role=shop-api que la véritable API. Un label de rôle seul n’identifie donc pas un espace de noms approuvé.
Lisez les Services. Un Service sélectionne les Pods préparés et fournit une adresse stable. Un port identifie un point d’écoute de l’application. TCP (Transmission Control Protocol) fournit la connexion utilisée par ces requêtes web ; le processus de stock écoute sur le port TCP 8080 :
kubectl --context=labex-v135 -n meadow-stock get services
Le programme fourni ./tools/network-test exécute une véritable requête depuis une identité d’application existante avec kubectl exec. Le préfixe ./ signifie que l’outil se trouve dans le répertoire courant. Son premier argument choisit customer, api, visitor, stock ou reference ; le suivant choisit http, dns ou dns-tcp ; le dernier est la cible. Il ne modifie jamais les politiques et ne répare pas l’application. Les requêtes http utilisent HTTP (Hypertext Transfer Protocol), le protocole de requête et de réponse de ces points d’accès web/API. Le nom complet stock.meadow-stock.svc.cluster.local identifie le Service de stock dans son espace de noms grâce au DNS du cluster (Domain Name System), qui résout les noms de Services en adresses.
Établissez d’abord la connexion et le contenu actuels. Les deux requêtes doivent réussir avant l’isolation :
./tools/network-test api http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
./tools/network-test customer http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
Vous devez obtenir HTTP_REPLY 200, suivi des mêmes données de stock : bottle compte 6 unités sur le rayon M-03, notebook en compte 4 sur M-08 et bag en compte 0 sur M-12. Le client doit obtenir la disponibilité publique par l’API, sans effectuer cette lecture interne directe. Cet état initial prouve que la cible fonctionne avant de la restreindre.
Une NetworkPolicy sélectionne des Pods et autorise des connexions précises pour une direction de trafic. Ingress désigne les connexions arrivant aux Pods sélectionnés. Lorsqu’une politique d’entrée sélectionne le stock, seuls les chemins entrants qu’elle autorise restent disponibles, hormis les exceptions de trafic des nœuds et vers soi-même documentées par Kubernetes. C’est un contrôle réseau des Pods, pas une authentification utilisateur ni une autorisation HTTP.
Créez votre répertoire de publication. mkdir -p le crée si nécessaire et conserve un répertoire existant. La commande cat suivante écrit la politique complète dans votre propre fichier de publication : > redirige la sortie vers ce fichier, et le marqueur YAML entre apostrophes garde le texte littéral jusqu’au marqueur final sur sa propre ligne. Répéter la commande remplace uniquement ce fichier de politique modifiable.
mkdir -p release
cat > release/stock-ingress.yaml <<'YAML'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: stock-ingress
namespace: meadow-stock
spec:
podSelector:
matchLabels:
role: inventory
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: meadow-shop
podSelector:
matchLabels:
role: shop-api
ports:
- protocol: TCP
port: 8080
YAML
Lisez le fichier enregistré avant de l’appliquer :
cat release/stock-ingress.yaml
Le podSelector extérieur sélectionne uniquement le stock, laissant l’expédition hors de cette politique. Dans l’unique entrée from, namespaceSelector et podSelector doivent tous deux correspondre : la source doit être dans meadow-shop et avoir role=shop-api. Les deux sélecteurs sont alignés sous le même élément de liste. Ajouter un autre tiret avant le podSelector intérieur créerait une seconde possibilité, signifiant OU, et autoriserait d’autres Pods de l’espace de noms approuvé. Le port est le port TCP d’écoute du Pod de stock. Cette règle ne limite pas les sorties de l’API.
apply -f lit votre manifeste enregistré et crée ou met à jour cette politique nommée. Il ne redémarre pas l’application :
kubectl --context=labex-v135 apply -f release/stock-ingress.yaml
describe montre comment Kubernetes a interprété la règle :
kubectl --context=labex-v135 -n meadow-stock describe networkpolicy stock-ingress
Lisez le rôle de stock sélectionné, l’espace de noms source et le rôle API, ainsi que le port TCP. L’application effective de la politique peut prendre quelques secondes. Confirmez d’abord que la requête autorisée d’origine renvoie toujours les données complètes :
./tools/network-test api http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
Testez maintenant les deux raisons différentes pour lesquelles une source doit être refusée :
./tools/network-test customer http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
./tools/network-test visitor http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
Pour ces deux dernières commandes, NETWORK_TIMEOUT et un code de sortie non nul sont attendus. Customer est dans l’espace de noms approuvé, mais a le mauvais rôle ; Visitor a le rôle correspondant, mais se trouve dans le mauvais espace de noms. Un refus de connexion, une erreur DNS ou une cible arrêtée ne prouvent pas l’isolation. La requête réussie de l’API vers cette même cible est le contrôle positif. Si une requête répétée immédiatement réussit encore juste après l’application de la politique, attendez quelques secondes et répétez ; ne déclarez pas l’isolation tant que les véritables chemins refusés n’expirent pas.
Si un chemin est mal saisi, utilisez les commandes précédentes pwd, ls et cd absolu, puis répétez l’opération qui a échoué. Si le YAML ne peut pas être analysé, lisez votre fichier de publication et comparez l’indentation et la position des tirets à l’exemple complet, réécrivez ce fichier modifiable et appliquez-le à nouveau. Si l’API est aussi bloquée, examinez describe, les labels déjà affichés et le port, corrigez votre politique enregistrée et réappliquez-la. Gardez les espaces de noms, labels, charges de travail, Pods, Services, application, fichiers sources et outil de diagnostic d’origine. N’arrêtez pas le stock, ne changez pas les labels, n’utilisez pas de règles d’IP de Pod ou de CIDR, ne modifiez pas le réseau de l’hôte et ne réinitialisez pas la VM pour fabriquer un refus.
Vérifier tout le parcours client
Dans cette étape, vous vérifierez l’expérience client complète après l’isolation et garderez le service d’expédition distinct utilisable.
Commencez dans Workspace, à /home/labex/project/stock-policy. Une requête directe au stock est volontairement bloquée pour Customer, mais Customer doit toujours atteindre la Shop API. Demandez son catalogue par ce chemin d’origine :
./tools/network-test customer http http://api.meadow-shop.svc.cluster.local:8080/catalogue.json
Vous devez obtenir HTTP_REPLY 200 et les trois produits approuvés avec les prix et unités d’origine : Glass water bottle 1800 centimes / 6 unités, Everyday notebook 1400 / 4, Canvas market bag 2400 / 0. L’API indique aussi quel Pod de stock d’origine a répondu ; la page publique n’expose pas ce détail d’infrastructure. Le chemin API réussi et le chemin direct refusé sont compatibles : l’API établit sa propre connexion autorisée au stock.
Passez à Shop et rechargez. Ouvrez Glass water bottle, réglez Quantity sur 2 et sélectionnez Try a basket quote. Vous devez obtenir Ready for collection, Quantity 2, Total $36.00 et Units available 6. Lisez l’avertissement d’entraînement : aucun stock n’est réservé. Utilisez Back to product et Back to collection.
Ouvrez Canvas market bag, marqué Back soon, et essayez un devis pour Quantity 1. Vous devez obtenir Not enough stock, Total $24.00 et Units available 0. C’est une réponse métier valide, pas une panne réseau ; ne modifiez pas l’inventaire pour faire réussir chaque devis. Utilisez Back to product, puis Back to collection. Ouvrez Our approach, lisez la description des devis d’entraînement et utilisez Back to collection.
Le catalogue terminé conserve les trois produits d’origine et la disponibilité en direct ; comparez son titre, ses prix et sa disponibilité à cet exemple en fonctionnement :
Passez à Reference et rechargez. P-104 · Ready et P-108 · Packed doivent rester visibles. Sélectionnez Download notes et ouvrez le véritable téléchargement notes.json : il contient les deux enregistrements d’expédition inchangés, pas les données de stock. Le téléchargement de votre navigateur et l’espace de travail du terminal sont des emplacements distincts ; cette tâche ne vous demande pas d’y copier ce fichier.
Revenez à Workspace et lisez ce même Service distinct depuis Customer :
./tools/network-test customer http http://dispatch.meadow-stock.svc.cluster.local:8080/notes.json
Vous devez obtenir HTTP_REPLY 200 et les deux notes d’origine. La politique sélectionne les Pods d’inventaire, pas tout l’espace de noms du stock. Gardez le processus d’expédition, les données et le Service d’origine ; l’arrêter masquerait une règle trop large.
Votre livraison est release/stock-ingress.yaml et la limite d’accès active correspondante. Le catalogue complet et les deux résultats de devis doivent continuer à passer par l’application d’origine, tandis que les deux contournements directs vers le stock restent refusés. Gardez chaque fichier source préparé, objet d’application et Pod d’origine. Si une page affiche Live availability unavailable, revenez aux vérifications de labels, de politiques et de requêtes enseignées, corrigez uniquement votre politique de publication et réappliquez-la ; une page statique de remplacement n’est pas une réparation. Les tests ici sont des requêtes TCP réelles en nombre fini sur un cluster préparé, pas une garantie de sécurité en production ni de disponibilité ininterrompue.
Résumé
Vous avez préservé le véritable parcours client → API → stock tout en empêchant les lectures directes du stock par un client au mauvais rôle et par un visiteur au rôle correspondant dans un autre espace de noms. Votre politique d’entrée enregistrée exprime la relation entre espace de noms et rôle, et le catalogue actif, les devis d’entraînement et le service d’expédition distinct fonctionnent toujours.
NetworkPolicy contrôle les chemins réseau des Pods, pas l’authentification des clients. Une expiration de délai n’est une preuve utile que si la cible et la connexion approuvée fonctionnent toujours. Le prochain lab indépendant examine l’autre direction : les sorties de l’API, le DNS et les permissions apportées par d’autres politiques.
