Set EKS-API-en bak ein VPN: rekkjefølgja av operasjonane

Aktiver det private endepunktet, prov at kubectl nådde det, og lukk deretter det offentlege. Ein trinnvis runbook med kommandoane og kontrollane mellom kvart trinn.

Den farlege versjonen av denne endringa er éin kommando som snur endepunktet og låser ute alle administratorar samstundes. Den trygge versjonen held begge vegane opne, prov at den private verkar frå VPN-en, og dreg først deretter tilbake det offentlege endepunktet. Føreset at det finst eit klynge, ein godkjend tunnel inn i VPC-en og ein kubeconfig som alt verkar; jobben er privat tilgang til Kubernetes-API-en, ikkje private nodar og ikkje ein ny tillatingsmodell. Kvart trinn nedanfor har ein kontroll du kan feile trygt på.

1. Kartlegg endepunktet og hald ein veg tilbake

Registrer dagens tilstand før du endrar han, inkludert den offentlege CIDR-tillatingslista og sikkerheitsgruppa til klynget. Det er desse to du vil samanlikne med når noko sluttar å verke, og tillatingslista er også vegen din tilbake om den private ruta viser seg å vere 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 plasshaldarar her. Legg merke til kva det private flagget les no, fordi eit klynge oppretta med privat tilgang alt aktivert treng eit anna første trinn enn eit som aldri har hatt det. Hald minst éin godkjend administrasjonsveg open under overgangen; ein VPN som er avhengig av at same klynge er tilgjengeleg, er ikkje ein gjenopprettingsveg.

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

Å slå flagget på er den lette halvdelen. Tunnelen treng ei rute til dei private adressene til endepunktet, og sikkerheitsgruppa til klynget treng TCP 443 frå kjelda VPN-en faktisk presenterer. Ei Client VPN-tilknyting, ein site-to-site-gateway og ein peera VPC kan alle presentere ulike kjeldeadresser, så bruk modellen du har rulla ut i staden for eit 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

Oppdateringa er asynkron. Spør oppdaterings-id-en til han rapporterer suksess i staden for å vente eit fast tal sekund og anta. La node- og kontrollplantrafikken vere i fred medan du gjer dette: å byte ut heile sikkerheitsgruppa til klynget med ein regel for laptopen din er måten ein fungerande dataplan blir ei ny hending.

Dokumentasjonen for EKS-endepunkt er verdt å lese éin gong i heilskap, fordi han seier at tilgang berre via privat nett kan kome frå VPC-en eller eit tilkopla nettverk. Den setninga er heile grunnen til at denne migreringa er mogleg, og det er også grunnen til at neste trinn finst.

3. Prov at arbeidsstasjonen brukte den private ruta

Med begge endepunkta aktiverte provar ein vellukka kubectl get ns ingenting om kva som svara. Slå opp vertsnamnet til endepunktet og kontroller om adressa du fekk høyrer til det private eller det offentlege området. Viss det tilkopla nettverket ditt ikkje mottek den private visninga via DNS, vil kommandoen lukkast over det offentlege endepunktet, og du vil dra tilbake den offentlege ruta på falske prov. Det er den einaste måten denne migreringa oftast går gale, og det ser nøyaktig ut som suksess.

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

Hald vertsnamnet og sertifikatvalideringa nøyaktig som dei er. Å byte til ein privat IP i kubeconfig og hoppe over TLS-verifisering er ikkje migreringa du skildra i endringsloggen, og ho vil feile igjen i det augneblunken endepunktet roterer.

4. Dra tilbake offentleg tilgang med vilje

Når den private ruta er demonstrert og gjenopprettingsflyten godkjend, lukk det offentlege endepunktet. Dette er ei reell endring og ikkje ein førehandsvising, så køyr ho mot kontoen og innstillingane du faktisk meiner.

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

I modusen berre privat blir det offentlege DNS-namnet løyst til dei private adressene til endepunktet frå innsida av VPC-en, så oppslag og tilgjenge sluttar å vere det same. Alt som var avhengig av den offentlege adressa, inkludert CI-løparar eller ein laptop på eit anna nettverk, treng no sin eigen veg inn.

5. Hald nettverkspolicy og identitetspolicy skilde

CIDR-lista for offentleg tilgang styrer berre det offentlege endepunktet. Ho avgrensar ikkje det private endepunktet, som i staden blir avgrensa av sikkerheitsgruppa til klynget og policyen for det tilkopla nettverket. Viss du held på det offentlege endepunktet, må tillatingslista hans samsvare med den offentlege utgangen som API-klientane og nodane dine faktisk brukar; ei VPN-puljeadresse er sjeldan den kjelda.

Ingenting av dette endrar IAM eller Kubernetes RBAC. Endepunktinnstillingar er ei administrativ handling, og vanlege brukarar bør ikkje få løyve til å lempe på grensa berre for å nå API-en. Skriv sluttilstanden, datoen og gjenopprettingsvegen i runbooken, og test deretter gjenopprettingsvegen éin gong medan han framleis er enkel.

Relaterte artiklar