Einführung
Meadow Supply hat einen kleinen Katalog und eine funktionierende Warenkorb-Kalkulation. Seine öffentliche Seite fragt die Shop API nach der Verfügbarkeit. API bedeutet Application Programming Interface, also Programmierschnittstelle: Hier ist sie die Anfrageschnittstelle der Anwendung zwischen der Kundenseite und dem internen Bestandsservice. Diese API liest den Bestand für die Seite. Derzeit können auch der Kundenprozess und ein separater Besucher den Bestand direkt lesen, einschließlich Regaldetails, die der öffentliche Katalog nicht benötigt.
Halte den normalen Kundenablauf funktionsfähig und beschränke gleichzeitig Bestandsverbindungen auf die freigegebene API-Rolle im freigegebenen Namespace. Dein wiederverwendbares Ergebnis ist eine gespeicherte NetworkPolicy mit der entsprechenden wirksamen Grenze, belegt durch echte Anfragen statt durch ein grünes Diagramm.
Du solltest grundlegende Terminalpfade, einfaches YAML, Namespaces, Pods, Deployments, Services und Labels bereits kennen. Dieses Lab erklärt die Richtlinienfelder, den bereitgestellten Diagnosebefehl und die Anfrageergebnisse, bevor sie verwendet werden. Ein echter Kubernetes-Einzelknoten-Cluster mit Calico, die Anwendung und synthetische Daten sind vorbereitet. Weder Clusterinstallation noch Imagebau oder Anwendungsprogrammierung sind erforderlich. Die Dauer ist eine Schätzung des Autors einschließlich Lesen und gewöhnlicher Fehler. Dies sind Übungskalkulationen: Es findet weder eine Bestellung noch eine Reservierung oder Zahlung statt.
Den Bestand auf den freigegebenen Zugriffspfad beschränken
In diesem Schritt erlaubst du der Shop API den Zugriff auf den Bestand und verhinderst zugleich, dass Kunden- und Besucherprozesse sie umgehen.
Beginne im Tab Shop. Meadow Supply sollte Good things for everyday und drei Produkte zeigen. Öffne Glass water bottle, beachte den Preis von $18.00 und Available · 6 in stock und wähle dann Try a basket quote, wobei Quantity auf 1 gesetzt ist. Das Ergebnis sollte Ready for collection anzeigen, $18.00 ausweisen und ausdrücklich erklären, dass nichts reserviert, bestellt oder bezahlt wurde. Verwende Back to product und dann Back to collection.
Der echte Anfragepfad lautet:
Kundenseite → Shop API → Bestandsservice
Die Kundenseite läuft in einem eigenen Pod. Das Öffnen der Website macht deinen Browser nicht zu einem Cluster-Pod; Anfragen an den Bestand kommen von den vorbereiteten Anwendungsprozessen. Die API liest den Bestand über eine neue Netzwerkverbindung und kombiniert ihn mit den freigegebenen Katalogpreisen. Sie hat keinen statischen Ersatzbestand. Ein separater Tab Reference zeigt Abholhinweise von Meadow Dispatch. Öffne ihn, lies P-104 und P-108 und wechsle dann zu Workspace. Dieser separate Service muss weiter funktionieren.
Das Terminal startet in /home/labex/project/stock-policy. pwd gibt das aktuelle Verzeichnis aus; ls listet seine Einträge auf. Verwende den absoluten Befehl cd, falls du hierher zurückkehren musst:
pwd
ls
cd /home/labex/project/stock-policy
Erwarte scope.json, starter und tools. cat gibt die vorbereitete Datei zum Arbeitsumfang aus. Sie verwendet JSON (JavaScript Object Notation), ein Textformat aus benannten Werten und Listen. Sie nennt tatsächliche Ressourcennamen und Anfrageziele statt eines erfundenen Topologiezustands:
cat scope.json
--context=labex-v135 wählt den vorbereiteten echten Cluster aus. --show-labels zeigt Objektlabels an. Ein Namespace fasst Objekte zusammen, blockiert aber für sich allein keine Netzwerkverbindungen zwischen ihnen. Lies die Namespace-Identitäten:
kubectl --context=labex-v135 get namespaces meadow-shop meadow-stock meadow-visitors --show-labels
Jeder hat ein eingebautes Label kubernetes.io/metadata.name, dessen Wert seinem Namen entspricht. -n wählt einen Namespace aus. Lies die Pods und ihre 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
Der Kundenprozess hat role=customer, die API hat role=shop-api, und der Bestand hat role=inventory. Der separate Versandservice hat role=dispatch. Der Besucher befindet sich in meadow-visitors, hat aber absichtlich dasselbe Label role=shop-api wie die echte API. Ein Rollenlabel allein kennzeichnet deshalb keinen freigegebenen Namespace.
Lies die Services. Ein Service wählt die vorbereiteten Pods aus und stellt eine stabile Adresse bereit. Ein Port kennzeichnet den Empfangsendpunkt einer Anwendung. TCP (Transmission Control Protocol) stellt die für diese Webanfragen verwendete Verbindung bereit; der Bestandsprozess lauscht auf TCP-Port 8080:
kubectl --context=labex-v135 -n meadow-stock get services
Das bereitgestellte ./tools/network-test führt mithilfe von kubectl exec eine echte Anfrage aus einer bestehenden Anwendungsidentität aus. Das vorangestellte ./ bedeutet, dass sich das Werkzeug im aktuellen Verzeichnis befindet. Sein erstes Argument wählt customer, api, visitor, stock oder reference; das nächste wählt http, dns oder dns-tcp; das letzte ist das Ziel. Es ändert niemals Richtlinien und repariert die Anwendung nicht. Anfragen mit http verwenden HTTP (Hypertext Transfer Protocol), das Anfrage-Antwort-Protokoll für diese Web-/API-Endpunkte. Der vollständige Name stock.meadow-stock.svc.cluster.local kennzeichnet den Bestands-Service in seinem Namespace über das Cluster-DNS (Domain Name System), das Service-Namen in Adressen auflöst.
Stelle zunächst die aktuelle Verbindung und den Inhalt fest. Beide Anfragen sollen vor der Isolation erfolgreich sein:
./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
Erwarte HTTP_REPLY 200, gefolgt von denselben Bestandsdaten: bottle hat 6 Einheiten auf Regal M-03, notebook hat 4 auf M-08, und bag hat 0 auf M-12. Der Kunde sollte die öffentliche Verfügbarkeit über die API erhalten und diesen internen Lesezugriff nicht direkt ausführen. Der Ausgangstest beweist, dass das Ziel funktioniert, bevor du den Zugriff einschränkst.
Eine NetworkPolicy wählt Pods aus und erlaubt bestimmte Verbindungen für eine Verkehrsrichtung. Ingress bedeutet Verbindungen, die bei ausgewählten Pods eingehen. Sobald eine Ingress-Richtlinie den Bestand auswählt, bleiben nur ihre erlaubten eingehenden Pfade verfügbar, abgesehen von den dokumentierten Kubernetes-Ausnahmen für Knotenverkehr und Verkehr eines Pods zu sich selbst. Dies ist Pod-Netzwerkkontrolle und keine Benutzerauthentifizierung oder HTTP-Autorisierung.
Erstelle dein Release-Verzeichnis. mkdir -p erstellt es bei Bedarf und behält ein vorhandenes Verzeichnis bei. Der folgende Befehl cat schreibt die vollständige Richtlinie in deine eigene Release-Datei: > leitet die Ausgabe in diese Datei um, und die Markierung YAML in Anführungszeichen hält den Text bis zur abschließenden, allein stehenden Markierung wörtlich. Eine Wiederholung ersetzt nur diese bearbeitbare Richtliniendatei.
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
Lies die gespeicherte Datei vor dem Anwenden:
cat release/stock-ingress.yaml
Der äußere podSelector wählt nur den Bestand aus und lässt den Versand außerhalb dieser Richtlinie. Innerhalb des einen Eintrags from müssen namespaceSelector und podSelector beide zutreffen: Die Quelle muss in meadow-shop liegen und role=shop-api haben. Die beiden Selektoren sind unter demselben Listeneintrag ausgerichtet. Ein weiterer Bindestrich vor dem inneren podSelector würde eine zweite Alternative erzeugen, also ODER bedeuten, und andere Pods im freigegebenen Namespace zulassen. Der Port ist der TCP-Empfangsport des Bestands-Pods. Diese Regel beschränkt den ausgehenden API-Verkehr nicht.
apply -f liest dein gespeichertes Manifest und erstellt oder aktualisiert diese benannte Richtlinie. Es startet die Anwendung nicht neu:
kubectl --context=labex-v135 apply -f release/stock-ingress.yaml
describe zeigt, wie Kubernetes die Regel interpretiert hat:
kubectl --context=labex-v135 -n meadow-stock describe networkpolicy stock-ingress
Lies die ausgewählte Bestandsrolle, den Quell-Namespace und die API-Rolle sowie den TCP-Port. Die Durchsetzung der Richtlinie kann einige Sekunden benötigen, bis sie vollständig wirksam ist. Bestätige zuerst, dass die ursprünglich erlaubte Anfrage weiterhin die vollständigen Daten zurückgibt:
./tools/network-test api http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
Prüfe nun die beiden unterschiedlichen Gründe, aus denen einer Quelle der Zugriff verweigert werden muss:
./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
Für diese letzten beiden Befehle werden NETWORK_TIMEOUT und ein Exit-Status ungleich null erwartet. Customer liegt im freigegebenen Namespace, hat aber die falsche Rolle; Visitor hat die passende Rolle, liegt aber im falschen Namespace. Eine verweigerte Verbindung, ein DNS-Fehler oder ein gestopptes Ziel beweisen keine Isolation. Die erfolgreiche API-Anfrage an dasselbe Ziel ist die Positivkontrolle. Falls eine unmittelbar wiederholte Anfrage kurz nach dem Anwenden der Richtlinie noch erfolgreich ist, warte einige Sekunden und wiederhole sie; erkläre die Isolation erst dann für wirksam, wenn die tatsächlich verweigerten Pfade in eine Zeitüberschreitung laufen.
Verwende bei einem Tippfehler im Pfad die früheren Befehle pwd, ls und das absolute cd und wiederhole dann die fehlgeschlagene Operation. Falls YAML nicht geparst werden kann, lies deine Release-Datei und vergleiche Einrückung und Bindestrichplatzierung mit dem vollständigen Beispiel, schreibe diese bearbeitbare Datei erneut und wende sie wieder an. Falls auch die API blockiert ist, untersuche describe sowie die bereits angezeigten Labels und den Port, korrigiere deine gespeicherte Richtlinie und wende sie erneut an. Behalte die ursprünglichen Namespaces, Labels, Workloads, Pods, Services, die Anwendung, Quelldateien und das Diagnosewerkzeug bei. Stoppe den Bestand nicht, ändere keine Labels, verwende keine Pod-IP-/CIDR-Regeln, ändere das Host-Netzwerk nicht und setze die VM nicht zurück, um eine Zugriffsverweigerung künstlich herzustellen.
Den gesamten Kundenablauf prüfen
In diesem Schritt prüfst du das vollständige Kundenerlebnis nach der Isolation und hältst den separaten Versandservice nutzbar.
Beginne in Workspace unter /home/labex/project/stock-policy. Eine direkte Bestandsanfrage ist für Customer absichtlich blockiert, Customer muss aber weiterhin die Shop API erreichen können. Fordere ihren Katalog über diesen ursprünglichen Pfad an:
./tools/network-test customer http http://api.meadow-shop.svc.cluster.local:8080/catalogue.json
Erwarte HTTP_REPLY 200 und die drei freigegebenen Produkte mit den ursprünglichen Preisen und Einheiten: Glass water bottle 1800 Cent / 6 Einheiten, Everyday notebook 1400 / 4, Canvas market bag 2400 / 0. Die API meldet außerdem, welcher ursprüngliche Bestands-Pod geantwortet hat; die öffentliche Seite zeigt dieses Infrastrukturdetail nicht. Der erfolgreiche API-Pfad und der fehlgeschlagene direkte Pfad sind miteinander vereinbar: Die API stellt ihre eigene erlaubte Bestandsverbindung her.
Wechsle zu Shop und lade die Seite neu. Öffne Glass water bottle, setze Quantity auf 2 und wähle Try a basket quote. Erwarte Ready for collection, Quantity 2, Total $36.00 und Units available 6. Lies den Übungshinweis: Es wird kein Bestand reserviert. Verwende Back to product und Back to collection.
Öffne Canvas market bag, gekennzeichnet mit Back soon, und versuche eine Kalkulation für Quantity 1. Erwarte Not enough stock, Total $24.00 und Units available 0. Dies ist eine gültige fachliche Antwort und kein Netzwerkfehler; ändere den Bestand nicht, damit jede Kalkulation erfolgreich wird. Verwende Back to product und dann Back to collection. Öffne Our approach, lies die Beschreibung der Übungskalkulationen und verwende Back to collection.
Der fertige Katalog hat drei ursprüngliche Produkte und eine aktuelle Verfügbarkeitsanzeige; vergleiche Überschrift, Preise und Verfügbarkeit mit diesem laufenden Beispiel:
Wechsle zu Reference und lade die Seite neu. P-104 · Ready und P-108 · Packed müssen sichtbar bleiben. Wähle Download notes und öffne den tatsächlichen Download notes.json: Er enthält die beiden unveränderten Versanddatensätze und keine Bestandsdaten. Dein Browserdownload und der Terminalarbeitsbereich sind unterschiedliche Speicherorte; diese Aufgabe verlangt nicht, diese Datei in den Arbeitsbereich zu kopieren.
Kehre zu Workspace zurück und lies denselben separaten Service aus der Identität Customer:
./tools/network-test customer http http://dispatch.meadow-stock.svc.cluster.local:8080/notes.json
Erwarte HTTP_REPLY 200 und beide ursprünglichen Hinweise. Die Richtlinie hat Bestands-Pods ausgewählt und nicht den gesamten Bestands-Namespace. Behalte den Versandprozess, seine Daten und den ursprünglichen Service bei; ihn abzuschalten würde eine zu weit gefasste Regel verbergen.
Deine Übergabe besteht aus release/stock-ingress.yaml und der entsprechenden wirksamen Grenze. Der vollständige Katalog und beide Kalkulationsergebnisse müssen weiterhin über die ursprüngliche Anwendung funktionieren, während die beiden direkten Bestandsumgehungen verweigert bleiben. Behalte jede vorbereitete Quelldatei, jedes Anwendungsobjekt und jeden ursprünglichen Pod bei. Falls eine Seite Live availability unavailable zeigt, kehre zu den erklärten Label-, Richtlinien- und Anfrageprüfungen zurück, korrigiere nur deine Release-Richtlinie und wende sie erneut an; eine statische Ersatzseite ist keine Reparatur. Die Tests hier sind endlich viele echte TCP-Anfragen auf einem vorbereiteten Cluster und keine Garantie für Produktionssicherheit oder unterbrechungsfreie Verfügbarkeit.
Zusammenfassung
Du hast den echten Ablauf Kundenseite → API → Bestand erhalten und zugleich direkte Bestandslesezugriffe sowohl von einem Kunden mit falscher Rolle als auch von einem Besucher mit passender Rolle in einem anderen Namespace verhindert. Deine gespeicherte Ingress-Richtlinie drückt die gemeinsame Bedingung aus Namespace und Rolle aus, und der laufende Katalog, die Übungskalkulationen und der separate Versandservice funktionieren weiterhin.
NetworkPolicy steuert Pod-Netzwerkpfade, keine Kundenauthentifizierung. Eine Zeitüberschreitung ist nur dann ein hilfreicher Beleg, wenn Ziel und freigegebene Verbindung weiterhin funktionieren. Das nächste unabhängige Lab betrachtet die andere Richtung: ausgehenden API-Verkehr, DNS und durch andere Richtlinien beigetragene Berechtigungen.
