Privat RDS fra EC2: samme VPC, peering eller noget andet?

Udviklerens laptop når den private RDS-instans via personalets VPN, og applikationen på EC2 kan slet ikke oprette forbindelse. Det er ikke en ødelagt udrulning. Laptoppen har en tunnel, som EC2-instansen aldrig arver, og »privat« i RDS betyder, at databasen ikke har noget offentligt endepunkt, ikke at menneskelige VPN-brugere er de eneste tilladte kaldere. Applikationen har brug for sin egen godkendte rute, sit eget forhold til sikkerhedsgruppen og sin egen databaseidentitet, og den rækkefølge, du vælger de tre i, sparer det meste af fejlfindingen. Beslut ruten først, derefter tilladelserne, og verificér derefter fra det udrullede miljø i stedet for fra dit skrivebord.

Laptoppens VPN er ikke applikationens rute

Uanset hvad personalets VPN gør for mennesker, gør den intet for en instans, medmindre den instans udtrykkeligt er en del af den samme netværksrute. En EC2-instans i et privat undernet når RDS via VPC-routing, sikkerhedsgrupper og netværks-ACL'er. Den arver ikke en menneskelig tunnel, en menneskelig session eller menneskelige legitimationsoplysninger, og det bør den ikke: ubetjent applikationsforbindelse og personalets fjernadgang skal kunne fungere uafhængigt.

Den uafhængighed er en fordel. Når VPN er nede, bliver applikationen ved med at virke. Når applikationen opfører sig forkert, mister ingen deres fjernadgang. Design, der smelter de to sammen til én rute, bliver normalt opdaget under en hændelse, på det værst tænkelige tidspunkt.

Beslutning 1: samme VPC, direkte rute

Når applikationen og databasen er i samme VPC med direkte routing og ingen inspektionsboks imellem, er ruten enkel, og sikkerhedsgruppereferencen er det stærkeste værktøj, der findes. Giv applikationen sin egen gruppe, og tillad derefter databaseporten fra den gruppe 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 skal matche motoren. En gruppereference godkender trafik fra applikationens instanser; den kopierer ikke deres regler, og den opretter ikke et databaselogin. To separate problemer, to separate løsninger.

Kontrollér derefter resten af ruten i stedet for at stoppe ved den regel, du netop har tilføjet. Applikationens udgående politik, databases fulde sæt af tilknyttede grupper, undernettets rutetabeller og eventuelle netværks-ACL'er skal alle stemme overens. Sikkerhedsgrupperegler er stateful, mens en brugerdefineret netværks-ACL skal tillade både anmodningen og returtrafikken i separate regler, inklusive efemere porte. En ny og snæver databaseregel annullerer heller ikke en ældre bred tilladelse, der allerede var tilknyttet.

Beslutning 2: en anden VPC eller en anden konto

Hvis applikationen er i en anden VPC, vælger netværksejerne en understøttet privat forbindelse: peering, et transitdesign eller en delt VPC-ordning. Derefter skal begge retninger af routing findes, navneopløsningen skal virke for RDS-endepunktet, og den kilde, databasepolitikken evaluerer, skal matche det, der faktisk ankommer. Matchende kontonavne eller et delt faktureringsforhold giver ingen af disse ting.

Sikkerhedsgruppereferencen er den del, der varierer. Den virker i flere design til private forbindelser, men holder op med at virke i det øjeblik en mellemboks omskriver kilden eller afslutter forbindelsen, fordi databasen derefter ser mellemboksen i stedet for din applikationsgruppe. RDS VPC-scenarierne adskiller adgang i samme VPC fra de øvrige ordninger, og det er værd at kontrollere din specifikke topologi mod dem, før du antager, at en regelstil overføres.

Løs ikke en manglende rute ved at gøre databasen offentligt tilgængelig. Det er en anden eksponeringsbeslutning med en anden ejer, og den foreslås normalt af den, der er længst fra konsekvensen.

Beslutning 3: hvilken identitet databasen accepterer

Netværksadgang og databasegodkendelse er separate lag, og hvis man blander dem, får man de mest vildledende fejl. Instansrollen er en AWS-identitet til at kalde AWS-API'er. Den er ikke en databasebruger. IAM-databasegodkendelse er en understøttet funktion, hvor motoren og konfigurationen tillader det, og det er stadig en mapping til en databasebruger i stedet for en erstatning.

Brug RDS-endepunktets navn i applikationens konfiguration i stedet for en adresse, der er fanget fra et enkelt opslag. Multi-AZ-failover ændrer adressen bag det navn, og en applikation, der er låst til en IP, vil fejle præcis i det øjeblik, den er nødvendig. Behold motorens TLS-verifikation aktiveret i stedet for at slå den fra for at få en fejl til at forsvinde, fordi en verifikationsfejl fortæller dig noget om det endepunkt, du nåede.

Giv derefter databasekontoen det minimum, applikationen har brug for, i det skema, den faktisk bruger. Det arbejde er kedeligt, det kan revideres, og det er den del, en hændelsesgennemgang vil spørge om.

Verificér fra det udrullede miljø

Test fra instansen eller fra en opgave, der kører med samme gruppe, undernet og rolle. Fire fejl ser ens ud fra en laptop og er nemme at skelne derfra: et navn, der ikke opløses, en forbindelse, der får timeout, en TLS-valideringsfejl og et afvist databaselogin. Hver af dem peger på en forskellig grænse, og at ændre databasens eksponering, før du ved, hvilken du har, er gætværk.

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

Hvis forbindelsen lykkes fra instansen og fejler fra dit skrivebord, er applikationens rute i orden, og din adgang er det, der skal rettes. Hvis den fejler fra begge steder, så start med gruppe- og rutekontrollerne ovenfor i stedet for med legitimationsoplysningerne. Den ene sammenligning forhindrer det meste af det bøvl, disse sager skaber.