Nebezpečná verze této změny je jediný příkaz, který přepne endpoint a současně zamkne všechny administrátory. Bezpečná verze nechává obě cesty otevřené, dokaže, že privátní cesta funguje z VPN, a teprve potom vyřadí veřejný endpoint. Předpokládejte existující cluster, schválený tunel do jeho VPC a kubeconfig, který už funguje; úkolem je privátní přístup k API Kubernetes, ne privátní uzly a ne nový model oprávnění. Každý krok níže má kontrolu, u které můžete bezpečně selhat.

1. Zinventarizujte endpoint a ponechte si cestu zpět

Před změnou si zapište současný stav, včetně veřejného seznamu povolených CIDR a bezpečnostní skupiny clusteru. Právě tyto dvě věci budete porovnávat, když něco přestane fungovat, a seznam povolených je také vaše cesta zpět, pokud se privátní trasa ukáže jako chybná.

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

REGION a CLUSTER jsou zde zástupné hodnoty. Všimněte si, co privátní příznak nyní ukazuje, protože cluster vytvořený s už zapnutým privátním přístupem potřebuje jiný první krok než ten, který ho nikdy neměl. Během přechodu udržujte otevřenou alespoň jednu schválenou administrativní cestu; VPN, která závisí na dostupnosti stejného clusteru, není cestou pro obnovu.

2. Zapněte privátní přístup s připravenou síťovou cestou

Zapnutí příznaku je ta snazší polovina. Tunel potřebuje trasu k privátním adresám endpointu a bezpečnostní skupina clusteru potřebuje TCP 443 ze zdroje, který VPN skutečně prezentuje. Přidružení Client VPN, brána site-to-site a propojené VPC mohou prezentovat různé zdrojové adresy, proto použijte model, který jste nasadili, a ne obecný privátní rozsah.

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

Aktualizace je asynchronní. Dotazujte se na id aktualizace, dokud neohlásí úspěch, místo abyste čekali pevný počet sekund a předpokládali. Ponechte provoz uzlů a řídicí roviny na pokoji, dokud to děláte: nahrazení celé bezpečnostní skupiny clusteru pravidlem pro váš notebook je způsob, jak se z fungující datové roviny stane druhý incident.

Dokumentace k endpointům EKS stojí za jedno celé přečtení, protože říká, že přístup pouze přes privátní cestu může přicházet z VPC nebo z připojené sítě. Tato věta je celým důvodem, proč je tato migrace možná, a zároveň důvodem, proč existuje další krok.

3. Dokažte, že pracovní stanice použila privátní cestu

Když jsou zapnuté oba endpointy, úspěšný kubectl get ns nic nedokazuje o tom, který z nich odpověděl. Přeložte název hostitele endpointu a zkontrolujte, zda získaná adresa patří do privátního, nebo veřejného rozsahu. Pokud vaše připojená síť nedostává privátní pohled přes DNS, příkaz uspěje přes veřejný endpoint a vy vyřadíte veřejnou cestu na základě falešných důkazů. To je nejčastější způsob, jak tato migrace selže, a vypadá přesně jako úspěch.

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

Ponechte název hostitele a ověřování certifikátu přesně tak, jak jsou. Nahrazení privátní IP v kubeconfig a přeskočení ověření TLS není migrace, kterou jste popsali v záznamu o změně, a selže znovu ve chvíli, kdy se endpoint otočí.

4. Úmyslně vyřaďte veřejný přístup

Jakmile je privátní cesta prokázána a postup obnovy schválen, zavřete veřejný endpoint. Jde o skutečnou změnu, ne o náhled, takže ji spusťte proti účtu a nastavení, které skutečně máte na mysli.

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

V režimu pouze privátního přístupu se veřejné jméno DNS překládá na privátní adresy endpointu zevnitř VPC, takže překlad a dostupnost přestávají být totéž. Vše, co se spoléhalo na veřejnou adresu, včetně CI runnerů nebo notebooku v jiné síti, nyní potřebuje vlastní cestu dovnitř.

5. Držte síťovou politiku a politiku identity odděleně

Seznam CIDR pro veřejný přístup řídí pouze veřejný endpoint. Neomezuje privátní endpoint, který místo toho omezuje bezpečnostní skupina clusteru a politika připojené sítě. Pokud si veřejný endpoint ponecháte, jeho seznam povolených musí odpovídat veřejnému odchozímu provozu, který vaši klienti API a uzly skutečně používají; adresa z poolu VPN je jen zřídka tím zdrojem.

Nic z toho nemění IAM ani Kubernetes RBAC. Nastavení endpointu je administrativní akce a běžní uživatelé by neměli dostávat oprávnění rozvolnit hranici jen proto, aby dosáhli na API. Zapište konečný stav, datum a cestu obnovy do runbooku, a poté cestu obnovy jednou otestujte, dokud je to ještě snadné.

Související články