EC2-യിൽ നിന്ന് സ്വകാര്യ RDS: അതേ VPC, peering അതോ മറ്റെന്തെങ്കിലുമോ?

ഡെവലപ്പറുടെ ലാപ്ടോപ്പ് സ്റ്റാഫ് VPN വഴി സ്വകാര്യ RDS ഇൻസ്റ്റൻസിൽ എത്തുന്നു, എന്നാൽ EC2-ലെ അപ്ലിക്കേഷന് ഒട്ടും കണക്റ്റ് ചെയ്യാൻ കഴിയുന്നില്ല. ഇത് തകർന്ന ഡിപ്ലോയ്മെന്റല്ല. ലാപ്ടോപ്പിൽ EC2 ഇൻസ്റ്റൻസ് ഒരിക്കലും പിന്തുടരാത്ത ഒരു ടണൽ ഉണ്ട്, RDS-ലെ «സ്വകാര്യ» എന്നാൽ ഡാറ്റാബേസിന് പൊതു എൻഡ്പോയിന്റ് ഇല്ല എന്നാണ്, മനുഷ്യ VPN ഉപയോക്താക്കൾ മാത്രമാണ് അനുവദനീയമായ വിളിക്കുന്നവർ എന്നല്ല. ആപ്ലിക്കേഷന് അതിന്റേതായ അംഗീകൃത പാത, സെക്യൂരിറ്റി ഗ്രൂപ്പുമായി അതിന്റേതായ ബന്ധം, ഡാറ്റാബേസിൽ അതിന്റേതായ ഐഡന്റിറ്റി എന്നിവ വേണം, ഈ മൂന്നും തിരഞ്ഞെടുക്കുന്ന ക്രമം ഡീബഗ്ഗിംഗിന്റെ ഭൂരിഭാഗവും ലാഭിക്കുന്നു. ആദ്യം റൂട്ട് തീരുമാനിക്കുക, പിന്നെ അനുമതികൾ, പിന്നെ നിങ്ങളുടെ മേശയിൽ നിന്നല്ല, വിന്യസിച്ച പരിസ്ഥിതിയിൽ നിന്ന് പരിശോധിക്കുക.

ലാപ്ടോപ്പിന്റെ VPN ആപ്ലിക്കേഷന്റെ പാതയല്ല

സ്റ്റാഫ് VPN ആളുകൾക്ക് എന്ത് ചെയ്താലും, ആ ഇൻസ്റ്റൻസ് അതേ നെറ്റ്വർക്ക് പാതയുടെ വ്യക്തമായ ഭാഗമല്ലെങ്കിൽ അത് ഇൻസ്റ്റൻസിന് ഒന്നും ചെയ്യുന്നില്ല. സ്വകാര്യ സബ്നെറ്റിലെ EC2 ഇൻസ്റ്റൻസ് VPC റൂട്ടിംഗ്, സെക്യൂരിറ്റി ഗ്രൂപ്പുകൾ, നെറ്റ്വർക്ക് ACL എന്നിവ വഴി RDS-ൽ എത്തുന്നു. അത് മനുഷ്യന്റെ ടണലോ സെഷനോ ക്രെഡൻഷ്യലുകളോ പിന്തുടരുന്നില്ല, പിന്തുടരരുത്: മേൽനോട്ടമില്ലാത്ത അപ്ലിക്കേഷൻ കണക്റ്റിവിറ്റിയും ജീവനക്കാരുടെ റിമോട്ട് ആക്സസും സ്വതന്ത്രമായി പ്രവർത്തിക്കണം.

ഈ സ്വാതന്ത്ര്യം ഒരു സവിശേഷതയാണ്. VPN ഡൗൺ ആകുമ്പോൾ അപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നത് തുടരുന്നു. അപ്ലിക്കേഷൻ മോശമായി പെരുമാറുമ്പോൾ ആരും റിമോട്ട് ആക്സസ് നഷ്ടപ്പെടുത്തുന്നില്ല. രണ്ടും ഒരു പാതയിലേക്ക് ലയിപ്പിക്കുന്ന രൂപകൽപ്പനകൾ സാധാരണയായി ഒരു സംഭവത്തിനിടയിൽ, ഏറ്റവും മോശം നിമിഷത്തിൽ കണ്ടെത്തുന്നു.

