Privat RDS frå EC2: same VPC, peering eller noko anna?

Laptopen til utviklaren når den private RDS-forekomsten via VPN-en til personalet, men applikasjonen på EC2 kan ikkje kople til i det heile. Dette er ikkje ein øydelagd utrulling. Laptopen har ein tunnel som EC2-forekomsten aldri arvar, og «privat» i RDS tyder at databasen ikkje har noko offentleg endepunkt, ikkje at menneskelege VPN-brukarar er dei einaste tillatne kallarane. Applikasjonen treng si eiga autoriserte rute, sitt eige forhold til tryggingsgruppa og sin eigen databaseidentitet, og rekkjefølgja du vel desse tre i, sparar det meste av feilsøkinga. Avgjer ruta først, deretter løyva, og stadfest deretter frå det utrulla miljøet i staden for frå skrivebordet ditt.

VPN-en til laptopen er ikkje ruta til applikasjonen

Kva personalets VPN enn gjer for menneske, gjer det ingenting for ein forekomst med mindre den forekomsten uttrykkeleg er ein del av den same nettverksruta. Ein EC2-forekomst i eit privat subnett når RDS via VPC-ruting, tryggingsgrupper og nettverks-ACL-ar. Han arvar ikkje ein menneskeleg tunnel, ei menneskeleg økt eller menneskelege påloggingsdata, og det bør han ikkje: ubetent applikasjonstilkopling og fjernåtkomst for personalet må kunne drivast uavhengig.

Denne uavhengigheita er ein fordel. Når VPN-en er nede, held applikasjonen fram med å virke. Når applikasjonen oppfører seg dårleg, mistar ingen fjernåtkomsten sin. Design som smeltar dei to saman til éi rute, vert vanlegvis oppdaga under ein hending, på det verste tenkelege tidspunktet.

Avgjerd 1: same VPC, direkte rute

Når applikasjonen og databasen er i same VPC med direkte ruting og inga inspeksjonsboks imellom, er ruta enkel og tryggingsgruppereferansen det sterkaste verktøyet som finst. Gi applikasjonen si eiga gruppe, og tillat deretter databaseporten frå den gruppa i staden for frå eit adresseområde:

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

Porten er illustrativ og må samsvare med motoren. Ein gruppereferanse autoriserer trafikk frå forekomstane til applikasjonen; han kopierer ikkje reglane deira og opprettar ikkje ei databasepålogging. To separate problem, to separate løysingar.

Deretter kontrollerer du resten av ruta i staden for å stoppe ved regelen du nettopp la til. Den utgåande politikken til applikasjonen, heile settet med grupper knytte til databasen, rutetabellane til subnettet og eventuelle nettverks-ACL-ar må alle stemme. Tryggingsgruppereglar er stateful, medan ein eigendefinert nettverks-ACL må tillate førespurnaden og returtrafikken i separate reglar, inkludert efemere portar. Ein ny og smal databaseregel opphevar heller ikkje eit eldre breitt løyve som allereie var knytt til.

Avgjerd 2: ein annan VPC eller ein annan konto

Viss applikasjonen er i ein annan VPC, vel nettverkseigarane ei støtta privat tilknyting: peering, eit transittdesign eller ei delt VPC-ordning. Deretter må begge retningane av ruting finnast, namneoppslag må fungere for RDS-endepunktet, og kjelda som databasepolitikken vurderer, må samsvare med det som faktisk kjem inn. Samsvarande kontonamn eller eit delt faktureringsforhold gir ingen av desse.

Tryggingsgruppereferansen er den delen som varierer. Han fungerer i fleire design for private tilknytingar, men sluttar å fungere i det augneblunken ein mellomkasse skriv om kjelda eller avsluttar tilkoplinga, fordi databasen då ser mellomkassa i staden for applikasjonsgruppa di. RDS VPC-scenarioa skil tilgang innanfor same VPC frå dei andre ordningane, og det er verd å kontrollere den spesifikke topologien din mot dei før du reknar med at ein regelstil vert overført.

Ikkje løys ei manglande rute ved å gjere databasen offentleg tilgjengeleg. Det er ei anna eksponeringsavgjerd med ein annan eigar, og ho vert vanlegvis føreslått av den som er lengst frå konsekvensen.

Avgjerd 3: kva identitet databasen godtek

Nettverkstilgang og databaseautentisering er separate lag, og å blande dei gir dei mest misvisande feila. Forekomstromma er ein AWS-identitet for å kalle AWS-API-ar. Ho er ikkje ein databasebrukar. IAM-databaseautentisering er ein støtta funksjon der motoren og konfigurasjonen tillèt det, og ho er framleis ei kartlegging til ein databasebrukar, ikkje ei erstatning.

Bruk namnet på RDS-endepunktet i konfigurasjonen til applikasjonen i staden for ei adresse henta frå eitt oppslag. Multi-AZ-failover endrar adressa bak det namnet, og ein applikasjon fest til ein IP vil feile nøyaktig i det augneblunken han trengst. La TLS-verifiseringa til motoren stå på i staden for å slå ho av for å få ein feil til å forsvinne, fordi ein verifiseringsfeil fortel deg noko om endepunktet du nådde.

Gi deretter databasekontoen det minimumet applikasjonen treng, i det skjemaet han faktisk brukar. Det arbeidet er keisamt, det kan reviderast, og det er delen ein hendingsgjennomgang vil spørje om.

Stadfest frå det utrulla miljøet

Test frå forekomsten eller frå ei oppgåve som køyrer med same gruppe, subnett og rolle. Fire feil ser like ut frå ein laptop og er enkle å skilje derfrå: eit namn som ikkje vert løyst opp, ei tilkopling som får tidsavbrot, ein TLS-valideringsfeil og ei avvist databasepålogging. Kvar av dei peikar på ei anna grense, og å endre eksponeringa til databasen før du veit kva for ei du har, er gissing.

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

Viss tilkoplinga lukkast frå forekomsten og feilar frå skrivebordet ditt, er ruta til applikasjonen i orden, og tilgangen din er det som må rettast. Viss ho feilar frå båe, byrja med gruppe- og rutekontrollane ovanfor i staden for med påloggingsdataa. Den eine samanlikninga hindrar det meste av det styret desse sakene skapar.