Den farlige versjonen av denne endringen er én kommando som snur endepunktet og låser ute alle administratorer samtidig. Den trygge versjonen holder begge veier åpne, beviser at den private virker fra VPN-en, og trekker først deretter tilbake det offentlige endepunktet. Forutsett et eksisterende klynge, en godkjent tunnel inn i VPC-en og en kubeconfig som allerede virker; jobben er privat tilgang til Kubernetes-API-en, ikke private noder og ikke en ny tillatelsesmodell. Hvert trinn nedenfor har en kontroll du kan feile trygt på.

1. Kartlegg endepunktet og behold en vei tilbake

Registrer dagens tilstand før du endrer den, inkludert den offentlige CIDR-tillatelseslisten og sikkerhetsgruppen til klyngen. Det er disse to du vil sammenligne med når noe slutter å virke, og tillatelseslisten er også veien din tilbake hvis den private ruten viser seg å være feil.

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

REGION og CLUSTER er plassholdere her. Legg merke til hva det private flagget leser nå, fordi en klynge opprettet med privat tilgang allerede aktivert trenger et annet første trinn enn en som aldri har hatt det. Hold minst én godkjent administrasjonsvei åpen under overgangen; en VPN som avhenger av at samme klynge er tilgjengelig, er ikke en gjenopprettingsvei.

2. Aktiver privat tilgang når nettverksveien er på plass

Å slå flagget på er den lette halvdelen. Tunnelen trenger en rute til endepunktets private adresser, og sikkerhetsgruppen til klyngen trenger TCP 443 fra kilden VPN-en faktisk presenterer. En Client VPN-tilknytning, en site-to-site-gateway og en peeret VPC kan alle presentere ulike kildeadresser, så bruk modellen du har rullet ut i stedet for et generisk privat område.

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

Oppdateringen er asynkron. Spør oppdaterings-id-en til den rapporterer suksess i stedet for å vente et fast antall sekunder og anta. La node- og kontrollplantrafikken være i fred mens du gjør dette: å erstatte hele sikkerhetsgruppen til klyngen med en regel for laptopen din er måten en fungerende dataplan blir en ny hendelse.

Dokumentasjonen for EKS-endepunkter er verdt å lese én gang i sin helhet, fordi den sier at tilgang kun via privat nett kan komme fra VPC-en eller et tilkoblet nettverk. Den setningen er hele grunnen til at denne migreringen er mulig, og det er også grunnen til at neste trinn finnes.

3. Bevis at arbeidsstasjonen brukte den private ruten

Med begge endepunktene aktivert beviser en vellykket kubectl get ns ingenting om hvilket som svarte. Slå opp vertsnavnet til endepunktet og kontroller om adressen du fikk tilhører det private eller det offentlige området. Hvis det tilkoblede nettverket ditt ikke mottar den private visningen via DNS, vil kommandoen lykkes over det offentlige endepunktet, og du vil trekke tilbake den offentlige ruten på falske bevis. Det er den enkelt måten denne migreringen oftest går galt, og det ser nøyaktig ut som suksess.

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

Behold vertsnavnet og sertifikatvalideringen nøyaktig som de er. Å bytte til en privat IP i kubeconfig og hoppe over TLS-verifisering er ikke migreringen du beskrev i endringsloggen, og den vil feile igjen i det øyeblikket endepunktet roterer.

4. Trekk tilbake offentlig tilgang med vilje

Når den private ruten er demonstrert og gjenopprettingsflyten godkjent, lukk det offentlige endepunktet. Dette er en reell endring og ikke en forhåndsvisning, så kjør den mot kontoen og innstillingene du faktisk mener.

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

I modusen kun privat løses det offentlige DNS-navnet til endepunktets private adresser fra innsiden av VPC-en, så oppslag og tilgjengelighet slutter å være det samme. Alt som var avhengig av den offentlige adressen, inkludert CI-løpere eller en laptop på et annet nettverk, trenger nå sin egen vei inn.

5. Hold nettverkspolicy og identitetspolicy atskilt

CIDR-listen for offentlig tilgang styrer bare det offentlige endepunktet. Den begrenser ikke det private endepunktet, som i stedet avgrenses av sikkerhetsgruppen til klyngen og policyen for det tilkoblede nettverket. Hvis du beholder det offentlige endepunktet, må tillatelseslisten samsvare med den offentlige utgangen som API-klientene og nodene dine faktisk bruker; en VPN-puljeadresse er sjelden den kilden.

Ingenting av dette endrer IAM eller Kubernetes RBAC. Endepunktinnstillinger er en administrativ handling, og vanlige brukere bør ikke få tillatelse til å lempe på grensen bare for å nå API-en. Skriv sluttilstanden, datoen og gjenopprettingsveien i runbooken, og test deretter gjenopprettingsveien én gang mens den fortsatt er enkel.

Relaterte artikler