Sätt EKS-API:t bakom en VPN: ordningen på operationerna

Aktivera den privata endpointen, bevisa att kubectl nådde den och stäng sedan den publika. En stegvis runbook med kommandona och kontrollerna mellan varje steg.

Den farliga versionen av den här ändringen är ett enda kommando som vänder endpointen och låser ute alla administratörer samtidigt. Den säkra versionen håller båda vägarna öppna, bevisar att den privata fungerar från VPN:en och drar först därefter tillbaka den publika endpointen. Utgå från ett befintligt kluster, en godkänd tunnel in i dess VPC och en kubeconfig som redan fungerar; jobbet är privat åtkomst till Kubernetes-API:t, inte privata noder och inte en ny behörighetsmodell. Varje steg nedan har en kontroll där du kan misslyckas säkert.

1. Inventera endpointen och behåll en väg tillbaka

Registrera nuvarande tillstånd innan du ändrar det, inklusive den publika CIDR-tillåtelselistan och klustrets säkerhetsgrupp. Det är dessa två du kommer att jämföra med när något slutar fungera, och tillåtelselistan är också din väg tillbaka om den privata rutten visar sig vara fel.

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

REGION och CLUSTER är platshållare här. Lägg märke till vad den privata flaggan läser nu, eftersom ett kluster som skapats med privat åtkomst redan aktiverad behöver ett annat första steg än ett som aldrig har haft det. Håll minst en godkänd administrationsväg öppen under övergången; en VPN som är beroende av att samma kluster går att nå är inte en återställningsväg.

2. Aktivera privat åtkomst när nätverksvägen är på plats

Att slå på flaggan är den lätta halvan. Tunneln behöver en rutt till endpointens privata adresser, och klustrets säkerhetsgrupp behöver TCP 443 från den källa som VPN:en faktiskt presenterar. En Client VPN-koppling, en site-to-site-gateway och ett peerat VPC kan alla presentera olika källadresser, så använd modellen du har rullat ut i stället för ett generiskt privat intervall.

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

Uppdateringen är asynkron. Fråga efter uppdaterings-id:t tills det rapporterar framgång i stället för att vänta ett fast antal sekunder och anta. Låt nod- och kontrollplanstrafiken vara i fred medan du gör detta: att ersätta klustrets hela säkerhetsgrupp med en regel för din laptop är hur ett fungerande dataplan blir en andra incident.

Dokumentationen för EKS-endpoints är värd en fullständig genomläsning, eftersom den säger att åtkomst endast via privat nät kan komma från VPC:n eller ett anslutet nätverk. Den meningen är hela anledningen till att den här migreringen är möjlig, och det är också anledningen till att nästa steg finns.

3. Bevisa att arbetsstationen använde den privata vägen

Med båda endpointsen aktiverade bevisar en lyckad kubectl get ns ingenting om vilken som svarade. Slå upp endpointens värdnamn och kontrollera om adressen du fick tillhör det privata eller det publika intervallet. Om ditt anslutna nätverk inte tar emot den privata vyn via DNS kommer kommandot att lyckas över den publika endpointen, och du drar tillbaka den publika vägen på falska bevis. Det är det enskilt vanligaste sättet den här migreringen går fel, och det ser exakt ut som framgång.

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

Behåll värdnamnet och certifikatvalideringen exakt som de är. Att byta till en privat IP i kubeconfig och hoppa över TLS-verifiering är inte migreringen du beskrev i ändringsloggen, och den kommer att misslyckas igen i samma ögonblick som endpointen roterar.

4. Dra tillbaka publik åtkomst med avsikt

När den privata vägen är demonstrerad och återställningsflödet godkänt, stäng den publika endpointen. Det här är en verklig ändring och inte en förhandsvisning, så kör den mot det konto och de inställningar du faktiskt menar.

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

I läget endast privat löses det publika DNS-namnet till endpointens privata adresser inifrån VPC:n, så uppslagning och nåbarhet är inte längre samma sak. Allt som förlitade sig på den publika adressen, inklusive CI-körare eller en laptop i ett annat nätverk, behöver nu sin egen väg in.

5. Håll nätverkspolicy och identitetspolicy åtskilda

CIDR-listan för publik åtkomst styr bara den publika endpointen. Den begränsar inte den privata endpointen, som i stället avgränsas av klustrets säkerhetsgrupp och policyn för det anslutna nätverket. Om du behåller den publika endpointen måste dess tillåtelselista matcha den publika utgång som dina API-klienter och noder faktiskt använder; en VPN-pooladress är sällan den källan.

Inget av detta ändrar IAM eller Kubernetes RBAC. Endpointinställningar är en administrativ åtgärd, och vanliga användare bör inte få behörighet att lätta på gränsen bara för att nå API:t. Skriv sluttillståndet, datumet och återställningsvägen i runbooken och testa sedan återställningsvägen en gång medan den fortfarande är enkel.

Relaterade artiklar