Súkromný RDS z EC2: rovnaká VPC, peering alebo niečo iné?

Notebook vývojára sa dostane k súkromnej inštancii RDS cez VPN personálu, ale aplikácia na EC2 sa nedokáže pripojiť vôbec. To nie je pokazené nasadenie. Notebook má tunel, ktorý inštancia EC2 nikdy nezdedí, a „súkromné“ v RDS znamená, že databáza nemá žiadny verejný koncový bod, nie že jedinými povolenými volajúcimi sú ľudskí používatelia VPN. Aplikácia potrebuje vlastnú autorizovanú cestu, vlastný vzťah s bezpečnostnou skupinou a vlastnú identitu v databáze, a poradie, v ktorom tieto tri vyberiete, ušetrí väčšinu ladenia. Najprv rozhodnite trasu, potom povolenia a napokon overte z nasadeného prostredia, nie od svojho stola.

VPN notebooku nie je cesta aplikácie

Čokoľvek VPN personálu robí pre ľudí, pre inštanciu nerobí nič, ak táto inštancia nie je výslovne súčasťou tej istej sieťovej cesty. Inštancia EC2 v súkromnej podsieti dosiahne RDS cez smerovanie VPC, bezpečnostné skupiny a sieťové ACL. Nezdedí ľudský tunel, ľudskú reláciu ani ľudské prihlasovacie údaje a nemala by: neobsluhované pripojenie aplikácií a vzdialený prístup personálu musia byť nezávisle prevádzkyschopné.

Táto nezávislosť je prednosť. Keď VPN nefunguje, aplikácia ďalej pracuje. Keď sa aplikácia správa zle, nikto nestratí vzdialený prístup. Návrhy, ktoré oboje zlievajú do jednej cesty, sa zvyčajne odhalia počas incidentu, v najhoršom možnom okamihu.

Rozhodnutie 1: rovnaká VPC, priama cesta

Keď sú aplikácia a databáza v tej istej VPC s priamym smerovaním a bez kontrolného zariadenia medzi nimi, cesta je jednoduchá a odkaz na bezpečnostnú skupinu je najsilnejší dostupný nástroj. Dajte aplikácii vlastnú skupinu a potom povoľte port databázy z tejto skupiny namiesto z rozsahu adries:

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}'

Port je ilustratívny a musí zodpovedať engine. Odkaz na skupinu autorizuje prevádzku z inštancií aplikácie; nekopíruje ich pravidlá a nevytvára prihlásenie do databázy. Dva oddelené problémy, dve oddelené riešenia.

Potom skontrolujte zvyšok cesty namiesto toho, aby ste sa zastavili pri pravidle, ktoré ste práve pridali. Odchádzajúca politika aplikácie, úplná sada skupín pripojených k databáze, smerovacie tabuľky podsiete a akékoľvek sieťové ACL musia všetky súhlasiť. Pravidlá bezpečnostných skupín sú stavové, zatiaľ čo vlastné sieťové ACL musí povoliť požiadavku a návratovú prevádzku v samostatných pravidlách vrátane efemérnych portov. Úzke nové pravidlo databázy tiež nezruší staršie široké povolenie, ktoré už bolo pripojené.

Rozhodnutie 2: iná VPC alebo iný účet

Ak je aplikácia v inej VPC, vlastníci siete zvolia podporované súkromné prepojenie: peering, tranzitný návrh alebo usporiadanie so zdieľanou VPC. Potom musia existovať oba smery smerovania, preklad názvov musí fungovať pre koncový bod RDS, a zdroj, ktorý vyhodnocuje politika databázy, musí zodpovedať tomu, čo skutočne prichádza. Zhoda názvov účtov alebo zdieľaný fakturačný vzťah nič z toho neposkytujú.

Odkaz na bezpečnostnú skupinu je časť, ktorá sa líši. Funguje v niekoľkých návrhoch súkromného prepojenia, ale prestane fungovať v momente, keď medziľahlé zariadenie prepíše zdroj alebo ukončí spojenie, pretože databáza potom vidí medziľahlé zariadenie, a nie vašu skupinu aplikácie. Scenáre VPC v RDS oddeľujú prístup v tej istej VPC od ostatných usporiadaní a stojí za to overiť svoju konkrétnu topológiu proti nim, než predpokladáte, že sa štýl pravidla prenesie.

Neriešte chýbajúcu trasu tým, že databázu sprístupníte verejne. To je iné rozhodnutie o vystavení s iným vlastníkom a zvyčajne ho navrhuje ten, kto je od dôsledku najďalej.

Rozhodnutie 3: akú identitu databáza prijíma

Sieťový prístup a autentifikácia databázy sú oddelené vrstvy a ich miešanie vytvára najzavádzajúcejšie chyby. Rola inštancie je identita AWS na volanie API AWS. Nie je to používateľ databázy. Autentifikácia databázy cez IAM je podporovaná funkcia tam, kde to engine a konfigurácia dovoľujú, a stále ide o mapovanie na používateľa databázy, nie o jeho nahradenie.

V konfigurácii aplikácie používajte názov koncového bodu RDS namiesto adresy získanej jedným vyhľadaním. Prepnutie pri zlyhaní Multi-AZ mení adresu za týmto názvom a aplikácia pripnutá k IP zlyhá presne v momente, keď je potrebná. Ponechajte overovanie TLS enginu zapnuté, namiesto toho, aby ste ho vypínali, aby chyba zmizla, pretože zlyhanie overenia vám niečo hovorí o koncovom bode, ktorý ste dosiahli.

Potom prideľte účtu databázy minimum, ktoré aplikácia potrebuje, v schéme, ktorú skutočne používa. Tá práca je nudná, je auditovateľná a je to časť, na ktorú sa bude pýtať prehľad incidentu.

Overte z nasadeného prostredia

Testujte z inštancie alebo z úlohy, ktorá beží s rovnakou skupinou, podsietou a rolou. Štyri zlyhania vyzerajú z notebooku podobne a odtiaľ sa dajú ľahko rozlíšiť: názov, ktorý sa nepreloží, spojenie, ktoré vyprší, zlyhanie overenia TLS a odmietnuté prihlásenie do databázy. Každé ukazuje na inú hranicu a meniť vystavenie databázy predtým, než zistíte, ktoré máte, je hádanie.

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

Ak spojenie uspeje z inštancie a zlyhá od vášho stola, cesta aplikácie je v poriadku a opraviť treba váš prístup. Ak zlyhá z oboch miest, začnite kontrolami skupiny a trasy vyššie, nie prihlasovacími údajmi. Toto jediné porovnanie zabráni väčšine zmätku, ktorý tieto tikety vytvárajú.