Introduction
Meadow Supply doit afficher la disponibilité en direct et calculer des devis de panier d’entraînement par son API. Dans cet environnement indépendant, les applications d’origine fonctionnent, mais une ancienne règle de migration des sorties de l’API autorise de larges connexions TCP et a oublié le DNS. Le catalogue affiche donc une erreur de disponibilité. Réparez les dépendances requises, puis retirez les permissions inutiles de l’ancienne règle sans casser la boutique ni le service d’expédition distinct.
Utilisez les méthodes d’espace de noms, de rôle, de politique, de terminal et de requêtes réelles enseignées dans le lab guidé précédent. Ce lab explique les sorties, les exigences de protocole et de port DNS, une variable de terminal et l’union des politiques avant de les utiliser. Le véritable cluster préparé à un seul nœud contient indépendamment l’application complète et les entrées approuvées du stock ; aucun fichier ni processus de votre VM précédente n’est nécessaire. Aucune installation de cluster ni programmation d’application n’est requise. La durée est une estimation de l’auteur, pas un temps mesuré auprès de débutants. Tous les produits et notes d’expédition sont synthétiques et les devis d’entraînement ne réservent, ne commandent ni ne facturent rien.
Restaurer les dépendances requises de l’API
Dans cette étape, vous restaurerez les véritables connexions DNS et stock de la Shop API sans ouvrir toutes les destinations.
Ouvrez Shop. Le résultat complet attendu est le même catalogue Meadow Supply à trois produits qu’auparavant : Glass water bottle coûte $18.00 avec 6 unités, Everyday notebook $14.00 avec 4 et Canvas market bag $24.00 avec 0. Dans l’état initial, la page indique plutôt Live availability unavailable. Les prix restent visibles, mais l’application n’a aucune solution de repli pour le stock et ne peut produire de devis valide. C’est la panne de dépendance prévue à réparer ; ne la confondez pas avec un stock vide. Reference doit toujours afficher les deux notes d’expédition d’origine. Passez à Workspace.
L’espace de travail indépendant est /home/labex/project/stock-policy. Utilisez la même récupération de chemin qu’auparavant : pwd, ls et le cd absolu si nécessaire. Lisez le périmètre fourni :
cd /home/labex/project/stock-policy
cat scope.json
La limite d’accès entrant au stock a déjà été préparée dans cette VM. Elle autorise le rôle API dans meadow-shop ; gardez cette politique inchangée. Les connexions sortantes de l’API sont contrôlées séparément. Egress désigne le trafic quittant les Pods sélectionnés. Une politique Egress qui les sélectionne isole ces Pods pour cette direction, et l’union de toutes les règles de sortie applicables détermine ce qui peut sortir. Le trafic de réponse à une connexion autorisée est implicitement autorisé.
Lisez la politique de migration existante dans l’espace de noms de l’API :
kubectl --context=labex-v135 -n meadow-shop get networkpolicies
kubectl --context=labex-v135 -n meadow-shop describe networkpolicy legacy-egress
legacy-egress sélectionne role=shop-api et autorise le port TCP 8080 vers toute destination. Elle n’incluait pas le DNS. CoreDNS est le service de noms préparé du cluster. Un nom de Service nécessite une requête DNS avant qu’une connexion HTTP puisse utiliser son adresse. DNS (Domain Name System) traduit les noms en adresses. UDP (User Datagram Protocol) envoie des datagrammes individuels ; TCP (Transmission Control Protocol) établit des connexions. Le service DNS de ce cluster accepte les deux sur le port 53 ; les deux chemins vers les Pods DNS dans kube-system sont donc requis.
Le mode dns de l’outil de diagnostic fourni envoie une nouvelle requête DNS UDP au résolveur de ce Pod ; dns-tcp envoie une nouvelle requête TCP. Aucun ne dépend d’un résultat d’application en cache. Testez la véritable identité API :
./tools/network-test api dns stock.meadow-stock.svc.cluster.local
./tools/network-test api dns-tcp stock.meadow-stock.svc.cluster.local
Les deux doivent signaler NETWORK_TIMEOUT et un code de sortie non nul. Ces échecs attendus concernent la connexion DNS. Pour les distinguer d’un processus de stock arrêté, effectuez une requête de diagnostic explicite vers l’adresse du Service de stock d’origine.
L’affectation suivante capture la sortie d’une commande avec $(...) dans la variable shell stock_ip. -o jsonpath='{.spec.clusterIP}' sélectionne uniquement le champ spec.clusterIP du Service ; les apostrophes gardent l’expression ensemble. Cette variable appartient à la session de terminal Workspace actuelle. C’est une valeur de diagnostic, pas une cible de politique ni une adresse permanente de Pod. Si vous vous reconnectez à un nouveau shell, répétez l’affectation avant de l’utiliser.
stock_ip=$(kubectl --context=labex-v135 -n meadow-stock get service stock -o jsonpath='{.spec.clusterIP}')
printf affiche la chaîne capturée ; %s signifie une chaîne et \n termine la ligne. Les guillemets doubles préservent la valeur développée comme un seul argument :
printf '%s\n' "$stock_ip"
${stock_ip} développe cette variable dans l’URL de requête. La règle TCP large existante autorise cette connexion sans nécessiter le DNS :
./tools/network-test api http "http://${stock_ip}:8080/stock.json"
Vous devez obtenir HTTP_REPLY 200 et les enregistrements de stock d’origine. L’accès TCP existe ; la résolution du nom est une dépendance distincte. Ne mettez jamais cette adresse dans la politique finale : utilisez les relations stables d’espace de noms et de rôle.
Examinez les véritables labels DNS avant de les sélectionner. -l k8s-app=kube-dns sélectionne les Pods DNS préparés :
kubectl --context=labex-v135 get namespace kube-system --show-labels
kubectl --context=labex-v135 -n kube-system get pods -l k8s-app=kube-dns --show-labels
Créez votre propre politique api-egress. Elle sélectionne le rôle API. Ses deux règles to sont des alternatives : DNS dans kube-system sur UDP/TCP 53, ou inventaire dans meadow-stock sur TCP 8080. Dans chaque pair individuel, les sélecteurs d’espace de noms et de Pod se combinent avec ET. Les ports de chaque règle s’appliquent uniquement aux destinations de cette règle.
mkdir -p conserve un répertoire de publication existant. Comme enseigné auparavant, le here-document à marqueur entre apostrophes et > écrivent uniquement votre fichier de publication modifiable :
mkdir -p release
cat > release/api-egress.yaml <<'YAML'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: api-egress
namespace: meadow-shop
spec:
podSelector:
matchLabels:
role: shop-api
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
podSelector:
matchLabels:
k8s-app: kube-dns
ports:
- protocol: UDP
port: 53
- protocol: TCP
port: 53
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: meadow-stock
podSelector:
matchLabels:
role: inventory
ports:
- protocol: TCP
port: 8080
YAML
Lisez, appliquez et examinez le manifeste enregistré :
cat release/api-egress.yaml
kubectl --context=labex-v135 apply -f release/api-egress.yaml
kubectl --context=labex-v135 -n meadow-shop describe networkpolicy api-egress
Confirmez les deux véritables transports DNS et la connexion au stock par son nom. L’application effective peut prendre quelques secondes après un apply ; répétez une requête après une courte attente si la limite d’accès précédente est encore visible.
./tools/network-test api dns stock.meadow-stock.svc.cluster.local
./tools/network-test api dns-tcp stock.meadow-stock.svc.cluster.local
./tools/network-test api http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
Vous devez obtenir DNS_REPLY UDP, DNS_REPLY TCP, puis HTTP_REPLY 200 avec toutes les données de stock d’origine. Passez à Shop et rechargez. La disponibilité en direct doit revenir. Ouvrez Glass water bottle, sélectionnez Quantity 2 et utilisez Try a basket quote. Vous devez obtenir Ready for collection, un total de $36.00 et 6 unités disponibles, avec l’avertissement d’entraînement sans réservation. Revenez par Back to product et Back to collection.
Comparez le catalogue en direct restauré à ce véritable résultat en fonctionnement :
Cela termine la réparation des connexions requises, mais ne prouve pas encore que les destinations sans rapport sont refusées. Une autre politique peut encore ajouter des permissions. Continuez à l’étape suivante avant de considérer cette limite d’accès comme finale.
Pour une faute de saisie, revenez avec pwd, ls et le cd absolu. Pour un manifeste mal formé ou une requête de dépendance en échec, lisez votre fichier enregistré, la sortie de describe et les véritables labels et ports enseignés, corrigez le fichier et réappliquez-le. DNS_REPLY est un résultat de service de noms ; HTTP_REPLY est une réponse d’application ; NETWORK_TIMEOUT signifie aucune réponse dans le délai réseau préparé ; CONNECTION_REFUSED indique une destination qui a refusé la connexion. Le REQUEST_TIMEOUT borné de l’outil inclut toute la requête et le DNS. Un échec générique ne démontre pas une politique correcte. Ne modifiez pas le code de l’application, les labels, les fichiers sources, les Pods d’origine, les entrées du stock, les Services, le réseau de l’hôte ni l’infrastructure DNS.
Retirer l’ancienne permission trop large
Dans cette étape, vous retirerez l’autorisation inutile de l’ancienne politique de migration tout en préservant le parcours client réparé et le service d’expédition distinct.
Commencez dans Workspace, à /home/labex/project/stock-policy. Votre nouvelle politique autorise uniquement le DNS et le stock. Testez le service d’expédition sans rapport depuis l’API :
./tools/network-test api http http://dispatch.meadow-stock.svc.cluster.local:8080/notes.json
Il renvoie actuellement HTTP_REPLY 200 et les deux notes d’expédition. Cette réussite révèle une permission excessive ; la Shop API n’a pas besoin d’accéder à l’expédition. La nouvelle politique étroite ne remplace pas la politique large existante. Les NetworkPolicies additionnent les connexions autorisées, quel que soit leur ordre d’application. Pour qu’une connexion fonctionne, les sorties de la source et les entrées de la destination doivent toutes deux l’autoriser.
Listez à nouveau les deux politiques, puis lisez la politique de migration gérée et sa source d’origine :
kubectl --context=labex-v135 -n meadow-shop get networkpolicies
kubectl --context=labex-v135 -n meadow-shop describe networkpolicy legacy-egress
cat starter/legacy-egress.yaml
L’ancienne règle autorise le port TCP 8080 sans restriction de destination to. Cette permission s’applique toujours aux Pods API sélectionnés. Dans cette publication, gardez l’objet géré d’origine legacy-egress et retirez ses permissions sur place. Enregistrez-le avec aucune entrée d’autorisation de sortie, représentée par la liste vide egress: []. Votre politique distincte api-egress continue à fournir les deux connexions requises. Gardez le fichier de départ en lecture seule inchangé.
cat > release/legacy-egress.yaml <<'YAML'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: legacy-egress
namespace: meadow-shop
spec:
podSelector:
matchLabels:
role: shop-api
policyTypes:
- Egress
egress: []
YAML
Lisez et appliquez la politique gérée enregistrée. Ne la supprimez pas pour la recréer :
cat release/legacy-egress.yaml
kubectl --context=labex-v135 apply -f release/legacy-egress.yaml
kubectl --context=labex-v135 -n meadow-shop describe networkpolicy legacy-egress
Elle doit toujours sélectionner le rôle API, mais n’apporter aucune autorisation sortante. Votre répertoire de publication final contient les deux politiques enregistrées. La politique d’entrée du stock préparée reste inchangée.
La requête de l’API vers l’expédition sans rapport doit maintenant expirer, tandis que la requête de contrôle du client vers ce service exact réussit toujours :
./tools/network-test api http http://dispatch.meadow-stock.svc.cluster.local:8080/notes.json
./tools/network-test customer http http://dispatch.meadow-stock.svc.cluster.local:8080/notes.json
Vous devez obtenir NETWORK_TIMEOUT avec un code de sortie non nul pour API, puis HTTP_REPLY 200 avec les deux notes inchangées pour Customer. Cette paire empêche un service arrêté de se faire passer pour une isolation correcte. Si la requête API réussit encore immédiatement après l’application, attendez quelques secondes et répétez jusqu’à observer la véritable nouvelle limite d’accès.
Confirmez à nouveau le chemin de stock approuvé et les deux protocoles DNS :
./tools/network-test api http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
./tools/network-test api dns stock.meadow-stock.svc.cluster.local
./tools/network-test api dns-tcp stock.meadow-stock.svc.cluster.local
Passez à Shop, rechargez et répétez le devis de Glass water bottle pour Quantity 2 : Ready for collection, $36.00, 6 unités. Demandez ensuite un devis de Canvas market bag, Quantity 1 : Not enough stock, $24.00, 0 unité. Revenez à la collection et ouvrez Our approach pour confirmer le périmètre d’entraînement. Passez à Reference et rechargez ; les deux notes de retrait d’origine restent présentes. Utilisez Download notes et examinez le véritable téléchargement de deux enregistrements. Ce téléchargement de navigateur est distinct de l’espace de travail du terminal et n’a pas besoin d’y être copié.
Votre livraison est release/api-egress.yaml et release/legacy-egress.yaml, appliqués aux identités de politiques d’origine. Les permissions actives et enregistrées doivent correspondre aux limites d’espace de noms/rôle et de protocole/port enseignées : DNS UDP/TCP 53 et stock TCP 8080, l’ancienne politique n’apportant aucune autorisation. Gardez toutes les ressources d’application d’origine, les Pods, les labels d’espace de noms, les données et les sources fournies. Si une correction casse la boutique, examinez les chemins DNS et stock enseignés, corrigez uniquement les fichiers de politique modifiables et appliquez-les à nouveau. N’ajoutez pas une autre règle autorisant tout et ne changez pas l’application pour contourner le DNS. Ces observations TCP/UDP finies ne prouvent pas une limite de sécurité réseau en production face aux nœuds ou aux administrateurs.
Résumé
Vous avez distingué la résolution de noms d’une connexion d’application, restauré les véritables dépendances DNS et stock de l’API et gardé les devis client en direct fonctionnels. Vous avez aussi découvert pourquoi une politique étroite ne retirait pas une permission fournie par une autre politique, puis retiré cette ancienne autorisation sans arrêter le service sans rapport avec l’API.
La publication finale enregistrée et l’union des politiques actives autorisent les chemins DNS et stock requis tout en refusant l’accès de l’API à l’expédition. L’ordre des politiques ne constitue pas une priorité ; évaluez les permissions combinées et préservez les contrôles positifs pour interpréter les échecs.
