Ilagay ang EKS API sa Likod ng VPN: Ayos ng mga Operasyon

Ang mapanganib na bersyon ng pagbabagong ito ay isang utos na binabaligtad ang endpoint at sabay na nagla-lock sa lahat ng administrator. Ang ligtas na bersyon ay nagpapanatili ng dalawang landas na bukas, nagpapatunay na gumagana ang pribado mula sa VPN, at pagkatapos lamang nito ay inaalis ang pampublikong endpoint. Ipagpalagay na may umiiral na cluster, isang aprubadong tunnel papunta sa VPC nito at isang kubeconfig na gumagana na; ang gawain ay pribadong pag-access sa Kubernetes API, hindi pribadong node at hindi bagong modelo ng permiso. Bawat hakbang sa ibaba ay may pagsusuring maaari mong mabigo nang ligtas.

1. Ilista ang endpoint at magtabi ng daan pabalik

Itala ang kasalukuyang estado bago ito baguhin, kabilang ang pampublikong CIDR allowlist at ang security group ng cluster. Ito ang dalawang ihahambing mo kapag may tumigil sa paggana, at ang allowlist ay daan mo rin pabalik kung ang pribadong ruta ay mali pala.

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

Ang REGION at CLUSTER ay placeholder dito. Pansinin kung ano ang binabasa ng pribadong flag ngayon, dahil ang cluster na ginawa na may pribadong access na naka-enable na ay nangangailangan ng ibang unang hakbang kaysa sa isa na hindi pa ito nagkaroon. Panatilihing bukas ang hindi bababa sa isang aprubadong daan ng administrasyon sa panahon ng paglipat; ang VPN na umaasa na maabot ang parehong cluster ay hindi daan ng pagbawi.

2. Paganahin ang pribadong access kapag nakahanda na ang daan ng network

Ang pag-on ng flag ay ang madaling kalahati. Ang tunnel ay nangangailangan ng ruta patungo sa mga pribadong address ng endpoint, at ang security group ng cluster ay nangangailangan ng TCP 443 mula sa pinagmumulang aktwal na ipinapakita ng VPN. Ang Client VPN association, site-to-site gateway at peered VPC ay maaaring magpakita ng magkakaibang source address, kaya gamitin ang modelong inilagay mo sa halip na pangkalahatang pribadong saklaw.

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

Ang update ay asynchronous. Tanungin ang update id hanggang mag-ulat ito ng tagumpay sa halip na maghintay ng takdang bilang ng segundo at magpalagay. Iwanan ang trapiko ng node at control plane nang payapa habang ginagawa ito: ang pagpapalit ng buong security group ng cluster ng isang patakaran para sa iyong laptop ay ang paraan kung paano nagiging pangalawang insidente ang gumaganang data plane.

Ang dokumentasyon ng mga EKS endpoint ay sulit basahin nang buo isang beses, dahil sinasabi nito na ang pribado-lamang access ay maaaring magmula sa VPC o sa konektadong network. Ang pangungusap na iyon ang buong dahilan kung bakit posible ang migrasyong ito, at ito rin ang dahilan kung bakit may susunod na hakbang.

3. Patunayan na ginamit ng workstation ang pribadong landas

Sa parehong endpoint na naka-enable, ang matagumpay na kubectl get ns ay walang pinatutunayan tungkol sa kung alin ang sumagot. I-resolve ang hostname ng endpoint at tingnan kung ang address na nakuha mo ay kabilang sa pribado o pampublikong saklaw. Kung hindi natatanggap ng konektadong network mo ang pribadong view sa pamamagitan ng DNS, magtatagumpay ang utos sa pampublikong endpoint at aalisin mo ang pampublikong landas batay sa maling ebidensya. Ito ang pinakakaraniwang paraan kung paano napupunta sa mali ang migrasyong ito, at mukhang eksaktong tagumpay.

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

Panatilihin ang hostname at ang validation ng certificate nang eksakto kung ano sila. Ang pagpapalit ng pribadong IP sa kubeconfig at paglaktaw sa TLS verification ay hindi ang migrasyong inilarawan mo sa talaan ng pagbabago, at mabibigo itong muli sa sandaling umikot ang endpoint.

4. Alisin ang pampublikong access nang sadyang

Kapag naipakita na ang pribadong landas at naaprubahan ang daloy ng pagbawi, isara ang pampublikong endpoint. Ito ay tunay na pagbabago at hindi preview, kaya isagawa ito sa account at mga setting na talagang tinutukoy mo.

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

Sa mode na pribado lamang, ang pampublikong DNS name ay nire-resolve sa mga pribadong address ng endpoint mula sa loob ng VPC, kaya hindi na magkapareho ang resolution at reachability. Anumang umaasa sa pampublikong address, kabilang ang mga CI runner o laptop sa ibang network, ay kailangan na ng sariling daan papasok.

5. Paghiwalayin ang patakaran ng network at patakaran ng identidad

Ang CIDR list ng pampublikong access ay namamahala lamang sa pampublikong endpoint. Hindi nito nililimitahan ang pribadong endpoint, na sa halip ay hinahangganan ng security group ng cluster at ng patakaran ng konektadong network. Kung panatilihin mo ang pampublikong endpoint, dapat tumugma ang allowlist nito sa pampublikong egress na aktwal na ginagamit ng iyong API client at node; ang address ng VPN pool ay bihirang maging pinagmulan.

Wala sa mga ito ang nagbabago sa IAM o Kubernetes RBAC. Ang mga setting ng endpoint ay administratibong aksyon, at ang mga ordinaryong user ay hindi dapat tumanggap ng permiso na luwagan ang hangganan para lamang maabot ang API. Isulat ang huling estado, petsa at daan ng pagbawi sa runbook, pagkatapos ay subukan ang daan ng pagbawi nang isang beses habang madali pa.