EKS API එක VPN පිටුපස තැබීම: මෙහෙයුම් අනුපිළිවෙල

පෞද්ගලික endpoint සක්‍රීය කරන්න, kubectl එයට ළඟා වූ බව ඔප්පු කරන්න, පසුව පොදු endpoint වසන්න. සෑම පියවරක් අතර විධාන සහ පරීක්ෂණ සහිත පියවරෙන් පියවර රන්බුක්.

මෙම වෙනසෙහි අනතුරුදායක අනුවාදය වන්නේ endpoint එක හරවා එකම වේලාවේ සියලු පරිපාලකයන් අගුලු දමන එකම විධානයකි. ආරක්ෂිත අනුවාදය මාර්ග දෙකම විවෘතව තබා, පෞද්ගලික මාර්ගය VPN සිට ක්‍රියා කරන බව ඔප්පු කර, ඉන් පසුව පමණක් පොදු endpoint ඉවත් කරයි. දැනටමත් ඇති cluster එකක්, එහි VPC වෙත අනුමත tunnel එකක් සහ දැනටමත් ක්‍රියා කරන kubeconfig එකක් උපකල්පනය කරන්න; කාර්යය Kubernetes API වෙත පෞද්ගලික ප්‍රවේශයයි, පෞද්ගලික නෝඩ නොවේ, නව අවසර ආකෘතියක් ද නොවේ. පහත සෑම පියවරකටම ආරක්ෂිතව අසාර්ථක විය හැකි පරීක්ෂණයක් ඇත.

1. Endpoint එක ලැයිස්තුගත කර ආපසු යාමේ මාර්ගයක් තබා ගන්න

වෙනස් කිරීමට පෙර වත්මන් තත්ත්වය සටහන් කරන්න, පොදු CIDR අවසර ලැයිස්තුව සහ cluster ආරක්ෂක කණ්ඩායම ඇතුළුව. යමක් ක්‍රියා කිරීම නතර වූ විට ඔබ සංසන්දනය කරන්නේ මේ දෙකයි, පෞද්ගලික මාර්ගය වැරදි බව පෙනුණහොත් අවසර ලැයිස්තුව ඔබේ ආපසු යාමේ මාර්ගයද වේ.

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

මෙහි REGION සහ CLUSTER ස්ථාන ආදේශක වේ. පෞද්ගලික ධජය දැන් කුමක් කියවනවාදැයි සැලකිල්ලට ගන්න, මන්ද දැනටමත් සක්‍රීය පෞද්ගලික ප්‍රවේශය සහිතව සාදන ලද cluster එකකට කිසිදා එය නොතිබූ එකකට වඩා වෙනස් පළමු පියවරක් අවශ්‍ය වේ. සංක්‍රාන්තිය අතරතුර අවම වශයෙන් එක් අනුමත පරිපාලන මාර්ගයක් විවෘතව තබන්න; එම cluster එකම ළඟා විය හැකි වීම මත රඳා පවතින VPN එකක් ප්‍රතිසාධන මාර්ගයක් නොවේ.

2. ජාල මාර්ගය සූදානම්ව ඇති විට පෞද්ගලික ප්‍රවේශය සක්‍රීය කරන්න

ධජය ක්‍රියාත්මක කිරීම පහසු අර්ධයයි. Tunnel එකට endpoint හි පෞද්ගලික ලිපින වෙත මාර්ගයක් අවශ්‍ය වන අතර, cluster ආරක්ෂක කණ්ඩායමට VPN ඇත්ත වශයෙන්ම ඉදිරිපත් කරන මූලාශ්‍රයෙන් TCP 443 අවශ්‍ය වේ. Client VPN සම්බන්ධතාවය, site-to-site ද්වාරය සහ peer කළ VPC සියල්ලටම විවිධ මූලාශ්‍ර ලිපින ඉදිරිපත් කළ හැක, එබැවින් සාමාන්‍ය පෞද්ගලික පරාසයක් වෙනුවට ඔබ deploy කළ ආකෘතිය භාවිත කරන්න.

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 එක සාර්ථකත්වය වාර්තා කරන තෙක් විමසන්න. මෙය කරන අතරතුර නෝඩ සහ පාලන තලයේ ගමනාගමනය තනිව තබන්න: cluster හි මුළු ආරක්ෂක කණ්ඩායමම ඔබේ ලැප්ටොප් එක සඳහා රීතියකින් ප්‍රතිස්ථාපනය කිරීම ක්‍රියා කරන දත්ත තලයක් දෙවන සිදුවීමක් බවට පත්වන මාර්ගයයි.

