Die EKS-API hinter ein VPN legen: Reihenfolge der Schritte

Aktivieren Sie den privaten Endpunkt, weisen Sie nach, dass kubectl ihn erreicht hat, und schließen Sie dann den öffentlichen. Ein stufenweises Runbook mit den Befehlen und den Prüfungen zwischen den Schritten.

Die gefährliche Variante dieser Änderung ist ein einziger Befehl, der den Endpunkt umschaltet und alle Administratoren gleichzeitig aussperrt. Die sichere Variante hält beide Wege offen, weist nach, dass der private Weg über das VPN funktioniert, und zieht erst dann den öffentlichen Endpunkt zurück. Setzen Sie einen bestehenden Cluster, einen genehmigten Tunnel in dessen VPC und eine bereits funktionierende kubeconfig voraus; die Aufgabe ist privater Zugriff auf die Kubernetes-API, nicht private Nodes und kein neues Berechtigungsmodell. Jeder Schritt unten hat eine Prüfung, an der Sie sicher scheitern können.

1. Den Endpunkt inventarisieren und einen Rückweg behalten

Halten Sie den aktuellen Zustand fest, bevor Sie ihn ändern, einschließlich der öffentlichen CIDR-Allowlist und der Sicherheitsgruppe des Clusters. Genau diese beiden vergleichen Sie, wenn etwas nicht mehr funktioniert, und die Allowlist ist auch Ihr Rollback-Weg, falls sich die private Route als falsch erweist.

aws eks describe-cluster --region REGION --name CLUSTER \
  --query 'cluster.{endpoint:endpoint,public:resourcesVpcConfig.endpointPublicAccess,private:resourcesVpcConfig.endpointPrivateAccess,cidrs:resourcesVpcConfig.publicAccessCidrs}'

REGION und CLUSTER sind hier Platzhalter. Achten Sie darauf, was das private Flag jetzt anzeigt, denn ein Cluster, der mit bereits aktiviertem privaten Zugriff erstellt wurde, braucht einen anderen ersten Schritt als einer, der ihn nie hatte. Halten Sie während der Umstellung mindestens einen genehmigten Administrationsweg offen; ein VPN, das davon abhängt, dass derselbe Cluster erreichbar ist, ist kein Wiederherstellungsweg.

2. Privaten Zugriff aktivieren, wenn der Netzwerkweg steht

Das Flag einzuschalten ist die leichte Hälfte. Der Tunnel braucht eine Route zu den privaten Adressen des Endpunkts, und die Sicherheitsgruppe des Clusters braucht TCP 443 von der Quelle, die das VPN tatsächlich präsentiert. Eine Client-VPN-Zuordnung, ein Site-to-Site-Gateway und ein gepeertes VPC können alle unterschiedliche Quelladressen präsentieren, deshalb verwenden Sie das Modell, das Sie bereitgestellt haben, statt eines generischen privaten Bereichs.

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=true

aws eks describe-update --region REGION --name CLUSTER --update-id UPDATE_ID

Die Aktualisierung ist asynchron. Fragen Sie die Update-ID ab, bis sie Erfolg meldet, statt eine feste Anzahl von Sekunden zu warten und es anzunehmen. Lassen Sie den Verkehr der Nodes und der Control Plane in Ruhe, während Sie das tun: die gesamte Sicherheitsgruppe des Clusters durch eine Regel für Ihren Laptop zu ersetzen, ist der Weg, wie aus einer funktionierenden Datenebene ein zweiter Vorfall wird.

Die Dokumentation zu EKS-Endpunkten lohnt sich einmal vollständig zu lesen, denn sie sagt, dass reiner Privatzugriff aus dem VPC oder einem verbundenen Netzwerk kommen kann. Dieser Satz ist der ganze Grund, warum diese Migration möglich ist, und er ist auch der Grund, warum der nächste Schritt existiert.

3. Nachweisen, dass die Workstation den privaten Weg benutzt hat

Wenn beide Endpunkte aktiviert sind, beweist ein erfolgreiches kubectl get ns nichts darüber, welcher geantwortet hat. Lösen Sie den Hostnamen des Endpunkts auf und prüfen Sie, ob die erhaltene Adresse zum privaten oder zum öffentlichen Bereich gehört. Wenn Ihr verbundenes Netzwerk die private Sicht nicht über DNS erhält, wird der Befehl über den öffentlichen Endpunkt erfolgreich sein, und Sie ziehen den öffentlichen Weg aufgrund falscher Beweise zurück. Das ist die mit Abstand häufigste Art, wie diese Migration schiefgeht, und es sieht genau wie Erfolg aus.

nslookup HASH.gr7.REGION.eks.amazonaws.com
kubectl cluster-info
kubectl get ns --request-timeout=10s

Behalten Sie den Hostnamen und die Zertifikatsprüfung genau so, wie sie sind. Eine private IP in die kubeconfig einzusetzen und die TLS-Prüfung zu überspringen, ist nicht die Migration, die Sie im Änderungsdatensatz beschrieben haben, und sie wird erneut fehlschlagen, sobald der Endpunkt rotiert.

4. Öffentlichen Zugriff bewusst zurückziehen

Sobald der private Weg nachgewiesen und der Wiederherstellungsablauf genehmigt ist, schließen Sie den öffentlichen Endpunkt. Dies ist eine echte Änderung und keine Vorschau, also führen Sie sie gegen das Konto und die Einstellungen aus, die Sie tatsächlich meinen.

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true

Im Nur-Privat-Modus löst der öffentliche DNS-Name von innerhalb des VPC auf die privaten Adressen des Endpunkts auf, sodass Auflösung und Erreichbarkeit nicht mehr dasselbe sind. Alles, was auf die öffentliche Adresse angewiesen war, einschließlich CI-Runnern oder einem Laptop in einem anderen Netzwerk, braucht jetzt seinen eigenen Weg hinein.

5. Netzwerkrichtlinie und Identitätsrichtlinie getrennt halten

Die CIDR-Liste für den öffentlichen Zugriff regelt nur den öffentlichen Endpunkt. Sie beschränkt nicht den privaten Endpunkt, der stattdessen durch die Sicherheitsgruppe des Clusters und die Richtlinie des verbundenen Netzwerks begrenzt wird. Wenn Sie den öffentlichen Endpunkt behalten, muss seine Allowlist zu dem öffentlichen Egress passen, den Ihre API-Clients und Nodes tatsächlich nutzen; eine VPN-Pool-Adresse ist selten diese Quelle.

Nichts davon ändert IAM oder Kubernetes RBAC. Endpunkteinstellungen sind eine administrative Aktion, und normale Benutzer sollten keine Berechtigung erhalten, die Grenze zu lockern, nur um die API zu erreichen. Schreiben Sie den Endzustand, das Datum und den Wiederherstellungsweg ins Runbook und testen Sie den Wiederherstellungsweg einmal, solange er noch einfach ist.

Ähnliche Artikel