Plaas die EKS-API agter 'n VPN: volgorde van bewerkings

Aktiveer die private eindpunt, bewys dat kubectl dit bereik het, sluit dan die publieke een. 'n Gefaseerde runbook met die opdragte en die kontroles tussen elke stap.

Die gevaarlike weergawe van hierdie verandering is een opdrag wat die eindpunt omdraai en elke administrateur tegelykertyd uitsluit. Die veilige weergawe hou beide paaie oop, bewys dat die private een van die VPN af werk, en trek eers dan die publieke eindpunt terug. Aanvaar 'n bestaande cluster, 'n goedgekeurde tonnel na sy VPC en 'n kubeconfig wat reeds werk; die taak is private toegang tot die Kubernetes-API, nie private nodes nie en nie 'n nuwe magtigingsmodel nie. Elke stap hieronder het 'n kontrole waarop jy veilig kan faal.

1. Inventariseer die eindpunt en hou 'n weg terug in

Teken die huidige toestand aan voordat jy dit verander, insluitend die publieke CIDR-toelatingslys en die cluster-sekuriteitsgroep. Dié twee is waarmee jy sal vergelyk wanneer iets ophou werk, en die toelatingslys is ook jou terugrolpad as die private roete verkeerd blyk te wees.

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

REGION en CLUSTER is hier plekhouers. Let op wat die private vlag nou aandui, want 'n cluster wat geskep is met private toegang reeds geaktiveer, benodig 'n ander eerste stap as een wat dit nog nooit gehad het nie. Hou minstens een goedgekeurde administrasiepad oop tydens die oorgang; 'n VPN wat daarvan afhang dat dieselfde cluster bereikbaar is, is nie 'n herstelpad nie.

2. Aktiveer private toegang met die netwerkpad in plek

Om die vlag aan te skakel is die maklike helfte. Die tonnel het 'n roete na die eindpunt se private adresse nodig, en die cluster-sekuriteitsgroep het TCP 443 nodig van die bron wat die VPN werklik aanbied. 'n Client VPN-assosiasie, 'n site-to-site-gateway en 'n peered VPC kan almal verskillende bronadresse aanbied, so gebruik die model wat jy ontplooi het eerder as 'n generiese private reeks.

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

Die opdatering is asinkroon. Peil die opdaterings-id totdat dit sukses rapporteer eerder as om 'n vaste aantal sekondes te wag en te aanvaar. Los node- en beheervlakverkeer alleen terwyl jy dit doen: om die cluster se hele sekuriteitsgroep te vervang met 'n reël vir jou skootrekenaar is hoe 'n werkende data-vlak 'n tweede voorval word.

Die dokumentasie oor EKS-eindpunte is die moeite werd om een keer volledig te lees, want dit sê private-alleen-toegang kan van die VPC of 'n gekoppelde netwerk kom. Daardie sin is die hele rede waarom hierdie migrasie moontlik is, en dit is ook waarom die volgende stap bestaan.

3. Bewys dat die werkstasie die private pad gebruik het

Met beide eindpunte geaktiveer, bewys 'n suksesvolle kubectl get ns niks oor watter een geantwoord het nie. Los die eindpunt se gasheernaam op en kyk of die adres wat jy kry aan die private reeks of die publieke een behoort. As jou gekoppelde netwerk nie die private aansig deur DNS ontvang nie, sal die opdrag oor die publieke eindpunt slaag en sal jy die publieke pad op valse bewyse terugtrek. Dit is die enkele mees algemene manier waarop hierdie migrasie verkeerd loop, en dit lyk presies soos sukses.

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

Hou die gasheernaam en sertifikaatvalidering presies soos dit is. Om 'n private IP in die kubeconfig te vervang en TLS-verifikasie oor te slaan is nie die migrasie wat jy in die veranderingsrekord beskryf het nie, en dit sal weer misluk die oomblik wanneer die eindpunt roteer.

4. Trek publieke toegang doelbewus terug

Sodra die private pad gedemonstreer is en die herstelwerkvloei goedgekeur is, sluit die publieke eindpunt. Dit is 'n werklike verandering eerder as 'n voorskou, so voer dit uit teen die rekening en instellings wat jy werklik bedoel.

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

In private-alleen-modus los die publieke DNS-naam op na die eindpunt se private adresse van binne die VPC, so oplossing en bereikbaarheid hou op om dieselfde ding te wees. Enigiets wat op die publieke adres staatgemaak het, insluitend CI-runners of 'n skootrekenaar op 'n ander netwerk, het nou sy eie pad in nodig.

5. Hou netwerkbeleid en identiteitsbeleid apart

Die publieke-toegang-CIDR-lys beheer slegs die publieke eindpunt. Dit beperk nie die private eindpunt nie, wat eerder deur die cluster-sekuriteitsgroep en die gekoppelde-netwerkbeleid begrens word. As jy die publieke eindpunt behou, moet sy toelatingslys ooreenstem met die publieke uitgang wat jou API-kliënte en nodes werklik gebruik; 'n VPN-poeladres is selde daardie bron.

Niks hiervan verander IAM of Kubernetes RBAC nie. Eindpuntinstellings is 'n administratiewe aksie, en gewone gebruikers moet nie toestemming kry om die grens te verslap net om die API te bereik nie. Skryf die finale toestand, die datum en die herstelpad in die runbook, en toets dan die herstelpad een keer terwyl dit nog maklik is.

Verwante artikels