Privat RDS fra EC2: samme VPC, peering eller noe annet?

Utviklerens laptop når den private RDS-forekomsten via personalets VPN, men applikasjonen på EC2 kan ikke koble til i det hele tatt. Dette er ikke en ødelagt utrulling. Laptopen har en tunnel som EC2-forekomsten aldri arver, og «privat» i RDS betyr at databasen ikke har noe offentlig endepunkt, ikke at menneskelige VPN-brukere er de eneste tillatte kallerne. Applikasjonen trenger sin egen autoriserte rute, sitt eget forhold til sikkerhetsgruppen og sin egen databaseidentitet, og rekkefølgen du velger disse tre i, sparer mesteparten av feilsøkingen. Bestem ruten først, deretter tillatelsene, og verifiser deretter fra det utrullede miljøet i stedet for fra skrivebordet ditt.

Laptopens VPN er ikke applikasjonens rute

Uansett hva personalets VPN gjør for mennesker, gjør det ingenting for en forekomst med mindre den forekomsten uttrykkelig er en del av den samme nettverksruten. En EC2-forekomst i et privat subnett når RDS via VPC-ruting, sikkerhetsgrupper og nettverks-ACL-er. Den arver ikke en menneskelig tunnel, en menneskelig økt eller menneskelige påloggingsdata, og det bør den ikke: ubetjent applikasjonstilkobling og personalets fjernakses må kunne drives uavhengig.

Denne uavhengigheten er en fordel. Når VPN er nede, fortsetter applikasjonen å virke. Når applikasjonen oppfører seg dårlig, mister ingen fjernaksesen sin. Design som smelter de to sammen til én rute, oppdages vanligvis under en hendelse, på det verst tenkelige tidspunktet.

Beslutning 1: samme VPC, direkte rute

Når applikasjonen og databasen er i samme VPC med direkte ruting og ingen inspeksjonsboks imellom, er ruten enkel og sikkerhetsgruppereferansen det sterkeste verktøyet som finnes. Gi applikasjonen sin egen gruppe, og tillat deretter databaseporten fra den gruppen i stedet for fra et 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. En gruppereferanse autoriserer trafikk fra applikasjonens forekomster; den kopierer ikke reglene deres og oppretter ikke en databasepålogging. To separate problemer, to separate løsninger.

Deretter kontrollerer du resten av ruten i stedet for å stoppe ved regelen du nettopp la til. Applikasjonens utgående policy, hele settet med grupper knyttet til databasen, subnettets rutetabeller og eventuelle nettverks-ACL-er må alle stemme. Sikkerhetsgrupperegler er stateful, mens en egendefinert nettverks-ACL må tillate forespørselen og returtrafikken i separate regler, inkludert efemere porter. En ny og smal databaseregel opphever heller ikke en eldre bred tillatelse som allerede var knyttet til.

Beslutning 2: en annen VPC eller en annen konto

Hvis applikasjonen er i en annen VPC, velger nettverkseierne en støttet privat forbindelse: peering, et transittdesign eller en delt VPC-ordning. Deretter må begge retninger av ruting finnes, navneoppslag må fungere for RDS-endepunktet, og kilden som databasepolicyen evaluerer, må samsvare med det som faktisk ankommer. Samsvarende kontonavn eller et delt faktureringsforhold gir ingen av disse.

Sikkerhetsgruppereferansen er delen som varierer. Den fungerer i flere design for private forbindelser, men slutter å fungere i det øyeblikket en mellomkasse skriver om kilden eller avslutter tilkoblingen, fordi databasen da ser mellomkassen i stedet for applikasjonsgruppen din. RDS VPC-scenarioene skiller tilgang innenfor samme VPC fra de andre ordningene, og det er verdt å kontrollere din spesifikke topologi mot dem før du antar at en regelstil overføres.

Ikke løs en manglende rute ved å gjøre databasen offentlig tilgjengelig. Det er en annen eksponeringsbeslutning med en annen eier, og den foreslås vanligvis av den som er lengst fra konsekvensen.

Beslutning 3: hvilken identitet databasen godtar

Nettverkstilgang og databaseautentisering er separate lag, og å blande dem gir de mest misvisende feilene. Forekomstrollen er en AWS-identitet for å kalle AWS-API-er. Den er ikke en databasebruker. IAM-databaseautentisering er en støttet funksjon der motoren og konfigurasjonen tillater det, og den er fortsatt en mapping til en databasebruker, ikke en erstatning.

Bruk navnet på RDS-endepunktet i applikasjonens konfigurasjon i stedet for en adresse hentet fra ett oppslag. Multi-AZ-failover endrer adressen bak det navnet, og en applikasjon festet til en IP vil feile nøyaktig i det øyeblikket den trengs. La motorens TLS-verifisering være på i stedet for å slå den av for å få en feil til å forsvinne, fordi en verifiseringsfeil forteller deg noe om endepunktet du nådde.

Gi deretter databasekontoen det minimum applikasjonen trenger, i det skjemaet den faktisk bruker. Det arbeidet er kjedelig, det kan revideres, og det er delen en hendelsesgjennomgang vil spørre om.

Verifiser fra det utrullede miljøet

Test fra forekomsten eller fra en oppgave som kjører med samme gruppe, subnett og rolle. Fire feil ser like ut fra en laptop og er enkle å skille derfra: et navn som ikke løses opp, en tilkobling som får tidsavbrudd, en TLS-valideringsfeil og en avvist databasepålogging. Hver av dem peker på en annen grense, og å endre databasens eksponering før du vet hvilken du har, er gjetting.

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

Hvis tilkoblingen lykkes fra forekomsten og feiler fra skrivebordet ditt, er applikasjonens rute i orden, og tilgangen din er det som må fikses. Hvis den feiler fra begge, begynn med gruppe- og rutekontrollene ovenfor i stedet for med påloggingsdataene. Den ene sammenligningen forhindrer mesteparten av det maset disse sakene skaper.