Umieść API EKS za VPN: kolejność operacji

Włącz prywatny endpoint, udowodnij, że kubectl do niego dotarł, a następnie zamknij publiczny. Stopniowy runbook z poleceniami i kontrolami między każdym krokiem.

Niebezpieczna wersja tej zmiany to jedno polecenie, które przełącza endpoint i jednocześnie odcina wszystkich administratorów. Bezpieczna wersja utrzymuje otwarte obie ścieżki, dowodzi, że prywatna działa z VPN, i dopiero potem wycofuje publiczny endpoint. Załóż istniejący klaster, zatwierdzony tunel do jego VPC i już działający kubeconfig; zadaniem jest prywatny dostęp do API Kubernetes, a nie prywatne węzły i nie nowy model uprawnień. Każdy krok poniżej ma kontrolę, na której można bezpiecznie ponieść porażkę.

1. Zinwentaryzuj endpoint i zachowaj drogę powrotu

Zapisz obecny stan przed zmianą, w tym publiczną listę dozwolonych CIDR i grupę zabezpieczeń klastra. Właśnie te dwa elementy porównasz, gdy coś przestanie działać, a lista dozwolonych jest też twoją drogą wycofania, jeśli prywatna trasa okaże się błędna.

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

REGION i CLUSTER są tu symbolami zastępczymi. Zwróć uwagę, co teraz wskazuje prywatna flaga, ponieważ klaster utworzony z już włączonym prywatnym dostępem wymaga innego pierwszego kroku niż ten, który nigdy go nie miał. Podczas przejścia utrzymuj otwartą co najmniej jedną zatwierdzoną ścieżkę administracyjną; VPN zależny od dostępności tego samego klastra nie jest ścieżką odzyskiwania.

2. Włącz prywatny dostęp, gdy ścieżka sieciowa jest gotowa

Włączenie flagi to łatwiejsza połowa. Tunel potrzebuje trasy do prywatnych adresów endpointu, a grupa zabezpieczeń klastra potrzebuje TCP 443 ze źródła, które VPN faktycznie prezentuje. Powiązanie Client VPN, brama site-to-site i połączony VPC mogą prezentować różne adresy źródłowe, więc użyj modelu, który wdrożyłeś, zamiast ogólnego zakresu prywatnego.

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

Aktualizacja jest asynchroniczna. Odpytuj identyfikator aktualizacji, aż zgłosi sukces, zamiast czekać stałą liczbę sekund i zakładać. Zostaw w spokoju ruch węzłów i płaszczyzny sterowania, gdy to robisz: zastąpienie całej grupy zabezpieczeń klastra regułą dla twojego laptopa to sposób, w jaki działająca płaszczyzna danych staje się drugim incydentem.

Dokumentacja endpointów EKS jest warta jednego pełnego przeczytania, bo mówi, że dostęp wyłącznie prywatny może pochodzić z VPC lub podłączonej sieci. To zdanie jest całym powodem, dla którego ta migracja jest możliwa, i jest też powodem, dla którego istnieje następny krok.

3. Udowodnij, że stacja robocza użyła prywatnej ścieżki

Przy włączonych obu endpointach udane kubectl get ns niczego nie dowodzi co do tego, który odpowiedział. Rozwiąż nazwę hosta endpointu i sprawdź, czy uzyskany adres należy do zakresu prywatnego czy publicznego. Jeśli twoja podłączona sieć nie otrzymuje prywatnego widoku przez DNS, polecenie powiedzie się przez publiczny endpoint i wycofasz publiczną ścieżkę na podstawie fałszywych dowodów. To najczęstszy sposób, w jaki ta migracja idzie źle, i wygląda dokładnie jak sukces.

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

Zachowaj nazwę hosta i weryfikację certyfikatu dokładnie tak, jak są. Podmiana na prywatny adres IP w kubeconfig i pominięcie weryfikacji TLS to nie jest migracja opisana w rejestrze zmian, i znowu zawiedzie w chwili, gdy endpoint się obróci.

4. Wycofaj publiczny dostęp świadomie

Gdy prywatna ścieżka zostanie wykazana, a procedura odzyskiwania zatwierdzona, zamknij publiczny endpoint. To rzeczywista zmiana, a nie podgląd, więc wykonaj ją na koncie i ustawieniach, które naprawdę masz na myśli.

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

W trybie tylko prywatnym publiczna nazwa DNS jest rozwiązywana na prywatne adresy endpointu od wewnątrz VPC, więc rozwiązywanie i osiągalność przestają być tym samym. Wszystko, co polegało na publicznym adresie, w tym runnerzy CI lub laptop w innej sieci, potrzebuje teraz własnej drogi wejścia.

5. Trzymaj politykę sieciową i politykę tożsamości osobno

Lista CIDR dostępu publicznego rządzi tylko publicznym endpointem. Nie ogranicza prywatnego endpointu, który jest zamiast tego ograniczany przez grupę zabezpieczeń klastra i politykę podłączonej sieci. Jeśli zachowasz publiczny endpoint, jego lista dozwolonych musi odpowiadać publicznemu wyjściu, którego naprawdę używają twoi klienci API i węzły; adres z puli VPN rzadko jest tym źródłem.

Nic z tego nie zmienia IAM ani Kubernetes RBAC. Ustawienia endpointu to działanie administracyjne, a zwykli użytkownicy nie powinni otrzymywać uprawnienia do poluzowania granicy tylko po to, by dotrzeć do API. Zapisz stan końcowy, datę i ścieżkę odzyskiwania w runbooku, a następnie przetestuj ścieżkę odzyskiwania raz, dopóki jest jeszcze łatwo.

Powiązane artykuły