Posa l’API d’EKS darrere d’una VPN: ordre de les operacions

Activa el punt de connexió privat, demostra que kubectl hi ha arribat i després tanca el públic. Un runbook per fases amb les ordres i les comprovacions entre cada pas.

La versió perillosa d’aquest canvi és una sola ordre que canvia el punt de connexió i bloqueja tots els administradors alhora. La versió segura manté els dos camins oberts, demostra que el privat funciona des de la VPN i només llavors retira el punt de connexió públic. Suposa un clúster existent, un túnel aprovat cap al seu VPC i un kubeconfig que ja funciona; la feina és l’accés privat a l’API de Kubernetes, no els nodes privats ni un model de permisos nou. Cada pas de sota té una comprovació on pots fallar amb seguretat.

1. Inventaria el punt de connexió i guarda una via de tornada

Registra l’estat actual abans de canviar-lo, incloent-hi la llista d’adreces CIDR públiques permeses i el grup de seguretat del clúster. Aquests dos són el que compararàs quan alguna cosa deixi de funcionar, i la llista permesa també és la teva via de reversió si la ruta privada resulta ser incorrecta.

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

REGION i CLUSTER són aquí marcadors de posició. Fixa’t en què indica ara la bandera privada, perquè un clúster creat amb l’accés privat ja activat necessita un primer pas diferent del que mai l’ha tingut. Mantén almenys una via d’administració aprovada oberta durant la transició; una VPN que depèn que el mateix clúster sigui accessible no és una via de recuperació.

2. Activa l’accés privat amb la ruta de xarxa ja preparada

Activar la bandera és la meitat fàcil. El túnel necessita una ruta cap a les adreces privades del punt de connexió, i el grup de seguretat del clúster necessita TCP 443 des de la font que la VPN presenta realment. Una associació de Client VPN, una passarel·la de lloc a lloc i un VPC emparellat poden presentar adreces d’origen diferents, així que fes servir el model que has desplegat en lloc d’un rang privat genèric.

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

L’actualització és asíncrona. Consulta l’identificador d’actualització fins que informi d’èxit en lloc d’esperar un nombre fix de segons i suposar-ho. Deixa el trànsit dels nodes i del pla de control tranquil mentre ho fas: substituir tot el grup de seguretat del clúster per una regla per al teu portàtil és com un pla de dades que funciona es converteix en un segon incident.

La documentació dels punts de connexió d’EKS val la pena llegir-la una vegada sencera, perquè diu que l’accés només privat pot venir del VPC o d’una xarxa connectada. Aquesta frase és tota la raó per la qual aquesta migració és possible, i també és per què existeix el pas següent.

3. Demostra que l’estació de treball va fer servir el camí privat

Amb els dos punts de connexió activats, un kubectl get ns correcte no demostra res sobre quin va respondre. Resol el nom d’amfitrió del punt de connexió i comprova si l’adreça que has obtingut pertany al rang privat o al públic. Si la teva xarxa connectada no rep la visió privada a través de DNS, l’ordre tindrà èxit pel punt de connexió públic i retiraràs el camí públic amb proves falses. Aquesta és la manera més habitual que aquesta migració surti malament, i sembla exactament un èxit.

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

Mantén el nom d’amfitrió i la validació del certificat exactament com són. Substituir una IP privada al kubeconfig i saltar-se la verificació TLS no és la migració que vas descriure al registre de canvis, i tornarà a fallar en el moment que el punt de connexió roti.

4. Retira l’accés públic deliberadament

Un cop demostrat el camí privat i aprovat el flux de recuperació, tanca el punt de connexió públic. Aquest és un canvi real i no una previsualització, així que executa’l contra el compte i la configuració que realment vols.

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

En mode només privat, el nom DNS públic es resol a les adreces privades del punt de connexió des de dins del VPC, així que la resolució i l’abastabilitat deixen de ser la mateixa cosa. Tot el que depenia de l’adreça pública, incloent-hi els executors de CI o un portàtil en una altra xarxa, ara necessita la seva pròpia via d’entrada.

5. Mantén separades la política de xarxa i la política d’identitat

La llista CIDR d’accés públic només governa el punt de connexió públic. No restringeix el punt de connexió privat, que en canvi queda limitat pel grup de seguretat del clúster i la política de la xarxa connectada. Si mantens el punt de connexió públic, la seva llista permesa ha de coincidir amb la sortida pública que els teus clients d’API i nodes fan servir realment; una adreça de pool de VPN poques vegades és aquesta font.

Res d’això no canvia IAM ni Kubernetes RBAC. La configuració del punt de connexió és una acció administrativa, i els usuaris normals no haurien de rebre permís per relaxar el límit només per arribar a l’API. Escriu l’estat final, la data i la via de recuperació al runbook, i després prova la via de recuperació una vegada mentre encara és fàcil.

Articles relacionats