തീരുമാനം 1: അതേ VPC, നേരിട്ടുള്ള പാത

അപ്ലിക്കേഷനും ഡാറ്റാബേസും ഒരേ VPC-യിൽ നേരിട്ടുള്ള റൂട്ടിംഗോടെയും അവയ്ക്കിടയിൽ പരിശോധനാ ഇടനില ഉപകരണമില്ലാതെയും ആകുമ്പോൾ, പാത ലളിതമാണ്, സെക്യൂരിറ്റി ഗ്രൂപ്പ് റഫറൻസ് ലഭ്യമായ ഏറ്റവും ശക്തമായ ഉപകരണമാണ്. അപ്ലിക്കേഷന് അതിന്റേതായ ഗ്രൂപ്പ് നൽകുക, തുടർന്ന് വിലാസ ശ്രേണിയിൽ നിന്നല്ല, ആ ഗ്രൂപ്പിൽ നിന്ന് ഡാറ്റാബേസ് പോർട്ട് അനുവദിക്കുക:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

പോർട്ട് ഉദാഹരണത്തിനുള്ളതാണ്, എഞ്ചിനുമായി പൊരുത്തപ്പെടണം. ഗ്രൂപ്പ് റഫറൻസ് അപ്ലിക്കേഷന്റെ ഇൻസ്റ്റൻസുകളിൽ നിന്നുള്ള ട്രാഫിക്കിന് അനുമതി നൽകുന്നു; അത് അവയുടെ നിയമങ്ങൾ പകർത്തുന്നില്ല, ഡാറ്റാബേസ് ലോഗിൻ സൃഷ്ടിക്കുന്നുമില്ല. രണ്ട് വെവ്വേറെ പ്രശ്നങ്ങൾ, രണ്ട് വെവ്വേറെ പരിഹാരങ്ങൾ.

തുടർന്ന് നിങ്ങൾ ഇപ്പോൾ ചേർത്ത നിയമത്തിൽ നിൽക്കാതെ പാതയുടെ ബാക്കി പരിശോധിക്കുക. അപ്ലിക്കേഷന്റെ ഔട്ട്ബൗണ്ട് നയം, ഡാറ്റാബേസുമായി ബന്ധിപ്പിച്ച ഗ്രൂപ്പുകളുടെ പൂർണ്ണ ഗണം, സബ്നെറ്റ് റൂട്ട് ടേബിളുകൾ, ഏതെങ്കിലും നെറ്റ്വർക്ക് ACL എന്നിവയെല്ലാം ഒത്തുപോകണം. സെക്യൂരിറ്റി ഗ്രൂപ്പ് നിയമങ്ങൾ സ്റ്റേറ്റ്ഫുൾ ആണ്, അതേസമയം ഇഷ്ടാനുസൃത നെറ്റ്വർക്ക് ACL അഭ്യർത്ഥനയും തിരിച്ചുള്ള ട്രാഫിക്കും വെവ്വേറെ നിയമങ്ങളിൽ അനുവദിക്കണം, താൽക്കാലിക പോർട്ടുകൾ ഉൾപ്പെടെ. പുതിയ ഇടുങ്ങിയ ഡാറ്റാബേസ് നിയമം മുമ്പ് ബന്ധിപ്പിച്ച പഴയ വിശാലമായ അനുമതിയും റദ്ദാക്കുന്നില്ല.

തീരുമാനം 2: മറ്റൊരു VPC അല്ലെങ്കിൽ മറ്റൊരു അക്കൗണ്ട്

