Einführung
Orchard Market benötigt ein kleines Statusboard für seine Marktstand- und Lieferanwendungen. Das Board-Programm ist bereit, doch seine aktuelle Kubernetes-Identität kann deren Deployments nicht lesen. Gib dem Board eine eigene Identität und nur die Berechtigungen, die es zum Anzeigen der tatsächlichen gewünschten Replikate, verfügbaren Replikate und Vorlagenimages benötigt. Halte den Personal-Namespace, Secrets und Workload-Änderungen außerhalb seines Zugriffs.
Dein Ergebnis ist ein nutzbares Board mit CSV-Download sowie vier gespeicherte Manifeste, die seine Identität, zwei Namespace-Berechtigungen und die Identitätsauswahl der Workload beschreiben. Das Board stellt echte HTTPS-Anfragen an den vorbereiteten Cluster. Es hat keine statischen Erfolgsdaten, mit denen es fehlgeschlagene Zugriffe ersetzen könnte.
Du solltest grundlegende Terminalpfade, einfaches YAML, Namespaces, Pods, Deployments, Services und Labels bereits kennen. Dieses Lab erklärt ServiceAccounts, Roles, RoleBindings und den bereitgestellten Client, bevor du sie verwendest. Ein echter Kubernetes-Einzelknoten-Cluster, das Board, synthetische Anwendungsdaten und das Diagnosewerkzeug sind vorbereitet. Du installierst weder den Cluster noch baust du ein Image, programmierst den Client oder kopierst Tokens. Die Dauer ist eine Schätzung des Autors einschließlich Lesen und gewöhnlicher Fehler und keine bei Anfängern gemessene Abschlusszeit.
Eine eigene Identität für das Board erstellen
In diesem Schritt liest du die tatsächliche anfängliche Identität des Boards und speicherst einen eigenen ServiceAccount, ohne ihm bereits Anwendungszugriff zu gewähren.
Beginne im Tab Board. Orchard Market sollte A clear view of the working day., die Gruppen Market stalls und Market delivery sowie Access denied · API 403 für beide Gruppen zeigen. Dies ist das erwartete anfängliche Problem. Das vollständige Ergebnis zeigt catalogue mit 2 gewünschten und 2 verfügbaren Replikaten, checkout mit 1 und 1, pickup mit 1 und 1 sowie receipts mit 0 und 0. Alle vier verwenden das vorbereitete Vorlagenimage python:3.12-alpine. Das Belegarchiv ist absichtlich auf null skaliert.
Die drei Hauptfelder beantworten unterschiedliche Fragen. Desired replicas ist die deklarierte Anzahl in einem Deployment. Available replicas ist die vom Controller gezählte Anzahl nach bestandener Readiness-Prüfung und erfüllter Mindestbereitschaftszeit. Template image ist das von der Deployment-Vorlage angeforderte Image; während einer Aktualisierung beweist es nicht, dass jeder bestehende Pod dieses Image bereits verwendet. Klappe What these fields mean auf, lies den Inhalt und klappe ihn wieder zu. Dies sind Controller-Beobachtungen und keine Verfügbarkeitsprüfungen einer Kundenwebsite.
Wähle Access details. Der Wert Read as stammt von der API und endet anfangs auf market-board:default. Die Tabelle nennt den beabsichtigten Berechtigungsumfang; sie behauptet nicht, dass der Zugriff bereits gewährt wurde. Verwende Back to status board und wechsle dann zu Workspace.
Das Terminal startet in /home/labex/project/status-board. pwd gibt dein Arbeitsverzeichnis aus, ls listet seine Einträge auf, und cd mit einem absoluten Pfad führt hierher zurück, falls du das Verzeichnis gewechselt hast:
pwd
ls
cd /home/labex/project/status-board
Erwarte scope.json, starter und tools. cat zeigt die vorbereitete Datei zum Arbeitsumfang an. Sie verwendet JSON (JavaScript Object Notation), ein Textformat aus benannten Werten und Listen, um die tatsächlichen Namespaces, die Identität und die Anwendungsnamen festzuhalten:
cat scope.json
Das Board läuft in market-board, während seine freigegebenen Anwendungsdaten in market-stalls und market-delivery liegen. market-office ist ausgeschlossen. --context=labex-v135 wählt den vorbereiteten Cluster aus; -n wählt einen Namespace aus. Die vorhandenen Zugangsdaten des Bedieners in Workspace können diese Kursobjekte untersuchen und konfigurieren. Sie sind nicht die Zugangsdaten des Boards. Untersuche als dieser Bediener die tatsächlichen Ziel-Deployments:
kubectl --context=labex-v135 get deployments -n market-stalls
kubectl --context=labex-v135 get deployments -n market-delivery
Lies die Namen und die Ergebnisse zu gewünschten/verfügbaren Replikaten, einschließlich des Belegarchivs mit null gewünschten Replikaten. Die zugrunde liegenden Objekte existieren, obwohl das Board sie nicht lesen kann. Ein Erfolg aus diesem Bedienerterminal beweist keinen Zugriff für einen Prozess innerhalb des Board-Pods.
Ein ServiceAccount ist eine Kubernetes-API-Identität für eine Workload innerhalb eines Namespaces und kein Linux-Benutzer oder Browserbesucher. Das vorbereitete Board-Deployment wählt anfangs den ServiceAccount default aus. describe stellt die Objektkonfiguration in lesbaren Abschnitten dar:
kubectl --context=labex-v135 describe deployment status-board -n market-board
Suche in seiner Pod-Vorlage nach dem ausgewählten ServiceAccount. Ein Pod erhält per Projektion einen Berechtigungsnachweis für diesen Account. Der vorbereitete Client liest ihn intern und prüft das Zertifikat des API-Servers anhand der bereitgestellten Zertifizierungsstelle; er gibt den Berechtigungsnachweis niemals aus und verwendet nicht deine Bediener-kubeconfig. Du konfigurierst Identität und Berechtigungen, statt die Behandlung von Zugangsdaten zu implementieren.
Das bereitgestellte ./tools/board-test führt diesen Client im aktuellen Board-Pod aus. Das vorangestellte ./ bedeutet, dass sich das Werkzeug in diesem Arbeitsverzeichnis befindet. Sein erstes Argument wählt eine erklärte Diagnoseoperation aus. identity fragt die API, wie sie diesen tatsächlichen Berechtigungsnachweis authentifiziert hat:
./tools/board-test identity
Erwarte als username den Wert system:serviceaccount:market-board:default zusammen mit der aktuellen pod_uid. Der Wert von http_status, hier 201, bedeutet, dass die API diese Prüfung der eigenen Identität beantwortet hat. Die Prüfung ist kein dauerhaft gespeichertes Clusterobjekt, ändert keine Berechtigungen und erstellt kein Deployment. Kein Token wird angezeigt. Auch ein bereiter Board-Prozess mit bestätigter Identität kann keinen Zugriff auf Anwendungsdaten haben.
Erstelle dein Release-Verzeichnis. mkdir -p erstellt es bei Bedarf und erhält ein vorhandenes Verzeichnis. Im nächsten Befehl leitet > die Ausgabe in deine bearbeitbare Datei um. Die Markierung YAML in Anführungszeichen hält den Text bis zur abschließenden, allein stehenden Markierung wörtlich. Eine Wiederholung des Befehls überschreibt nur diese Release-Datei:
mkdir -p release
cat > release/identity.yaml <<'YAML'
apiVersion: v1
kind: ServiceAccount
metadata:
name: market-reader
namespace: market-board
YAML
Lies deine Datei und wende sie dann an. apply -f liest das benannte Manifest und erstellt oder aktualisiert dessen Objekt:
cat release/identity.yaml
kubectl --context=labex-v135 apply -f release/identity.yaml
kubectl --context=labex-v135 get serviceaccount market-reader -n market-board
Die eigene Identität existiert jetzt. Ein langlebiges Token-Secret ist nicht automatisch erforderlich: Kubernetes projiziert einen gebundenen Berechtigungsnachweis in einen Pod, wenn dieser die Identität verwendet. Das Erstellen dieses ServiceAccounts allein gewährt weder Deployment-Zugriff noch ändert es die Identität des laufenden Boards. Lasse den ursprünglichen Standardaccount unverändert.
Verwende bei einem Tippfehler im Pfad die bereits gezeigten Befehle pwd, ls und das absolute cd und wiederhole dann die fehlgeschlagene Operation. Lies bei einem YAML-Fehler deine bearbeitbare Datei, vergleiche die Einrückung mit dem vollständigen Beispiel, schreibe sie erneut und wende sie wieder an. Lasse scope.json, die Startdatei, Werkzeuge, ursprünglichen Namespaces, Anwendungen und Daten unverändert. Du bearbeitest nur die genannten Release-Manifeste und deren benannte Identitäts-/RBAC-Objekte sowie den ausgewählten ServiceAccount des Board-Deployments.
Den ersten Namespace anbinden
In diesem Schritt gewährst du zwei Leseoperationen im Marktstand-Namespace und sorgst dann dafür, dass ein neuer Board-Pod die eigene Identität tatsächlich verwendet.
Beginne in Workspace unter /home/labex/project/status-board. Kubernetes-RBAC bedeutet rollenbasierte Zugriffskontrolle. Eine Role definiert Berechtigungen innerhalb eines Namespaces. Ein RoleBinding verbindet die Role dieses Namespaces mit einer Identität. Übereinstimmende Namen allein stellen diese Verbindung nicht her.
Das Board benötigt list, um eine Deployment-Sammlung zu lesen, und get, um ein einzelnes Deployment zu öffnen. Deployments gehören zur API-Gruppe apps; die Regel verwendet apps ohne /v1. watch würde einen Änderungsstrom anfordern, den dieses Board nicht verwendet. Schreibverben oder Secret-Zugriff werden nicht benötigt. Halte beide Leseverben für alle Deployments in jedem freigegebenen Namespace verfügbar. Lasse resourceNames weg, das optionale Regelfeld, das Berechtigungen auf benannte Ressourcen beschränkt. Das Feld roleRef.apiGroup der Bindung kennzeichnet die RBAC-API rbac.authorization.k8s.io; sie unterscheidet sich von der Gruppe apps, die die von der Role erlaubten Deployments enthält.
Speichere eine Role und ihre Bindung in einem Manifest. Der Trenner --- beginnt ein zweites YAML-Dokument. Das Feld metadata.namespace der Bindung gibt an, wo die Berechtigung gilt, während subjects.namespace angibt, wo der ServiceAccount existiert. Hier sind diese absichtlich unterschiedlich:
cat > release/first-access.yaml <<'YAML'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-reader
namespace: market-stalls
rules:
- apiGroups: [apps]
resources: [deployments]
verbs: [get, list]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: board-reader
namespace: market-stalls
subjects:
- kind: ServiceAccount
name: market-reader
namespace: market-board
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: deployment-reader
YAML
Lies beide Objekte, wende sie an und untersuche dann die interpretierte Verbindung:
cat release/first-access.yaml
kubectl --context=labex-v135 apply -f release/first-access.yaml
kubectl --context=labex-v135 describe role deployment-reader -n market-stalls
kubectl --context=labex-v135 describe rolebinding board-reader -n market-stalls
Erwarte nur get und list für Deployments. Folge roleRef zur Role in market-stalls und dem Subjekt zu market-reader in market-board. Die Bindung erstellt keinen zweiten ServiceAccount im Ziel-Namespace.
Das laufende Board verwendet weiterhin default. Die Operation list des Diagnosewerkzeugs fordert die tatsächliche Deployment-Sammlung mit dem aktuellen Berechtigungsnachweis dieses Pods an. Ein verbotener Lesezugriff gibt http_status: 403 und einen Befehls-Exit-Status ungleich null zurück; dies ist zu erwarten, bevor du die Workload-Identität wechselst:
./tools/board-test list market-stalls
Die neue Berechtigung gehört market-reader und nicht default. Behebe dies nicht, indem du dem Standardaccount Zugriff gewährst. Wähle den eigenen Account in einer gespeicherten Kopie des vorbereiteten Board-Deployments aus.
Lies zuerst die vollständige Startdatei. Sie enthält das vorhandene Image, die eingebundene Quelle, Zustandsprüfung, Replikatanzahl und weitere zu erhaltende Einstellungen:
cat starter/board.yaml
kubectl set serviceaccount ändert die ausgewählte Identität. --local transformiert diese Eingabedatei, ohne sie auf den Cluster anzuwenden. -f benennt die Eingabe, -o yaml schreibt ein YAML-Manifest auf die Standardausgabe, und das bereits gelernte > speichert es als deine bearbeitbare Release-Datei:
kubectl --context=labex-v135 set serviceaccount --local -f starter/board.yaml market-reader -o yaml > release/board.yaml
Lies das Ergebnis und bestätige, dass spec.template.spec.serviceAccountName auf market-reader gesetzt ist. Behalte alle anderen Anwendungseinstellungen bei:
cat release/board.yaml
kubectl --context=labex-v135 apply -f release/board.yaml
Der ServiceAccount eines bestehenden Pods kann nicht direkt geändert werden. Das Aktualisieren der Pod-Vorlage des Deployments erzeugt einen neuen Pod. rollout status wartet auf die neue Workload; --timeout=120s begrenzt die Wartezeit:
kubectl --context=labex-v135 rollout status deployment/status-board -n market-board --timeout=120s
kubectl --context=labex-v135 get pods -n market-board
Erwarte einen bereiten aktuellen Board-Pod. Das Ersetzen dieses Board-Pods ist nötig; die Pods der Zielanwendungen werden nicht geändert. Lies seine tatsächliche authentifizierte Identität erneut:
./tools/board-test identity
Erwarte system:serviceaccount:market-board:market-reader und eine andere pod_uid als beim ursprünglichen Pod mit Standardidentität. Dies bestätigt den Berechtigungsnachweis des Prozesses, statt lediglich eine stellvertretend angenommene Identität zu bewerten.
Ergebnisse für Deployment-Sammlungen und -Details enthalten außerdem generation, die Version des gewünschten Deployment-Zustands, und observed_generation, die zuletzt vom Controller verarbeitete Version. Die Detailseite bezeichnet sie als Deployment generation und Observed generation. Ein Controller kann einer gewünschten Änderung kurzzeitig hinterherlaufen. Diese Felder zählen keine Kundenanfragen und belegen keine Website-Verfügbarkeit.
Lies die Marktstand-Sammlung und ein einzelnes Deployment. get erwartet den Namespace, gefolgt vom Deployment-Namen:
./tools/board-test list market-stalls
./tools/board-test get market-stalls catalogue
Erwarte http_status: 200, beide ursprünglichen Marktstand-Deployments in der Sammlung und catalogue mit 2 gewünschten und 2 verfügbaren Replikaten im Einzelergebnis. Die uid kennzeichnet das ursprüngliche Objekt; das Vorlagenimage bleibt python:3.12-alpine. Eine Namespace-Role erstreckt sich nicht auf den Liefer-Namespace:
./tools/board-test list market-delivery
Erwarte für diesen letzten Befehl API 403 und einen Befehlsstatus ungleich null. Wechsle zu Board, verwende Refresh view, öffne Inspect catalogue und lies die gewünschten/verfügbaren Anzahlen sowie Template image. Verwende Back to status board. Die Marktstand-Karten sollten funktionieren, während die Liefergruppe weiterhin Access denied · API 403 zeigt. Dieses Teilergebnis ist ein hilfreicher Beleg für die Namespace-Grenze.
Falls Read as unmittelbar nach einem Rollout noch die vorherige Identität zeigt, verwende Refresh view erneut. Um den aktuellen Pod zu bestätigen, wechsle zu Workspace, wiederhole ./tools/board-test identity, kehre dann zu Board zurück und aktualisiere die Ansicht. Das Service-Routing benötigt möglicherweise einen kurzen Moment, um den Rollout nachzuvollziehen; gewähre der alten Identität keinen Zugriff, um den Übergang zu verbergen.
Vergleiche den tatsächlichen Leser, die erfolgreichen Marktstand-Karten und die weiterhin verweigerte Liefergruppe in diesem laufenden Beispiel:
Falls die Rollout-Wartezeit überschritten wird, kehre zu Workspace zurück und untersuche dasselbe Deployment und die Pods mit den bereits gezeigten Befehlen describe und get. Falls ein Lesezugriff unerwartet verweigert wird, vergleiche Role, Subjekt-Namespace des RoleBindings und ausgewählte Workload-Identität. Korrigiere nur deine Release-Datei, wende sie an und wiederhole den entsprechenden Rollout oder die Anfrage. Kopiere keine Bedienerzugangsdaten, ändere die Anwendung nicht und starte die VM nicht neu.
Das Feld roleRef eines RoleBindings ist unveränderlich. Falls ein früherer Tippfehler die neue Bindung board-reader dieses Kurses mit dem falschen Role-Verweis erstellt hat, verweigert Kubernetes eine direkte Änderung dieses Verweises. Untersuche sie zuerst und korrigiere release/first-access.yaml; erstelle dann nur deine eigene benannte Bindung neu und wende anschließend die korrigierte gespeicherte Datei an:
kubectl --context=labex-v135 delete rolebinding board-reader -n market-stalls
kubectl --context=labex-v135 apply -f release/first-access.yaml
Dies sind bedingte Wiederherstellungsbefehle und keine erforderliche Löschung auf dem normalen erfolgreichen Weg. Lösche keine Standard- oder Plattformbindungen und lösche weder das ursprüngliche Board-Deployment noch die Ziel-Workloads.
Das Board erweitern, ohne seinen Aufgabenbereich auszuweiten
In diesem Schritt gibst du derselben Identität dieselben zwei Leseoperationen im Liefer-Namespace und prüfst anschließend die nützliche Ausgabe und geschützten Grenzen.
Beginne in Workspace unter /home/labex/project/status-board. Ein zweiter Namespace benötigt seine eigene Role und sein eigenes RoleBinding. Verwende dort denselben Role-Namen, lasse das Subjekt aber in market-board; die Identität ist nicht umgezogen:
cat > release/second-access.yaml <<'YAML'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-reader
namespace: market-delivery
rules:
- apiGroups: [apps]
resources: [deployments]
verbs: [get, list]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: board-reader
namespace: market-delivery
subjects:
- kind: ServiceAccount
name: market-reader
namespace: market-board
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: deployment-reader
YAML
cat release/second-access.yaml
kubectl --context=labex-v135 apply -f release/second-access.yaml
kubectl --context=labex-v135 describe rolebinding board-reader -n market-delivery
Die Bindung weist diese Ziel-Role der bestehenden Board-Identität zu. Ein weiterer Board-Rollout ist nicht nötig, weil der aktuelle Pod diese Identität bereits verwendet. RBAC-Berechtigungen addieren sich; das Ändern der Dateireihenfolge führt keine Verweigerungsregel ein und entfernt keine unabhängige Berechtigung.
Lies beide freigegebenen Sammlungen und ein Lieferdetail über den tatsächlichen Berechtigungsnachweis des Boards:
./tools/board-test list market-stalls
./tools/board-test list market-delivery
./tools/board-test get market-delivery pickup
Erwarte API 200 mit den ursprünglichen Objekten und Images. Die Liefersammlung enthält pickup mit 1 gewünschtem/1 verfügbarem Replikat und receipts mit 0/0. Das Deployment mit null gewünschten Replikaten bleibt ein echtes Objekt, obwohl es keine laufenden Pods hat. Erhalte diese deklarierte Einstellung.
Prüfe jetzt ausgeschlossene Daten. Ein Kubernetes-Secret speichert benannte Datenwerte. Das vorbereitete staff-note ist eine synthetische Übungsdatei; das Board hat keinen Grund, es zu lesen. Der Bediener kann bestätigen, dass dieses Objekt existiert, ohne seine Werte anzuzeigen:
kubectl --context=labex-v135 get secret staff-note -n market-stalls
Der eigene Berechtigungsnachweis des Boards muss für den dritten Namespace und dieses Secret weiterhin API 403 erhalten. Beide folgenden Befehle sollen mit einem Status ungleich null enden:
./tools/board-test list market-office
./tools/board-test secret market-stalls staff-note
Ein fehlendes Objekt, ein Verbindungsfehler oder ein Screenshot einer Fehlermeldung ist dieser tatsächlichen Autorisierungsverweigerung nicht gleichwertig. Derselbe Client liest die freigegebenen Ziele erfolgreich, während die bestehenden ausgeschlossenen Objekte intakt bleiben. Seine Datei mit dem projizierten Berechtigungsnachweis gewährt ihm keinen Zugriff auf die Secret-API.
Die Operation permission des Werkzeugs fragt die API, ob dieser tatsächliche Berechtigungsnachweis eine Aktion ausführen darf. Sie führt diese Aktion nicht aus. Die Argumente sind Namespace, Verb und gegebenenfalls Deployment-Name. Die nicht dauerhaft gespeicherte Prüfung gibt für jede verbotene Operation http_status: 201 mit allowed: false zurück; das Werkzeug gibt für diese Verweigerung einen Status ungleich null zurück:
./tools/board-test permission market-stalls patch catalogue
./tools/board-test permission market-delivery delete pickup
./tools/board-test permission market-stalls create
Das Board benötigt nur get und list; weder ein Watch-Stream noch Workload-Änderungen sind autorisiert. Lasse die Standardidentität und das ursprüngliche Plattform-RBAC unverändert. Füge keine ClusterRole, kein ClusterRoleBinding, keinen Platzhalter, kein zusätzliches Subjekt und keine weitere Ressourcenberechtigung hinzu.
Wechsle zu Board und verwende Refresh view. Beide Gruppen zeigen jetzt ihre ursprünglichen Deployments. Öffne Inspect pickup, lies seine Anzahlen und sein Image und verwende dann Back to status board. Lies die Karte receipts: Scaled to zero, 0 verfügbar, 0 gewünscht. Dies ist kein leerer Ersatz für eine fehlgeschlagene Anfrage.
Vergleiche den tatsächlichen Leser, alle vier Deployment-Karten und das sichtbare Archiv mit null gewünschten Replikaten in diesem fertigen Beispiel:
Wähle Download CSV und öffne die tatsächlich heruntergeladene orchard-market-deployments.csv. Sie hat vier Datenzeilen, eine für jedes ursprüngliche Deployment einschließlich des Belegarchivs. Gleiche Namespace, Deployment-Name, gewünschte/verfügbare Werte, Vorlagenimage und API-Status mit der Seite ab. Dies ist ein frischer API-Export und kein gespeichertes Erfolgsbeispiel. Browserdownloads und Terminalarbeitsbereich sind getrennte Speicherorte; du sollst den Download nicht in den Arbeitsbereich kopieren.
Wähle Access details, bestätige den tatsächlichen Wert Read as und beide beabsichtigten Namespace-Bereiche und verwende dann Back to status board. Behalte jedes ursprüngliche Ziel-Deployment, jede Pod-/Containeridentität, Quelle, jedes Image, alle Daten und Namespace-Labels bei. Erhalte das ursprüngliche Board-Deployment und seinen Service; nur sein ausgewählter ServiceAccount ändert sich. Das wiederverwendbare Release enthält identity.yaml, first-access.yaml, second-access.yaml und board.yaml, passend zur tatsächlichen Identität und zu den wirksamen Berechtigungen.
Falls der zweite Namespace weiterhin verweigert wird, kehre zu Workspace zurück, untersuche seine Bindung mit dem gezeigten Befehl describe, vergleiche Subjekt-Namespace und Role-Verweis, korrigiere deine gespeicherte Datei und wende sie erneut an. Verwende bei einem unveränderlichen falschen roleRef dieselbe zuvor erklärte eng begrenzte Wiederherstellung, jetzt nur für deine neue Lieferbindung:
kubectl --context=labex-v135 delete rolebinding board-reader -n market-delivery
kubectl --context=labex-v135 apply -f release/second-access.yaml
Führe diese Befehle nur für genau diese Wiederherstellung aus. Falls ausgeschlossener Zugriff unerwartet erfolgreich ist, untersuche deine beiden gespeicherten Roles und deren Bindungen, entferne die unbeabsichtigte Berechtigung innerhalb dieser Objekte und wende sie erneut an. Eine weitreichende Berechtigung wird nicht durch eine andere engere Role außer Kraft gesetzt. Bearbeite weder Plattformberechtigungen noch die Anwendung, um einen Fehler zu verbergen. Pfad- und YAML-Fehler werden mit der zuvor erklärten Wiederherstellung behoben, ohne die VM zurückzusetzen.
Das fertige Werkzeug liest vom Controller gemeldeten Deployment-Zustand in diesem vorbereiteten Einzelknoten-Cluster. Es authentifiziert keine Board-Besucher, liest keine Pod-Logs oder Metriken und beweist keine Produktionsverfügbarkeit. Sein Readiness-Endpunkt bestätigt nur, dass der Board-Prozess Anfragen bedienen kann; tatsächliche API-Ergebnisse belegen, ob Anwendungsdaten zugänglich sind.
Zusammenfassung
Du hast einem echten Client innerhalb des Clusters einen eigenen ServiceAccount gegeben, eine Namespace-bezogene Role und ein RoleBinding verbunden und einen neuen Pod dazu gebracht, diese Identität tatsächlich zu verwenden. Anschließend hast du dieselbe Leseaufgabe auf einen zweiten freigegebenen Namespace erweitert, ohne Zugriff auf ausgeschlossene Daten oder Workload-Änderungen zu gewähren.
Das nutzbare Board, die aktuelle CSV-Datei und gespeicherte Manifeste verknüpfen Identität, Berechtigungen und tatsächliche API-Ausgabe. Gewünschte Replikate, vom Controller gemeldete Verfügbarkeit und Vorlagenimages bleiben unterschiedliche Beobachtungen. Eine API-Verweigerung bleibt als nicht verfügbar ausgewiesen, während ein absichtliches Deployment mit null gewünschten Replikaten als echtes Objekt sichtbar bleibt.
