kubectl funktioniert über das VPN, aber AKS skaliert nicht mehr: Warum

Sie fügen die öffentliche Adresse des Büro-VPNs zur Positivliste des AKS-API-Servers hinzu, und kubectl funktioniert. Eine Woche später schlägt das Hochskalieren eines Knotenpools fehl, ein CI-Job erreicht den Cluster nicht, und das Portal zeigt einen Fehler, der nichts über IP-Bereiche sagt. Niemand hat die Positivliste geändert. Die aktivierte Kontrolle ist ein öffentlicher IP-Filter vor dem API-Server, und er weiß nicht, wer anruft, sondern nur, von welcher Adresse der Aufruf kommt. Das VPN ist eine von mehreren Adressen, die der Cluster braucht, und es ist selten die, die zuerst ausfällt.

Die Positivliste gleicht eine Adresse ab, keine Person

--api-server-authorized-ip-ranges erwartet CIDR-Blöcke, keine Benutzer oder Gruppen. Wenn eine Anfrage eines Entwicklers den VPN-Server in Richtung Azure verlässt, ist die Quelladresse am API-Server der öffentliche Egress des VPN-Servers. Jede Person in diesem VPN teilt sich daher einen Eintrag, und wer nicht im VPN ist, wird abgewiesen, bevor die Authentifizierung überhaupt beginnt.

Das bedeutet auch, dass der Eintrag mehr Personen zulässt, als Sie vielleicht beabsichtigen. Ein Auftragnehmer mit VPN-Zugang, ein privates Notebook am selben Konzentrator und ein kompromittiertes Konto kommen alle von derselben Adresse. Die Cluster-Autorisierung bleibt unverändert, deshalb entscheidet weiterhin die rollenbasierte Zugriffssteuerung, was der Aufrufer darf, aber die Positivliste ist keine Identitätskontrolle und sollte nie als solche beschrieben werden.

Was zuerst ausfällt, ist meist nicht kubectl

Die Positivliste gilt für den öffentlichen Endpunkt des API-Servers, daher funktioniert alles außerhalb Ihrer aufgeführten Adressen sofort nicht mehr. Die offensichtlichen Opfer sind das zweite Büro ohne VPN-Route, ein CI-Runner in einer gehosteten Pipeline und ein Notebook, das vergessen hat, sich zu verbinden. Diese sind leicht zu erkennen, weil ein Mensch wartet.

Der weniger offensichtliche Fall ist Automatisierung, die Azure oder Ihre eigenen Werkzeuge steuert. Einige von der Plattform ausgelöste Vorgänge erreichen den API-Server von Adressen, die nicht Ihr VPN sind, und wenn einer davon direkt nach dem Verschärfen der Liste ausfällt, ist der Zeitpunkt der Hinweis. Gehen Sie nicht davon aus, dass die Liste vollständig ist, nur weil der interaktive Zugriff funktioniert; prüfen Sie, was das Feature für Ihre Region und Ihre Abonnements benötigt, bevor Sie den Cluster für defekt erklären.

Die Fehlersignatur hilft. Wenn die Anfrage nie zur Authentifizierung gelangt, ist es der Filter. Wenn sie sich authentifiziert und dann einen Berechtigungsfehler erhält, hat der Filter seine Aufgabe erfüllt, und das Problem ist die rollenbasierte Zugriffssteuerung, die die Positivliste nie berührt.

Erstellen Sie die ganze Liste mit einem Befehl

Der Update-Parameter ersetzt die gesamte Liste, statt einen Eintrag hinzuzufügen, daher verwirft ein Befehl, der nur die VPN-Adresse enthält, stillschweigend alles andere, was dort stand. Lesen Sie zuerst den aktuellen Wert, behalten Sie ihn, und senden Sie die Vereinigung:

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

Verwenden Sie eine reservierte öffentliche IP für den VPN-Server, bevor Sie sich darauf verlassen. Eine dynamische Adresse ändert sich beim Wiederverbinden, und jede Änderung sperrt das Team stillschweigend aus dem Cluster aus, bis jemand die Liste von einem noch erlaubten Netzwerk aus aktualisiert. Wenn Sie zwei VPN-Egress-Punkte für Redundanz haben, führen Sie beide auf, denn der Filter kennt kein bevorzugtes Pfadkonzept.

Planen Sie die Änderung so, dass der erste erlaubte Versuch zugleich der Test ist. Kündigen Sie die neue Liste an, wenden Sie sie an und verbinden Sie sich sofort über das VPN; in umgekehrter Reihenfolge bleibt ein Fenster, in dem niemand den API-Server erreichen kann, um einen Tippfehler in einem CIDR-Block zu korrigieren.

Was die Positivliste nie abgedeckt hat

Sie macht den API-Server nicht privat. Ein privater Cluster verwendet einen privaten Endpunkt und privates DNS, und die Liste der autorisierten Bereiche ist nicht die Kontrolle, die das ersetzt. Sie ändert auch nicht, was ein zugelassener Aufrufer tun kann, daher funktioniert eine durchgesickerte Admin-kubeconfig weiterhin von jeder erlaubten Adresse aus. Behandeln Sie den Ausweis als Sicherheitsgrenze und die Liste als Netzkomfort.

Sie hat nichts mit Workloads zu tun. Pods und Dienste laufen mit aktivierter Liste weiter, und eine Anwendung über das VPN zu erreichen, ist ein getrenntes Problem: Ein Dienst, der nur eine Cluster-IP hat, braucht trotzdem einen internen Load Balancer, ein Ingress oder einen Port-Forward, bevor ein Notebook ihn öffnen kann. Das Vermischen dieser beiden Entwürfe erzeugt ein Änderungsticket, das vorgibt, Entwickler einzuschränken, und tatsächlich nichts an den Anwendungen einschränkt.

Prüfen Sie von beiden Seiten, dann führen Sie einen echten Vorgang aus

Testen Sie mit einem frischen Client im VPN und mit einem Client außerhalb. Der Versuch von außen sollte am API-Server abgelehnt werden, nicht bei der Namensauflösung; wenn der Name nicht aufgelöst wird, dann testen Sie DNS und haben nichts über den Filter gelernt. Führen Sie dann einen Vorgang aus, der kein interaktiver kubectl-Aufruf ist, etwa das Skalieren eines Knotenpools oder eine Upgrade-Prüfung, und bestätigen Sie, dass er abgeschlossen wird, statt es anzunehmen.

Halten Sie den vorherigen Listenwert neben der Änderung fest, und lesen Sie den effektiven Wert nach dem Update erneut, statt dem eingegebenen Befehl zu vertrauen. Die Dokumentation zu den autorisierten IP-Bereichen von AKS listet die unterstützten Parameter und die Plattformanforderungen auf, die in dieselbe Liste gehören, was der Teil ist, den die meisten Ticketbeschreibungen auslassen.