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-യിൽ എത്താൻ മാത്രം അതിർത്തി അയയ്ക്കാനുള്ള അനുമതി സാധാരണ ഉപയോക്താക്കൾക്ക് ലഭിക്കരുത്. അന്തിമ അവസ്ഥ, തീയതി, വീണ്ടെടുക്കൽ വഴി എന്നിവ റൺബുക്കിൽ എഴുതുക, തുടർന്ന് ഇപ്പോഴും എളുപ്പമുള്ളപ്പോൾ വീണ്ടെടുക്കൽ വഴി ഒരിക്കൽ പരിശോധിക്കുക.