Privat RDS från EC2: samma VPC, peering eller något annat?

Utvecklarens laptop når den privata RDS-instansen via personalens VPN, men programmet på EC2 kan inte ansluta alls. Det är inte en trasig driftsättning. Laptopen har en tunnel som EC2-instansen aldrig ärver, och ”privat” i RDS betyder att databasen inte har någon offentlig slutpunkt, inte att mänskliga VPN-användare är de enda tillåtna anroparen. Programmet behöver sin egen auktoriserade väg, sin egen relation till säkerhetsgruppen och sin egen databasidentitet, och ordningen i vilken du väljer dessa tre sparar det mesta av felsökningen. Bestäm rutten först, sedan behörigheterna, och verifiera sedan från den driftsatta miljön i stället för från ditt skrivbord.

Laptopens VPN är inte programmets väg

Oavsett vad personalens VPN gör för människor gör det ingenting för en instans om inte den instansen uttryckligen är en del av samma nätverksväg. En EC2-instans i ett privat undernät når RDS via VPC-routing, säkerhetsgrupper och nätverks-ACL:er. Den ärver inte en mänsklig tunnel, en mänsklig session eller mänskliga autentiseringsuppgifter, och det borde den inte: oövervakad programanslutning och personalens fjärråtkomst måste kunna drivas oberoende av varandra.

Det oberoendet är en fördel. När VPN:en ligger nere fortsätter programmet att fungera. När programmet beter sig illa förlorar ingen sin fjärråtkomst. Design som smälter samman de två till en väg upptäcks vanligtvis under en incident, vid sämsta möjliga tillfälle.

Beslut 1: samma VPC, direkt väg

När programmet och databasen finns i samma VPC med direkt routing och ingen inspektionsbox emellan är vägen enkel och säkerhetsgruppsreferensen det starkaste tillgängliga verktyget. Ge programmet sin egen grupp och tillåt sedan databasporten från den gruppen i stället för från ett adressområ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 är illustrativ och måste matcha motorn. En gruppreferens auktoriserar trafik från programmets instanser; den kopierar inte deras regler och skapar inte en databasinloggning. Två separata problem, två separata åtgärder.

Kontrollera sedan resten av vägen i stället för att stanna vid regeln du just lade till. Programmets utgående policy, hela uppsättningen grupper som är kopplade till databasen, undernätets rutttabeller och eventuella nätverks-ACL:er måste alla stämma. Säkerhetsgruppsregler är tillståndskänsliga, medan en anpassad nätverks-ACL måste tillåta begäran och returtrafiken i separata regler, inklusive efemära portar. En smal ny databasregel upphäver inte heller en äldre bred tillåtelse som redan var kopplad.

Beslut 2: en annan VPC eller ett annat konto

Om programmet finns i en annan VPC väljer nätverksägarna en stödd privat anslutning: peering, en transitdesign eller en delad VPC-lösning. Då måste båda routingriktningarna finnas, namnupplösningen måste fungera för RDS-slutpunkten, och den källa som databaspolicyn utvärderar måste matcha det som faktiskt anländer. Matchande kontonamn eller en delad faktureringsrelation ger inget av detta.

Säkerhetsgruppsreferensen är den del som varierar. Den fungerar i flera designer för privata anslutningar, men slutar fungera i samma ögonblick som en mellanbox skriver om källan eller avslutar anslutningen, eftersom databasen då ser mellanboxen i stället för din programgrupp. RDS VPC-scenarierna skiljer åtkomst inom samma VPC från de andra arrangemangen, och det är värt att kontrollera din specifika topologi mot dem innan du antar att en regelstil överförs.

Lös inte en saknad rutt genom att göra databasen offentligt tillgänglig. Det är ett annat exponeringsbeslut med en annan ägare, och det föreslås vanligtvis av den som står längst från konsekvensen.

Beslut 3: vilken identitet databasen accepterar

Nätverksåtkomst och databasautentisering är separata lager, och att blanda dem ger de mest missvisande felen. Instansrollen är en AWS-identitet för att anropa AWS-API:er. Den är inte en databasanvändare. IAM-databasautentisering är en funktion som stöds där motorn och konfigurationen tillåter det, och den är fortfarande en mappning till en databasanvändare, inte en ersättning.

Använd namnet på RDS-slutpunkten i programmets konfiguration i stället för en adress som hämtats från en enda sökning. Multi-AZ-failover ändrar adressen bakom det namnet, och ett program som är fäst vid en IP kommer att misslyckas precis i det ögonblick det behövs. Låt motorns TLS-verifiering vara på i stället för att stänga av den för att få ett fel att försvinna, eftersom ett verifieringsfel berättar något om slutpunkten du nådde.

Ge sedan databaskontot det minimum som programmet behöver, i det schema det faktiskt använder. Det arbetet är tråkigt, det går att granska, och det är den del som en incidentgranskning kommer att fråga om.

Verifiera från den driftsatta miljön

Testa från instansen eller från en uppgift som körs med samma grupp, undernät och roll. Fyra fel ser likadana ut från en laptop och är lätta att skilja därifrån: ett namn som inte löses upp, en anslutning som får timeout, ett TLS-valideringsfel och en avvisad databasinloggning. Var och en pekar på en annan gräns, och att ändra databasens exponering innan du vet vilken du har är gissning.

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

Om anslutningen lyckas från instansen och misslyckas från ditt skrivbord är programmets väg i ordning och det är din åtkomst som behöver åtgärdas. Om den misslyckas från båda, börja med grupp- och ruttkontrollerna ovan i stället för med autentiseringsuppgifterna. Den enda jämförelsen förhindrar det mesta av det krångel som dessa ärenden skapar.