Sæt EKS-API’en bag en VPN: rækkefølgen af operationer

Aktivér det private endpoint, bevis at kubectl nåede det, og luk derefter det offentlige. En trinvis runbook med kommandoerne og kontrollerne mellem hvert trin.

Den farlige version af denne ændring er én kommando, der vender endpointet og låser alle administratorer ude på samme tid. Den sikre version holder begge veje åbne, beviser at den private virker fra VPN’en, og trækker først derefter det offentlige endpoint tilbage. Forudsæt et eksisterende klynge, en godkendt tunnel ind i dets VPC og en kubeconfig, der allerede virker; opgaven er privat adgang til Kubernetes-API’en, ikke private noder og ikke en ny tilladelsesmodel. Hvert trin nedenfor har en kontrol, hvor du kan fejle sikkert.

1. Kortlæg endpointet, og behold en vej tilbage

Registrér den nuværende tilstand, før du ændrer den, inklusive den offentlige CIDR-tilladelsesliste og klyngens sikkerhedsgruppe. Det er de to, du vil sammenligne med, når noget holder op med at virke, og tilladelseslisten er også din tilbagerulningsvej, hvis den private rute viser sig at være forkert.

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 pladsholdere her. Læg mærke til, hvad det private flag læser nu, fordi en klynge oprettet med privat adgang allerede aktiveret kræver et andet første trin end en, der aldrig har haft det. Hold mindst én godkendt administrationsvej åben under overgangen; en VPN, der afhænger af, at den samme klynge er tilgængelig, er ikke en gendannelsesvej.

2. Aktivér privat adgang, når netværksvejen er på plads

At slå flaget til er den lette halvdel. Tunnelen skal have en rute til endpointets private adresser, og klyngens sikkerhedsgruppe skal have TCP 443 fra den kilde, VPN’en faktisk præsenterer. En Client VPN-tilknytning, en site-to-site-gateway og et peered VPC kan alle præsentere forskellige kildeadresser, så brug den model, du har udrullet, 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

Opdateringen er asynkron. Spørg opdaterings-id’et, indtil det rapporterer succes, i stedet for at vente et fast antal sekunder og antage. Lad node- og kontrolplans-trafik være i fred, mens du gør dette: at erstatte klyngens hele sikkerhedsgruppe med en regel til din laptop er måden, en fungerende dataplan bliver til en anden hændelse.

Dokumentationen for EKS-endpoints er værd at læse én gang i sin helhed, fordi den siger, at adgang kun via privat netværk kan komme fra VPC’en eller et tilsluttet netværk. Den sætning er hele grunden til, at denne migrering er mulig, og det er også grunden til, at næste trin findes.

3. Bevis, at arbejdsstationen brugte den private vej

Med begge endpoints aktiveret beviser en vellykket kubectl get ns intet om, hvilket der svarede. Slå endpointets værtsnavn op, og kontrollér, om den adresse, du fik, hører til det private eller det offentlige område. Hvis dit tilsluttede netværk ikke modtager den private visning via DNS, vil kommandoen lykkes over det offentlige endpoint, og du vil trække den offentlige vej tilbage på falske beviser. Det er den enkelt mest almindelige måde, denne migrering går galt, og det ligner præcis succes.

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

Behold værtsnavnet og certifikatvalideringen præcis, som de er. At erstatte med en privat IP i kubeconfig og springe TLS-verifikationen over er ikke den migrering, du beskrev i ændringsregistreringen, og den vil fejle igen i det øjeblik, endpointet roterer.

4. Træk offentlig adgang tilbage med vilje

Når den private vej er demonstreret, og gendannelsesarbejdsgangen er godkendt, luk det offentlige endpoint. Dette er en rigtig ændring og ikke en forhåndsvisning, så kør den mod den konto og de indstillinger, du faktisk mener.

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

I tilstanden kun privat opløses det offentlige DNS-navn til endpointets private adresser inde fra VPC’en, så opløsning og tilgængelighed holder op med at være det samme. Alt, der var afhængigt af den offentlige adresse, herunder CI-runnere eller en laptop på et andet netværk, har nu brug for sin egen vej ind.

5. Hold netværkspolitik og identitetspolitik adskilt

CIDR-listen for offentlig adgang styrer kun det offentlige endpoint. Den begrænser ikke det private endpoint, som i stedet afgrænses af klyngens sikkerhedsgruppe og politikken for det tilsluttede netværk. Hvis du beholder det offentlige endpoint, skal dets tilladelsesliste matche den offentlige udgang, som dine API-klienter og noder faktisk bruger; en VPN-puljeadresse er sjældent den kilde.

Intet af dette ændrer IAM eller Kubernetes RBAC. Endpointindstillinger er en administrativ handling, og almindelige brugere bør ikke få tilladelse til at lempe grænsen blot for at nå API’en. Skriv den endelige tilstand, datoen og gendannelsesvejen i runbooken, og test derefter gendannelsesvejen én gang, mens den stadig er let.

Relaterede artikler