അപ്ലിക്കേഷൻ മറ്റൊരു VPC-യിലാണെങ്കിൽ, നെറ്റ്വർക്ക് ഉടമകൾ പിന്തുണയ്ക്കുന്ന സ്വകാര്യ ഇന്റർകണക്റ്റ് തിരഞ്ഞെടുക്കുന്നു: peering, ട്രാൻസിറ്റ് രൂപകൽപ്പന അല്ലെങ്കിൽ പങ്കിട്ട VPC ക്രമീകരണം. അപ്പോൾ റൂട്ടിംഗിന്റെ രണ്ട് ദിശകളും ഉണ്ടായിരിക്കണം, നാമ പരിഹാരം RDS എൻഡ്പോയിന്റിനായി പ്രവർത്തിക്കണം, ഡാറ്റാബേസ് നയം വിലയിരുത്തുന്ന ഉറവിടം യഥാർത്ഥത്തിൽ എത്തുന്നതുമായി പൊരുത്തപ്പെടണം. അക്കൗണ്ട് പേരുകൾ ഒത്തുപോകുന്നതോ പങ്കിട്ട ബില്ലിംഗ് ബന്ധമോ ഇവയൊന്നും നൽകുന്നില്ല.

സെക്യൂരിറ്റി ഗ്രൂപ്പ് റഫറൻസാണ് വ്യത്യാസപ്പെടുന്ന ഭാഗം. ഇത് നിരവധി സ്വകാര്യ ഇന്റർകണക്റ്റ് രൂപകൽപ്പനകളിൽ പ്രവർത്തിക്കുന്നു, എന്നാൽ ഒരു ഇടനില ഉപകരണം ഉറവിടം വീണ്ടും എഴുതുകയോ കണക്ഷൻ അവസാനിപ്പിക്കുകയോ ചെയ്യുന്ന നിമിഷം പ്രവർത്തിക്കുന്നത് നിർത്തുന്നു, കാരണം അപ്പോൾ ഡാറ്റാബേസ് നിങ്ങളുടെ അപ്ലിക്കേഷൻ ഗ്രൂപ്പിനെയല്ല, ഇടനില ഉപകരണത്തെയാണ് കാണുന്നത്. RDS VPC സാഹചര്യങ്ങൾ ഒരേ VPC-യിലെ ആക്സസിനെ മറ്റ് ക്രമീകരണങ്ങളിൽ നിന്ന് വേർതിരിക്കുന്നു, നിയമ ശൈലി കൈമാറ്റം ചെയ്യുമെന്ന് അനുമാനിക്കുന്നതിന് മുമ്പ് നിങ്ങളുടെ പ്രത്യേക ടോപ്പോളജി അവയ്ക്കെതിരെ പരിശോധിക്കുന്നത് മൂല്യവത്താണ്.

വിട്ടുപോയ പാത ഡാറ്റാബേസ് പൊതുവായി ആക്സസ് ചെയ്യാവുന്നതാക്കി പരിഹരിക്കരുത്. അത് വേറെ ഉടമയുള്ള വേറെ എക്സ്പോഷർ തീരുമാനമാണ്, സാധാരണയായി അനന്തരഫലത്തിൽ നിന്ന് ഏറ്റവും അകലെയുള്ളയാളാണ് അത് നിർദ്ദേശിക്കുന്നത്.

തീരുമാനം 3: ഏത് ഐഡന്റിറ്റിയാണ് ഡാറ്റാബേസ് അംഗീകരിക്കുന്നത്

നെറ്റ്വർക്ക് ആക്സസും ഡാറ്റാബേസ് ഓതന്റിക്കേഷനും വെവ്വേറെ പാളികളാണ്, അവ കൂട്ടിച്ചേർക്കുന്നത് ഏറ്റവും തെറ്റിദ്ധരിപ്പിക്കുന്ന പിശകുകൾ സൃഷ്ടിക്കുന്നു. ഇൻസ്റ്റൻസ് റോൾ AWS API വിളിക്കാനുള്ള AWS ഐഡന്റിറ്റിയാണ്. അത് ഡാറ്റാബേസ് ഉപയോക്താവല്ല. IAM ഡാറ്റാബേസ് ഓതന്റിക്കേഷൻ എഞ്ചിനും കോൺഫിഗറേഷനും അനുവദിക്കുന്നിടത്ത് പിന്തുണയ്ക്കുന്ന സവിശേഷതയാണ്, അത് ഇപ്പോഴും ഡാറ്റാബേസ് ഉപയോക്താവിലേക്കുള്ള മാപ്പിംഗാണ്, അതിന്റെ പകരമല്ല.

