Puneți API-ul EKS în spatele unui VPN: ordinea operațiunilor

Activați endpointul privat, demonstrați că kubectl l-a atins, apoi închideți endpointul public. Un runbook etapizat cu comenzile și verificările dintre fiecare pas.

Versiunea periculoasă a acestei modificări este o singură comandă care inversează endpointul și blochează toți administratorii în același timp. Versiunea sigură păstrează ambele căi deschise, demonstrează că cea privată funcționează din VPN și abia apoi retrage endpointul public. Presupuneți un cluster existent, un tunel aprobat în VPC-ul acestuia și un kubeconfig care funcționează deja; sarcina este accesul privat la API-ul Kubernetes, nu nodurile private și nu un model nou de permisiuni. Fiecare pas de mai jos are o verificare la care puteți eșua în siguranță.

1. Inventariați endpointul și păstrați o cale de întoarcere

Înregistrați starea actuală înainte de a o schimba, inclusiv lista CIDR publică de adrese permise și grupul de securitate al clusterului. Acestea două sunt cele pe care le veți compara când ceva nu mai funcționează, iar lista de permise este și calea de revenire dacă ruta privată se dovedește greșită.

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

REGION și CLUSTER sunt aici substituenți. Observați ce indică acum indicatorul privat, deoarece un cluster creat cu accesul privat deja activat are nevoie de un prim pas diferit față de unul care nu l-a avut niciodată. Păstrați deschisă cel puțin o cale administrativă aprobată în timpul tranziției; un VPN care depinde de accesibilitatea aceluiași cluster nu este o cale de recuperare.

2. Activați accesul privat cu ruta de rețea pregătită

Aprinderea indicatorului este jumătatea ușoară. Tunelul are nevoie de o rută către adresele private ale endpointului, iar grupul de securitate al clusterului are nevoie de TCP 443 de la sursa pe care VPN-ul o prezintă efectiv. O asociere Client VPN, o poartă site-to-site și un VPC împerecheat pot prezenta adrese de sursă diferite, așa că folosiți modelul pe care l-ați implementat în locul unui interval privat generic.

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

Actualizarea este asincronă. Interogați id-ul actualizării până când raportează succes în loc să așteptați un număr fix de secunde și să presupuneți. Lăsați în pace traficul nodurilor și al planului de control în timp ce faceți asta: înlocuirea întregului grup de securitate al clusterului cu o regulă pentru laptopul dvs. este modul în care un plan de date funcțional devine un al doilea incident.

Documentația endpointurilor EKS merită o citire completă, pentru că spune că accesul doar privat poate veni din VPC sau dintr-o rețea conectată. Acea frază este întregul motiv pentru care această migrare este posibilă și este și motivul pentru care există pasul următor.

3. Demonstrați că stația de lucru a folosit calea privată

Cu ambele endpointuri activate, un kubectl get ns reușit nu demonstrează nimic despre care a răspuns. Rezolvați numele de gazdă al endpointului și verificați dacă adresa obținută aparține intervalului privat sau celui public. Dacă rețeaua dvs. conectată nu primește vederea privată prin DNS, comanda va reuși prin endpointul public și veți retrage calea publică pe baza unor dovezi false. Acesta este cel mai frecvent mod în care această migrare merge prost și arată exact ca un succes.

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

Păstrați numele de gazdă și validarea certificatului exact așa cum sunt. Înlocuirea cu un IP privat în kubeconfig și omiterea verificării TLS nu este migrarea pe care ați descris-o în registrul de modificări și va eșua din nou în momentul în care endpointul se rotește.

4. Retrageți accesul public în mod deliberat

După ce calea privată este demonstrată și fluxul de recuperare aprobat, închideți endpointul public. Aceasta este o modificare reală, nu o previzualizare, așa că rulați-o pe contul și setările pe care chiar le aveți în vedere.

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

În modul doar privat, numele DNS public se rezolvă la adresele private ale endpointului din interiorul VPC-ului, așa că rezolvarea și accesibilitatea nu mai sunt același lucru. Orice se baza pe adresa publică, inclusiv executorii CI sau un laptop într-o altă rețea, are acum nevoie de propria cale de intrare.

5. Țineți politica de rețea și politica de identitate separate

Lista CIDR de acces public guvernează doar endpointul public. Nu restricționează endpointul privat, care este în schimb delimitat de grupul de securitate al clusterului și de politica rețelei conectate. Dacă păstrați endpointul public, lista sa de permise trebuie să corespundă ieșirii publice pe care clienții API și nodurile dvs. o folosesc efectiv; o adresă din pool-ul VPN este rareori acea sursă.

Nimic din toate acestea nu schimbă IAM sau Kubernetes RBAC. Setările endpointului sunt o acțiune administrativă, iar utilizatorii obișnuiți nu ar trebui să primească permisiunea de a relaxa granița doar pentru a ajunge la API. Scrieți starea finală, data și calea de recuperare în runbook, apoi testați calea de recuperare o dată cât timp încă este ușor.

Articole similare