EKS API ને VPN પાછળ મૂકો: ક્રિયાઓનો ક્રમ

ખાનગી એન્ડપોઇન્ટ સક્ષમ કરો, kubectl તે સુધી પહોંચ્યું તે સાબિત કરો, પછી જાહેર એન્ડપોઇન્ટ બંધ કરો. દરેક પગલા વચ્ચેના આદેશો અને ચકાસણીઓ સાથેનું તબક્કાવાર રનબુક.

આ ફેરફારનું જોખમી સ્વરૂપ એ એક જ આદેશ છે જે એન્ડપોઇન્ટ ફેરવે છે અને એક જ સમયે દરેક વ્યવસ્થાપકને બહાર પરવાનગી બંધ કરી દે છે. સુરક્ષિત સ્વરૂપ બંને માર્ગો ખુલ્લા રાખે છે, ખાનગી માર્ગ 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. નેટવર્ક માર્ગ તૈયાર હોય ત્યારે ખાનગી પ્રવેશ સક્ષમ કરો

ફ્લેગ ચાલુ કરવો સરળ અડધો ભાગ છે. ટનલને એન્ડપોઇન્ટના ખાનગી સરનામાં સુધીનો માર્ગ જોઈએ છે, અને ક્લસ્ટર સુરક્ષા જૂથને VPN ખરેખર રજૂ કરે તે સ્રોતથી TCP 443 જોઈએ છે. Client VPN સંલગ્નતા, સાઇટ-ટુ-સાઇટ ગેટવે અને પીઅર કરેલ 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

અપડેટ અસમકાલિક છે. નિશ્ચિત સેકન્ડો રાહ જોઈને ધારી લેવાને બદલે અપડેટ આઈડી સફળતા જાહેર કરે ત્યાં સુધી પૂછો. આ કરતી વખતે નોડ અને નિયંત્રણ-સ્તરના ટ્રાફિકને એકલું છોડો: ક્લસ્ટરનું આખું સુરક્ષા જૂથ તમારા લેપટોપ માટેના નિયમ સાથે બદલવું એ જ રીતે કાર્યક્ષમ ડેટા સ્તર બીજી ઘટના બની જાય છે.

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 સુધી પહોંચવા માટે સીમા ઢીલી કરવાની પરવાનગી મળવી જોઈએ નહીં. અંતિમ સ્થિતિ, તારીખ અને પુનઃપ્રાપ્તિ માર્ગ રનબુકમાં લખો, પછી પુનઃપ્રાપ્તિ માર્ગ એક વાર તપાસો જ્યારે તે હજી સરળ હોય.

સંબંધિત લેખો