EKS endpoint ප්‍රලේඛනය එක් වරක් සම්පූර්ණයෙන් කියවීම වටී, මන්ද එහි පවසන්නේ පෞද්ගලික-පමණ ප්‍රවේශය VPC හෝ සම්බන්ධිත ජාලයකින් පැමිණිය හැකි බවයි. එම වාක්‍යය මෙම සංක්‍රමණය කළ හැකි වීමට මුළු හේතුවයි, ඊළඟ පියවර පවතින්නේ ද එම හේතුව නිසාය.

3. වැඩස්ථානය පෞද්ගලික මාර්ගය භාවිත කළ බව ඔප්පු කරන්න

endpoint දෙකම සක්‍රීය වූ විට, සාර්ථක kubectl get ns එකක් කුමන එක පිළිතුරු දුන්නාද යන්න ගැන කිසිවක් ඔප්පු නොකරයි. endpoint හි hostname එක විසඳා ඔබට ලැබුණු ලිපිනය පෞද්ගලික පරාසයටද පොදු එකටද අයත් දැයි පරීක්ෂා කරන්න. ඔබේ සම්බන්ධිත ජාලයට DNS හරහා පෞද්ගලික දර්ශනය ලැබෙන්නේ නැත්නම්, විධානය පොදු endpoint හරහා සාර්ථක වන අතර ඔබ අසත්‍ය සාක්ෂි මත පොදු මාර්ගය ඉවත් කරනු ඇත. මෙම සංක්‍රමණය වැරදි ලෙස සිදුවන වඩාත් සාමාන්‍ය ක්‍රමය මෙයයි, එය සාර්ථකත්වයට හරියටම සමානය.

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

hostname එක සහ සහතික සත්‍යාපනය ඇති පරිදිම තබන්න. kubeconfig හි පෞද්ගලික IP එකක් ආදේශ කිරීම සහ TLS සත්‍යාපනය මඟ හැරීම ඔබ වෙනස්කම් වාර්තාවේ විස්තර කළ සංක්‍රමණය නොවේ, එය endpoint එක කැරකෙන මොහොතේ නැවතත් අසාර්ථක වනු ඇත.

4. පොදු ප්‍රවේශය හිතාමතාම ඉවත් කරන්න

පෞද්ගලික මාර්ගය ප්‍රදර්ශනය වී ප්‍රතිසාධන කාර්ය ප්‍රවාහය අනුමත වූ පසු පොදු endpoint වසන්න. මෙය පෙරදසුනක් නොව සැබෑ වෙනසකි, එබැවින් ඔබ ඇත්ත වශයෙන් අදහස් කරන ගිණුම සහ සැකසුම් මත එය ධාවනය කරන්න.

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

පෞද්ගලික-පමණ මාදිලියේදී පොදු DNS නාමය VPC ඇතුළතින් endpoint හි පෞද්ගලික ලිපින වෙත විසඳෙයි, එබැවින් විසඳීම සහ ළඟා වීම එකම දෙය නොවේ. පොදු ලිපිනය මත රඳා පැවති සියල්ලට, CI ධාවකයන් හෝ වෙනත් ජාලයක ලැප්ටොප් එකක් ඇතුළුව, දැන් තමන්ගේම පිවිසුම් මාර්ගයක් අවශ්‍යයි.

5. ජාල ප්‍රතිපත්තිය සහ අනන්‍යතා ප්‍රතිපත්තිය වෙන් කර තබන්න

පොදු ප්‍රවේශ CIDR ලැයිස්තුව පාලනය කරන්නේ පොදු endpoint එක පමණි. එය පෞද්ගලික endpoint එක සීමා නොකරයි, එය ඒ වෙනුවට cluster ආරක්ෂක කණ්ඩායම සහ සම්බන්ධිත ජාල ප්‍රතිපත්තිය මගින් සීමා වේ. ඔබ පොදු endpoint තබා ගන්නේ නම්, එහි අවසර ලැයිස්තුව ඔබේ API සේවාලාභීන් සහ නෝඩ ඇත්ත වශයෙන්ම භාවිත කරන පොදු egress සමඟ ගැළපිය යුතුය; VPN තටාක ලිපිනයක් කලාතුරකින් එම මූලාශ්‍රය වේ.

මේවායින් කිසිවක් IAM හෝ Kubernetes RBAC වෙනස් නොකරයි. endpoint සැකසුම් පරිපාලන ක්‍රියාවකි, සාමාන්‍ය පරිශීලකයන්ට API වෙත ළඟා වීමට පමණක් මායිම ලිහිල් කිරීමේ අවසරය ලැබිය යුතු නොවේ. අවසාන තත්ත්වය, දිනය සහ ප්‍රතිසාධන මාර්ගය රන්බුක් එකේ ලියා, පසුව තවමත් පහසු වන විට ප්‍රතිසාධන මාර්ගය එක් වරක් පරීක්ෂා කරන්න.

අදාළ ලිපි