Meti la EKS-API malantaŭ VPN: ordo de operacioj

Ŝaltu la privatan finpunkton, pruvu ke kubectl atingis ĝin, poste fermu la publikan. Etapa runlibro kun la komandoj kaj la kontroloj inter ĉiu paŝo.

La danĝera versio de ĉi tiu ŝanĝo estas unu komando, kiu renversas la finpunkton kaj samtempe ŝlosas ĉiun administranton. La sekura versio tenas ambaŭ vojojn malfermitaj, pruvas ke la privata funkcias el la VPN, kaj nur poste retiras la publikan finpunkton. Supozu ekzistantan klusteron, aprobitan tunelon en ĝian VPC kaj kubeconfig-on kiu jam funkcias; la tasko estas privata aliro al la Kubernetes-API, ne privataj nodoj kaj ne nova permesa modelo. Ĉiu paŝo sube havas kontrolon, ĉe kiu vi povas sekure malsukcesi.

1. Inventaru la finpunkton kaj konservu vojon reen

Notu la nunan staton antaŭ ol ŝanĝi ĝin, inkluzive la publikan CIDR-permesliston kaj la sekurecan grupon de la klustero. Tiuj du estas tio, kun kio vi komparos kiam io ĉesas funkcii, kaj la permeslisto ankaŭ estas via retrovojo se la privata itinero montriĝos malĝusta.

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

REGION kaj CLUSTER estas ĉi tie anstataŭigiloj. Rimarku, kion la privata flago legas nun, ĉar klustero kreita kun jam ŝaltita privata aliro bezonas alian unuan paŝon ol unu kiu neniam havis ĝin. Tenu almenaŭ unu aprobitan administran vojon malfermita dum la transiro; VPN kiu dependas de la atingeblo de la sama klustero ne estas reakira vojo.

2. Ŝaltu privatan aliron kun la reta vojo preta

Ŝalti la flagon estas la facila duono. La tunelo bezonas itineron al la privataj adresoj de la finpunkto, kaj la sekureca grupo de la klustero bezonas TCP 443 de la fonto kiun la VPN efektive prezentas. Client VPN-asocio, site-to-site-pordego kaj peerita VPC povas ĉiuj prezenti malsamajn fontadresojn, do uzu la modelon kiun vi deplojis anstataŭ ĝenerala privata gamo.

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

La ĝisdatigo estas nesinkrona. Petu la ĝisdatigan identigilon ĝis ĝi raportos sukceson anstataŭ atendi fiksan nombron da sekundoj kaj supozi. Lasu la trafikon de nodoj kaj de la rega ebeno trankvila dum vi faras tion: anstataŭigi la tutan sekurecan grupon de la klustero per regulo por via tekokomputilo estas la maniero kiel funkcianta datena ebeno fariĝas dua incidento.

La dokumentaro pri EKS-finpunktoj indas unufoje plene legi, ĉar ĝi diras ke aliro nur per privata vojo povas veni el la VPC aŭ el konektita reto. Tiu frazo estas la tuta kialo ke ĉi tiu migrado eblas, kaj ĝi ankaŭ estas la kialo ke la sekva paŝo ekzistas.

3. Pruvu ke la labortablo uzis la privatan vojon

Kun ambaŭ finpunktoj ŝaltitaj, sukcesa kubectl get ns pruvas nenion pri tio, kiu respondis. Solvu la gastigantnomon de la finpunkto kaj kontrolu ĉu la adreso kiun vi ricevis apartenas al la privata aŭ al la publika gamo. Se via konektita reto ne ricevas la privatan vidon per DNS, la komando sukcesos tra la publika finpunkto kaj vi retiros la publikan vojon surbaze de falsaj pruvoj. Tio estas la plej ofta maniero kiel ĉi tiu migrado misfunkcias, kaj ĝi aspektas ekzakte kiel sukceso.

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

Tenu la gastigantnomon kaj la atestilan validigon ekzakte kiel ili estas. Anstataŭigi privatan IP en la kubeconfig kaj preterlasi TLS-validigon ne estas la migrado kiun vi priskribis en la ŝanĝa registro, kaj ĝi denove malsukcesos en la momento kiam la finpunkto rotacias.

4. Retiru la publikan aliron intence

Post kiam la privata vojo estas montrita kaj la reaka laborfluo aprobita, fermu la publikan finpunkton. Ĉi tio estas reala ŝanĝo, ne antaŭrigardo, do plenumu ĝin kontraŭ la konto kaj agordoj kiujn vi efektive celas.

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

En la reĝimo nur privata, la publika DNS-nomo solviĝas al la privataj adresoj de la finpunkto de interne de la VPC, do solvado kaj atingeblo ĉesas esti la sama afero. Ĉio kio dependis de la publika adreso, inkluzive CI-rulilojn aŭ tekokomputilon en alia reto, nun bezonas sian propran eniron.

5. Tenu retan politikon kaj identecan politikon aparte

La CIDR-listo de publika aliro regas nur la publikan finpunkton. Ĝi ne limigas la privatan finpunkton, kiun anstataŭe limigas la sekureca grupo de la klustero kaj la politiko de la konektita reto. Se vi konservas la publikan finpunkton, ĝia permeslisto devas kongrui kun la publika eliro kiun viaj API-klientoj kaj nodoj efektive uzas; adreso de VPN-poolo malofte estas tiu fonto.

Nenio el ĉi tio ŝanĝas IAM aŭ Kubernetes RBAC. Finpunktaj agordoj estas administra ago, kaj ordinaraj uzantoj ne devus ricevi permeson malstreĉi la limon nur por atingi la API. Skribu la finan staton, la daton kaj la reakan vojon en la runlibron, poste testu la reakan vojon unufoje dum ĝi ankoraŭ facilas.

Rilataj artikoloj