RDS privat din EC2: același VPC, peering sau altceva?

Laptopul dezvoltatorului ajunge la instanța RDS privată prin VPN-ul personalului, dar aplicația de pe EC2 nu se poate conecta deloc. Aceasta nu este o implementare defectă. Laptopul are un tunel pe care instanța EC2 nu îl moștenește niciodată, iar „privat” în RDS înseamnă că baza de date nu are un endpoint public, nu că utilizatorii umani ai VPN sunt singurii apelanți permiși. Aplicația are nevoie de propria rută autorizată, de propria relație cu grupul de securitate și de propria identitate în baza de date, iar ordinea în care alegeți aceste trei economisește cea mai mare parte a depanării. Decideți mai întâi ruta, apoi permisiunile, iar la final verificați din mediul implementat, nu de la biroul dumneavoastră.

VPN-ul laptopului nu este ruta aplicației

Orice ar face VPN-ul personalului pentru oameni, nu face nimic pentru o instanță decât dacă acea instanță face parte în mod explicit din aceeași cale de rețea. O instanță EC2 dintr-un subnet privat ajunge la RDS prin rutarea VPC, grupurile de securitate și ACL-urile de rețea. Nu moștenește tunelul unei persoane, sesiunea unei persoane sau acreditările unei persoane și nici nu ar trebui: conectivitatea aplicațiilor fără supraveghere și accesul la distanță al personalului trebuie să fie operabile independent.

Această independență este un avantaj. Când VPN-ul cade, aplicația continuă să funcționeze. Când aplicația se comportă prost, nimeni nu își pierde accesul la distanță. Proiectele care le unesc pe ambele într-o singură rută sunt de obicei descoperite în timpul unui incident, în cel mai rău moment posibil.

Decizia 1: același VPC, rută directă

Când aplicația și baza de date sunt în același VPC cu rutare directă și fără niciun dispozitiv de inspecție între ele, ruta este simplă, iar referința la grupul de securitate este cel mai puternic instrument disponibil. Dați aplicației propriul grup, apoi permiteți portul bazei de date din acel grup în locul unui interval de adrese:

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

Portul este ilustrativ și trebuie să corespundă motorului. O referință de grup autorizează traficul de la instanțele aplicației; nu copiază regulile acestora și nu creează o autentificare în baza de date. Două probleme separate, două remedieri separate.

Apoi verificați restul rutei în loc să vă opriți la regula pe care tocmai ați adăugat-o. Politica de ieșire a aplicației, setul complet de grupuri atașate bazei de date, tabelele de rutare ale subnetului și orice ACL de rețea trebuie să fie toate de acord. Regulile grupurilor de securitate sunt cu stare, în timp ce un ACL de rețea personalizat trebuie să permită cererea și traficul de retur în reguli separate, inclusiv porturile efemere. O regulă nouă și îngustă pentru bază de date nu anulează nici o permisiune largă mai veche care era deja atașată.

Decizia 2: alt VPC sau alt cont

Dacă aplicația este într-un alt VPC, proprietarii rețelei aleg o interconectare privată acceptată: peering, un proiect de tranzit sau un aranjament de VPC partajat. Apoi trebuie să existe ambele direcții de rutare, rezolvarea numelor trebuie să funcționeze pentru endpointul RDS, iar sursa evaluată de politica bazei de date trebuie să corespundă cu ceea ce ajunge efectiv. Nume de cont identice sau o relație de facturare partajată nu oferă nimic din toate acestea.

Referința la grupul de securitate este partea care variază. Funcționează în mai multe proiecte de interconectare privată, dar încetează să funcționeze în momentul în care un dispozitiv intermediar rescrie sursa sau încheie conexiunea, pentru că baza de date vede atunci dispozitivul intermediar, nu grupul aplicației dumneavoastră. Scenariile VPC din RDS separă accesul în același VPC de celelalte aranjamente și merită să verificați topologia dumneavoastră concretă față de ele înainte de a presupune că un stil de regulă se transferă.

Nu rezolvați o rută lipsă făcând baza de date accesibilă public. Aceasta este o altă decizie de expunere, cu alt proprietar, și de obicei este propusă de cel care este cel mai departe de consecință.

Decizia 3: ce identitate acceptă baza de date

Accesul de rețea și autentificarea în baza de date sunt straturi separate, iar confundarea lor produce cele mai înșelătoare erori. Rolul instanței este o identitate AWS pentru apelarea API-urilor AWS. Nu este un utilizator de bază de date. Autentificarea în baza de date prin IAM este o funcție acceptată acolo unde motorul și configurația o permit și rămâne o mapare către un utilizator de bază de date, nu un substitut.

Folosiți numele endpointului RDS în configurația aplicației în locul unei adrese capturate dintr-o singură căutare. Comutarea la eroare Multi-AZ schimbă adresa din spatele acelui nume, iar o aplicație fixată pe un IP va eșua exact în momentul în care este necesară. Lăsați activă verificarea TLS a motorului în loc să o dezactivați pentru a face o eroare să dispară, pentru că o eroare de verificare vă spune ceva despre endpointul la care ați ajuns.

Apoi acordați contului bazei de date minimul de care are nevoie aplicația, în schema pe care o folosește efectiv. Această muncă este plictisitoare, este auditabilă și este partea despre care va întreba o analiză de incident.

Verificați din mediul implementat

Testați din instanță sau dintr-o sarcină care rulează cu același grup, subnet și rol. Patru eșecuri arată la fel de pe un laptop și se disting ușor de acolo: un nume care nu se rezolvă, o conexiune care expiră, un eșec de validare TLS și o autentificare refuzată în baza de date. Fiecare indică o altă graniță, iar schimbarea expunerii bazei de date înainte de a ști pe care o aveți este ghicit.

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

Dacă conexiunea reușește din instanță și eșuează de la biroul dumneavoastră, ruta aplicației este în regulă și accesul dumneavoastră este ceea ce trebuie reparat. Dacă eșuează din ambele, începeți cu verificările de grup și rută de mai sus, nu cu acreditările. Acea singură comparație previne cea mai mare parte a agitației pe care o generează aceste tichete.