Դնել EKS API-ն VPN-ի հետևում. գործողությունների հաջորդականությունը

Այս փոփոխության վտանգավոր տարբերակը մեկ հրաման է, որը շրջում է վերջնակետը և միաժամանակ կողպում բոլոր ադմինիստրատորներին։ Անվտանգ տարբերակը բաց է պահում երկու ուղիները, ապացուցում, որ մասնավորը աշխատում է VPN-ից, և միայն դրանից հետո է դուրս բերում հանրային վերջնակետը։ Ենթադրեք գոյություն ունեցող կլաստեր, դրա VPC-ի հաստատված թունել և արդեն աշխատող kubeconfig. խնդիրը Kubernetes API-ի մասնավոր հասանելիությունն է, ոչ մասնավոր հանգույցները և ոչ նոր թույլտվությունների մոդել։ Ստորև բերված յուրաքանչյուր քայլ ունի ստուգում, որտեղ կարող եք անվտանգ ձախողվել։

1. Գույքագրեք վերջնակետը և պահեք վերադարձի ուղին

Գրանցեք ընթացիկ վիճակը նախքան այն փոխելը, ներառյալ հանրային CIDR թույլատրելիների ցանկը և կլաստերի անվտանգության խումբը։ Հենց այս երկուսի հետ եք համեմատելու, երբ ինչ-որ բան դադարի աշխատել, և թույլատրելիների ցանկը նաև ձեր հետադարձ ուղին է, եթե մասնավոր երթուղին սխալ պարզվի։

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

REGION-ը և CLUSTER-ը այստեղ տեղապահներ են։ Ուշադրություն դարձրեք, թե ինչ է հիմա ցույց տալիս մասնավոր դրոշակը, քանի որ արդեն միացված մասնավոր հասանելիությամբ ստեղծված կլաստերը պահանջում է այլ առաջին քայլ, քան այն, որը երբեք չի ունեցել։ Անցման ընթացքում բաց պահեք առնվազն մեկ հաստատված ադմինիստրացիոն ուղի. VPN-ը, որը կախված է նույն կլաստերի հասանելիությունից, վերականգնման ուղի չէ։

2. Միացրեք մասնավոր հասանելիությունը, երբ ցանցային ուղին պատրաստ է

Դրոշակը միացնելը հեշտ կեսն է։ Թունելին պետք է երթուղի դեպի վերջնակետի մասնավոր հասցեները, իսկ կլաստերի անվտանգության խմբին՝ TCP 443 այն աղբյուրից, որը VPN-ը իրականում ներկայացնում է։ Client VPN միավորումը, site-to-site դարպասը և փիր-ված VPC-ն կարող են տարբեր աղբյուրային հասցեներ ներկայացնել, ուստի օգտագործեք ձեր տեղակայած մոդելը՝ ընդհանուր մասնավոր միջակայքի փոխարեն։

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

Թարմացումը ասինխրոն է։ Հարցրեք թարմացման id-ին, մինչև այն հաջողություն հաղորդի, փոխարենը՝ ֆիքսված քանակի վայրկյան սպասելու և ենթադրելու։ Այս ընթացքում հանգիստ թողեք հանգույցների և կառավարման հարթության երթևեկությունը. կլաստերի ամբողջ անվտանգության խումբը ձեր նոութբուքի համար կանոնով փոխարինելը այն ուղին է, որով աշխատող տվյալների հարթությունը դառնում է երկրորդ միջադեպ։

EKS վերջնակետերի փաստաթղթերը արժե մեկ անգամ ամբողջությամբ կարդալ, որովհետև ասվում է, որ միայն մասնավոր հասանելիությունը կարող է գալ VPC-ից կամ միացված ցանցից։ Հենց այդ նախադասությունն է այս միգրացիայի հնարավորության ամբողջ պատճառը, և դա է նաև հաջորդ քայլի գոյության պատճառը։

3. Ապացուցեք, որ աշխատանքային կայանը օգտագործել է մասնավոր ուղին

Երկու վերջնակետերն էլ միացված լինելու դեպքում հաջող kubectl get ns-ը ոչինչ չի ապացուցում այն մասին, թե որն է պատասխանել։ Լուծեք վերջնակետի հոսթի անունը և ստուգեք՝ ստացած հասցեն մասնավոր միջակայքին է պատկանում, թե հանրայինին։ Եթե ձեր միացված ցանցը DNS-ի միջոցով չի ստանում մասնավոր տեսքը, հրամանը կհաջողվի հանրային վերջնակետով, և դուք կհեռացնեք հանրային ուղին կեղծ ապացույցի հիման վրա։ Սա այս միգրացիայի սխալ ընթանալու ամենատարածված ձևն է, և այն ուղիղ նման է հաջողության։

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

Պահեք հոսթի անունը և վկայագրի ստուգումը ճիշտ այնպես, ինչպես կան։ kubeconfig-ում մասնավոր IP-ով փոխարինելը և TLS ստուգումը բաց թողնելը այն միգրացիան չէ, որը նկարագրել եք փոփոխությունների գրառման մեջ, և այն նորից կձախողվի այն պահին, երբ վերջնակետը պտտվի։

4. Դիտավորյալ դուրս բերեք հանրային հասանելիությունը

Երբ մասնավոր ուղին ապացուցված է և վերականգնման հոսքը հաստատված, փակեք հանրային վերջնակետը։ Սա իրական փոփոխություն է, ոչ նախադիտում, ուստի գործարկեք այն այն հաշվի և կարգավորումների վրա, որոնք իսկապես նկատի ունեք։

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

Միայն մասնավոր ռեժիմում հանրային DNS անունը լուծվում է վերջնակետի մասնավոր հասցեներին VPC-ի ներսից, ուստի լուծումը և հասանելիությունը դադարում են նույնը լինելուց։ Այն ամենը, ինչ հենվում էր հանրային հասցեի վրա, ներառյալ CI գործարկիչները կամ այլ ցանցում գտնվող նոութբուքը, հիմա իր սեփական ներս մտնելու ուղին է պետք։

5. Առանձին պահեք ցանցային քաղաքականությունը և ինքնության քաղաքականությունը

Հանրային հասանելիության CIDR ցանկը կառավարում է միայն հանրային վերջնակետը։ Այն չի սահմանափակում մասնավոր վերջնակետը, որը փոխարենը սահմանափակվում է կլաստերի անվտանգության խմբով և միացված ցանցի քաղաքականությամբ։ Եթե պահում եք հանրային վերջնակետը, նրա թույլատրելիների ցանկը պետք է համապատասխանի այն հանրային ելքին, որն իրականում օգտագործում են ձեր API հաճախորդները և հանգույցները. VPN լողավազանի հասցեն հազվադեպ է այդ աղբյուրը։

Սրանից ոչինչ չի փոխում IAM-ը կամ Kubernetes RBAC-ը։ Վերջնակետի կարգավորումները վարչական գործողություն են, և սովորական օգտվողները չպետք է թույլտվություն ստանան թուլացնելու սահմանը միայն API-ին հասնելու համար։ Գրեք վերջնական վիճակը, ամսաթիվը և վերականգնման ուղին runbook-ում, ապա մեկ անգամ փորձարկեք վերականգնման ուղին, քանի դեռ այն հեշտ է։