ഒരു തിരയലിൽ നിന്ന് പിടിച്ച വിലാസത്തിന് പകരം അപ്ലിക്കേഷന്റെ കോൺഫിഗറേഷനിൽ RDS എൻഡ്പോയിന്റ് നാമം ഉപയോഗിക്കുക. Multi-AZ ഫെയിൽഓവർ ആ പേരിന് പിന്നിലെ വിലാസം മാറ്റുന്നു, IP-യിൽ പിന്നിച്ച അപ്ലിക്കേഷൻ അത് ആവശ്യമായ കൃത്യമായ നിമിഷത്തിൽ പരാജയപ്പെടും. പിശക് അപ്രത്യക്ഷമാക്കാൻ എഞ്ചിന്റെ TLS പരിശോധന ഓഫ് ചെയ്യുന്നതിന് പകരം അത് ഓണായി നിലനിർത്തുക, കാരണം പരിശോധനാ പരാജയം നിങ്ങൾ എത്തിയ എൻഡ്പോയിന്റിനെക്കുറിച്ച് എന്തോ പറയുന്നു.

തുടർന്ന് ഡാറ്റാബേസ് അക്കൗണ്ടിന് അപ്ലിക്കേഷന് ആവശ്യമായ ഏറ്റവും കുറഞ്ഞത്, അത് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന സ്കീമയിൽ നൽകുക. ആ ജോലി വിരസമാണ്, അത് ഓഡിറ്റ് ചെയ്യാവുന്നതാണ്, സംഭവ അവലോകനം ചോദിക്കുന്ന ഭാഗം അതാണ്.

വിന്യസിച്ച പരിസ്ഥിതിയിൽ നിന്ന് പരിശോധിക്കുക

ഇൻസ്റ്റൻസിൽ നിന്നോ അതേ ഗ്രൂപ്പ്, സബ്നെറ്റ്, റോൾ എന്നിവയോടെ പ്രവർത്തിക്കുന്ന ടാസ്കിൽ നിന്നോ പരീക്ഷിക്കുക. നാല് പരാജയങ്ങൾ ലാപ്ടോപ്പിൽ നിന്ന് സമാനമായി തോന്നും, അവിടെ നിന്ന് എളുപ്പത്തിൽ വേർതിരിക്കാം: പരിഹരിക്കാത്ത പേര്, സമയം കഴിയുന്ന കണക്ഷൻ, TLS സാധുതാ പരാജയം, നിരസിക്കപ്പെട്ട ഡാറ്റാബേസ് ലോഗിൻ. ഓരോന്നും വ്യത്യസ്ത അതിർത്തിയിലേക്ക് ചൂണ്ടുന്നു, ഏതാണ് നിങ്ങൾക്കുള്ളതെന്ന് അറിയുന്നതിന് മുമ്പ് ഡാറ്റാബേസിന്റെ എക്സ്പോഷർ മാറ്റുന്നത് ഊഹമാണ്.

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

ഇൻസ്റ്റൻസിൽ നിന്ന് കണക്ഷൻ വിജയിക്കുകയും നിങ്ങളുടെ മേശയിൽ നിന്ന് പരാജയപ്പെടുകയും ചെയ്താൽ, അപ്ലിക്കേഷന്റെ പാത കുഴപ്പമില്ല, ശരിയാക്കേണ്ടത് നിങ്ങളുടെ ആക്സസാണ്. രണ്ടിൽ നിന്നും പരാജയപ്പെട്ടാൽ, ക്രെഡൻഷ്യലുകളല്ല, മുകളിലെ ഗ്രൂപ്പ്, റൂട്ട് പരിശോധനകളിൽ നിന്ന് തുടങ്ങുക. ആ ഒരു താരതമ്യം ഈ ടിക്കറ്റുകൾ സൃഷ്ടിക്കുന്ന ഭൂരിഭാഗം ബഹളവും തടയുന്നു.