Einführung
Meadow Supply soll aktuelle Verfügbarkeit anzeigen und über seine API Warenkorb-Kalkulationen zu Übungszwecken berechnen. In dieser unabhängigen Umgebung laufen die ursprünglichen Anwendungen, doch eine alte Migrationsregel für ausgehenden API-Verkehr erlaubt weitreichende TCP-Verbindungen und hat DNS vergessen. Der Katalog zeigt deshalb einen Verfügbarkeitsfehler. Repariere die erforderlichen Abhängigkeiten und entferne anschließend die unnötigen Berechtigungen der alten Regel, ohne den Shop oder den separaten Versandservice zu beeinträchtigen.
Verwende die im vorherigen geführten Lab erklärten Methoden für Namespaces, Rollen, Richtlinien, Terminal und echte Anfragen. Dieses Lab erklärt ausgehenden Verkehr, DNS-Anforderungen an Protokolle und Ports, eine Terminalvariable und die Vereinigung von Richtlinienberechtigungen, bevor du sie verwendest. Der vorbereitete echte Einzelknoten-Cluster enthält unabhängig die vollständige Anwendung und die freigegebene Bestands-Ingress-Richtlinie; Dateien oder Prozesse aus deiner vorherigen VM werden nicht benötigt. Weder Clusterinstallation noch Anwendungsprogrammierung sind erforderlich. Die Dauer ist eine Schätzung des Autors und keine bei Anfängern gemessene Zeit. Alle Produkte und Versandhinweise sind synthetisch, und Übungskalkulationen lösen weder Reservierungen noch Bestellungen oder Zahlungen aus.
Die erforderlichen API-Abhängigkeiten wiederherstellen
In diesem Schritt stellst du echte DNS- und Bestandsverbindungen für die Shop API wieder her, ohne jedes Ziel zu öffnen.
Öffne Shop. Das erwartete vollständige Ergebnis ist derselbe Katalog von Meadow Supply mit drei Produkten wie zuvor: Glass water bottle kostet $18.00 bei 6 Einheiten, Everyday notebook $14.00 bei 4 und Canvas market bag $24.00 bei 0. Im Ausgangszustand zeigt die Seite stattdessen Live availability unavailable. Preise bleiben sichtbar, doch die Anwendung hat keinen Ersatzbestand und kann keine gültige Kalkulation erzeugen. Dies ist der beabsichtigte Abhängigkeitsfehler, den du beheben sollst; verwechsle ihn nicht mit einem leeren Bestand. Reference sollte weiterhin die beiden ursprünglichen Versandhinweise zeigen. Wechsle zu Workspace.
Der unabhängige Arbeitsbereich ist /home/labex/project/stock-policy. Verwende dieselbe Pfadkorrektur wie zuvor: pwd, ls und bei Bedarf das absolute cd. Lies den bereitgestellten Arbeitsumfang:
cd /home/labex/project/stock-policy
cat scope.json
Die Bestands-Ingress-Grenze ist in dieser VM bereits vorbereitet. Sie erlaubt die API-Rolle in meadow-shop; lasse diese Richtlinie unverändert. Die ausgehenden Verbindungen der API werden getrennt gesteuert. Egress bedeutet Verkehr, der ausgewählte Pods verlässt. Eine auswählende Egress-Richtlinie isoliert diese Pods in dieser Richtung, und die Vereinigung aller zutreffenden Egress-Regeln bestimmt, was sie verlassen darf. Antwortverkehr für eine erlaubte Verbindung ist implizit erlaubt.
Lies die vorhandene Migrationsrichtlinie im API-Namespace:
kubectl --context=labex-v135 -n meadow-shop get networkpolicies
kubectl --context=labex-v135 -n meadow-shop describe networkpolicy legacy-egress
legacy-egress wählt role=shop-api aus und erlaubt TCP-Port 8080 zu jedem Ziel. DNS war nicht enthalten. CoreDNS ist der vorbereitete Namensdienst des Clusters. Ein Service-Name benötigt eine DNS-Abfrage, bevor eine HTTP-Verbindung seine Adresse verwenden kann. DNS (Domain Name System) übersetzt Namen in Adressen. UDP (User Datagram Protocol) sendet einzelne Datagramme; TCP (Transmission Control Protocol) baut Verbindungen auf. Der DNS-Service dieses Clusters akzeptiert beides auf Port 53, deshalb sind beide Pfade zu den DNS-Pods in kube-system erforderlich.
Der Modus dns des bereitgestellten Diagnosewerkzeugs sendet eine neue UDP-DNS-Abfrage an den Resolver in diesem Pod; dns-tcp sendet eine neue TCP-Abfrage. Keiner verlässt sich auf ein zwischengespeichertes Anwendungsergebnis. Prüfe die tatsächliche API-Identität:
./tools/network-test api dns stock.meadow-stock.svc.cluster.local
./tools/network-test api dns-tcp stock.meadow-stock.svc.cluster.local
Beide sollten NETWORK_TIMEOUT und einen Exit-Status ungleich null melden. Diese erwarteten Fehlschläge betreffen die DNS-Verbindung. Um sie von einem gestoppten Bestandsprozess zu unterscheiden, sende eine ausdrückliche Diagnoseanfrage an die ursprüngliche Bestands-Service-Adresse.
Die folgende Zuweisung erfasst die Ausgabe eines Befehls mit $(...) in der Shell-Variablen stock_ip. -o jsonpath='{.spec.clusterIP}' wählt ausschließlich das Feld spec.clusterIP des Services; Anführungszeichen halten den Ausdruck zusammen. Diese Variable gehört zur aktuellen Terminalsitzung von Workspace. Sie ist ein Diagnosewert, kein Richtlinienziel und keine dauerhafte Pod-Adresse. Falls du dich mit einer neuen Shell verbindest, wiederhole die Zuweisung, bevor du sie verwendest.
stock_ip=$(kubectl --context=labex-v135 -n meadow-stock get service stock -o jsonpath='{.spec.clusterIP}')
printf gibt die erfasste Zeichenfolge aus; %s bedeutet eine Zeichenfolge und \n beendet die Zeile. Doppelte Anführungszeichen erhalten den expandierten Wert als ein einzelnes Argument:
printf '%s\n' "$stock_ip"
${stock_ip} expandiert diese Variable innerhalb der Anfrage-URL. Die vorhandene weit gefasste TCP-Regel erlaubt diese Verbindung ohne DNS:
./tools/network-test api http "http://${stock_ip}:8080/stock.json"
Erwarte HTTP_REPLY 200 und die ursprünglichen Bestandsdatensätze. TCP-Zugriff besteht; das Auflösen des Namens ist eine separate Abhängigkeit. Trage diese Adresse niemals in die fertige Richtlinie ein: Verwende die stabilen Beziehungen aus Namespace und Rolle.
Untersuche die echten DNS-Labels, bevor du sie auswählst. -l k8s-app=kube-dns wählt die vorbereiteten DNS-Pods aus:
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
Erstelle deine eigene Richtlinie api-egress. Sie wählt die API-Rolle aus. Ihre beiden Regeln to sind Alternativen: DNS in kube-system auf UDP/TCP 53 oder Bestand in meadow-stock auf TCP 8080. Innerhalb jedes einzelnen Kommunikationspartners sind Namespace- und Pod-Selektoren mit UND verknüpft. Die Ports jeder Regel gelten nur für die Ziele dieser Regel.
mkdir -p behält ein vorhandenes Release-Verzeichnis bei. Wie zuvor erklärt, schreiben das Here-Dokument mit Anführungszeichen und > nur deine bearbeitbare Release-Datei:
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
Lies das gespeicherte Manifest, wende es an und untersuche es:
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
Bestätige beide echten DNS-Transportarten und die Bestandsverbindung über den Namen. Die Durchsetzung kann nach dem Anwenden einige Sekunden dauern; wiederhole eine Anfrage nach kurzer Wartezeit, falls die vorherige Grenze noch sichtbar ist.
./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
Erwarte DNS_REPLY UDP, DNS_REPLY TCP und dann HTTP_REPLY 200 mit allen ursprünglichen Bestandsdaten. Wechsle zu Shop und lade die Seite neu. Die aktuelle Verfügbarkeit sollte zurückkehren. Öffne Glass water bottle, wähle Quantity 2 und verwende Try a basket quote. Erwarte Ready for collection, die Summe $36.00 und 6 verfügbare Einheiten zusammen mit dem Übungshinweis, dass keine Reservierung erfolgt. Kehre über Back to product und Back to collection zurück.
Vergleiche den wiederhergestellten aktuellen Katalog mit diesem tatsächlichen laufenden Ergebnis:
Damit ist die erforderliche Verbindungsreparatur abgeschlossen; es ist aber noch nicht bewiesen, dass andere Ziele verweigert werden. Eine andere Richtlinie kann weiterhin Berechtigungen hinzufügen. Fahre mit dem nächsten Schritt fort, bevor du dies als endgültige Grenze betrachtest.
Kehre bei einem Tippfehler mit pwd, ls und dem absoluten cd zurück. Lies bei einem fehlerhaften Manifest oder einer fehlgeschlagenen Abhängigkeitsanfrage deine gespeicherte Datei, die Ausgabe von describe und die erklärten echten Labels/Ports, korrigiere die Datei und wende sie erneut an. DNS_REPLY ist ein Namensdienstergebnis; HTTP_REPLY ist eine Anwendungsantwort; NETWORK_TIMEOUT bedeutet, dass innerhalb der vorbereiteten Netzwerkwartezeit keine Antwort kam; CONNECTION_REFUSED kennzeichnet ein Ziel, das die Verbindung verweigert hat. Der begrenzte REQUEST_TIMEOUT des Werkzeugs umfasst die gesamte Anfrage einschließlich DNS. Ein allgemeiner Fehlschlag belegt keine korrekte Richtlinie. Ändere weder Anwendungscode, Labels, Quelldateien, ursprüngliche Pods, Bestands-Ingress, Services, Host-Netzwerk noch DNS-Infrastruktur.
Die alte weitreichende Berechtigung entfernen
In diesem Schritt entfernst du die unnötige Erlaubnis der alten Migrationsrichtlinie und erhältst dabei den reparierten Kundenablauf und den separaten Versandservice.
Beginne in Workspace unter /home/labex/project/stock-policy. Deine neue Richtlinie erlaubt ausschließlich DNS und Bestand. Prüfe den nicht benötigten Versandservice aus der API-Identität:
./tools/network-test api http http://dispatch.meadow-stock.svc.cluster.local:8080/notes.json
Derzeit gibt er HTTP_REPLY 200 und die beiden Versandhinweise zurück. Dieser Erfolg deckt eine zu weit reichende Berechtigung auf; die Shop API benötigt keinen Versandzugriff. Die neue enge Richtlinie setzt die bestehende weit gefasste nicht außer Kraft. NetworkPolicies vereinigen erlaubte Verbindungen unabhängig von der Anwendungsreihenfolge. Damit eine Verbindung funktioniert, müssen sowohl der ausgehende Verkehr der Quelle als auch der eingehende Verkehr des Ziels sie erlauben.
Liste beide Richtlinien erneut auf und lies dann die verwaltete Migrationsrichtlinie und ihre ursprüngliche Quelle:
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
Die alte Regel erlaubt TCP-Port 8080 ohne eine Zieleinschränkung durch to. Diese Berechtigung gilt weiterhin für die ausgewählten API-Pods. Behalte in diesem Release das ursprüngliche verwaltete Objekt legacy-egress bei und entferne seine Berechtigungen direkt am bestehenden Objekt. Speichere es ohne Egress-Erlaubniseinträge, dargestellt durch die leere Liste egress: []. Deine separate Richtlinie api-egress stellt weiterhin die beiden erforderlichen Verbindungen bereit. Lasse die schreibgeschützte Startdatei unverändert.
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
Lies die gespeicherte verwaltete Richtlinie und wende sie an. Lösche sie nicht, um sie neu anzulegen:
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
Sie sollte weiterhin die API-Rolle auswählen, aber keine Erlaubnis für ausgehenden Verkehr beitragen. Dein endgültiges Release-Verzeichnis enthält beide gespeicherten Richtlinien. Die vorbereitete Bestands-Ingress-Richtlinie bleibt unverändert.
Nun muss die nicht benötigte Versandanfrage der API in eine Zeitüberschreitung laufen, während die Kontrollanfrage des Kunden an genau denselben Service weiterhin erfolgreich ist:
./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
Erwarte NETWORK_TIMEOUT mit einem Exit-Status ungleich null für API und dann HTTP_REPLY 200 mit beiden unveränderten Hinweisen für Customer. Dieses Paar verhindert, dass sich ein gestoppter Service als korrekte Isolation ausgibt. Falls die API-Anfrage unmittelbar nach dem Anwenden noch erfolgreich ist, warte einige Sekunden und wiederhole sie, bis die tatsächliche neue Grenze beobachtet wird.
Bestätige den freigegebenen Bestandspfad und beide DNS-Protokolle erneut:
./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
Wechsle zu Shop, lade die Seite neu und wiederhole die Kalkulation für Glass water bottle mit Quantity 2: Ready for collection, $36.00, 6 Einheiten. Berechne dann für Canvas market bag, Quantity 1: Not enough stock, $24.00, 0 Einheiten. Kehre zur Kollektion zurück und öffne Our approach, um den Übungsumfang zu bestätigen. Wechsle zu Reference und lade die Seite neu; beide ursprünglichen Abholhinweise bleiben erhalten. Verwende Download notes und untersuche den tatsächlichen Download mit zwei Datensätzen. Dieser Browserdownload ist vom Terminalarbeitsbereich getrennt und muss nicht dorthin kopiert werden.
Deine Übergabe besteht aus release/api-egress.yaml und release/legacy-egress.yaml, angewendet auf die ursprünglichen Richtlinienidentitäten. Sowohl wirksame als auch gespeicherte Berechtigungen müssen den erklärten Namespace-/Rollen- und Protokoll-/Portgrenzen entsprechen: DNS UDP/TCP 53 und Bestand TCP 8080, wobei die alte Richtlinie keine Erlaubnis beiträgt. Behalte alle ursprünglichen Anwendungsressourcen, Pods, Namespace-Labels, Daten und bereitgestellten Quellen bei. Falls eine Korrektur den Shop beeinträchtigt, untersuche die erklärten DNS- und Bestandspfade, korrigiere nur die bearbeitbaren Richtliniendateien und wende sie erneut an. Füge keine weitere pauschale Erlaubnisregel hinzu und ändere die Anwendung nicht, um DNS zu umgehen. Diese endlich vielen TCP-/UDP-Beobachtungen beweisen keine Produktionsnetzwerk-Sicherheitsgrenze gegenüber Knoten oder Administratoren.
Zusammenfassung
Du hast die Namensauflösung von einer Anwendungsverbindung getrennt, die echten DNS- und Bestandsabhängigkeiten der API wiederhergestellt und die laufenden Warenkorb-Kalkulationen funktionsfähig gehalten. Außerdem hast du herausgefunden, warum eine enge Richtlinie eine durch eine andere Richtlinie bereitgestellte Berechtigung nicht entfernt, und anschließend diese alte Erlaubnis entfernt, ohne den unabhängigen Service anzuhalten.
Das endgültige gespeicherte Release und die Vereinigung der wirksamen Richtlinien erlauben die erforderlichen DNS- und Bestandspfade und verweigern gleichzeitig den API-Zugriff auf den Versand. Die Richtlinienreihenfolge schafft keinen Vorrang; bewerte die kombinierten Berechtigungen und erhalte Positivkontrollen, wenn du Fehlschläge interpretierst.
