Privé-RDS vanaf EC2: dezelfde VPC, peering of iets anders?

De laptop van de ontwikkelaar bereikt de privé-RDS-instantie via de VPN van het personeel, maar de applicatie op EC2 kan helemaal geen verbinding maken. Dat is geen kapotte implementatie. De laptop heeft een tunnel die de EC2-instantie nooit erft, en „privé“ in RDS betekent dat de database geen openbaar eindpunt heeft, niet dat menselijke VPN-gebruikers de enige toegestane bellers zijn. De applicatie heeft haar eigen geautoriseerde pad, haar eigen relatie met de beveiligingsgroep en haar eigen database-identiteit nodig, en de volgorde waarin u die drie kiest, bespaart het grootste deel van het debuggen. Bepaal eerst de route, dan de machtigingen, en verifieer dan vanuit de uitgerolde omgeving in plaats van vanaf uw bureau.

De laptop-VPN is niet het pad van de applicatie

Wat de personeels-VPN ook voor mensen doet, voor een instantie doet zij niets, tenzij die instantie expliciet deel uitmaakt van hetzelfde netwerkpad. Een EC2-instantie in een privésubnet bereikt RDS via VPC-routing, beveiligingsgroepen en netwerk-ACL's. Zij erft geen menselijke tunnel, geen menselijke sessie en geen menselijke inloggegevens, en dat zou zij ook niet moeten doen: onbeheerde applicatieconnectiviteit en externe toegang van personeel moeten onafhankelijk operationeel zijn.

Die onafhankelijkheid is een voordeel. Als de VPN uitvalt, blijft de applicatie werken. Als de applicatie zich misdraagt, verliest niemand zijn externe toegang. Ontwerpen die beide in één pad samensmelten, worden meestal tijdens een incident ontdekt, op het slechtst mogelijke moment.

Beslissing 1: dezelfde VPC, direct pad

Als de applicatie en de database in dezelfde VPC staan met directe routing en zonder inspectiemiddel ertussen, is het pad eenvoudig en is de verwijzing naar de beveiligingsgroep het sterkste beschikbare instrument. Geef de applicatie haar eigen groep en sta vervolgens de databasepoort toe vanuit die groep in plaats van vanuit een adresbereik:

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

De poort is illustratief en moet bij de engine passen. Een groepsverwijzing autoriseert verkeer van de instanties van de applicatie; zij kopieert hun regels niet en maakt geen databaselogin aan. Twee afzonderlijke problemen, twee afzonderlijke oplossingen.

Controleer daarna de rest van het pad in plaats van te stoppen bij de regel die u zojuist hebt toegevoegd. Het uitgaande beleid van de applicatie, de volledige set groepen die aan de database zijn gekoppeld, de routetabellen van het subnet en eventuele netwerk-ACL's moeten allemaal overeenkomen. Beveiligingsgroepregels zijn stateful, terwijl een aangepaste netwerk-ACL het verzoek en het retourverkeer in afzonderlijke regels moet toestaan, inclusief efemere poorten. Een smalle nieuwe databaseregel heft ook geen oudere brede toestemming op die al was gekoppeld.

Beslissing 2: een andere VPC of een ander account

Als de applicatie in een andere VPC staat, kiezen de netwerkeigenaren een ondersteunde privéverbinding: peering, een transitontwerp of een gedeelde VPC-regeling. Dan moeten beide richtingen van routing bestaan, naamresolutie moet werken voor het RDS-eindpunt, en de bron die het databasebeleid evalueert, moet overeenkomen met wat werkelijk aankomt. Overeenkomende accountnamen of een gedeelde facturatieverhouding leveren niets daarvan.

De verwijzing naar de beveiligingsgroep is het deel dat varieert. Zij werkt in verschillende ontwerpen voor privéverbindingen, maar houdt op te werken op het moment dat een tussenkast de bron herschrijft of de verbinding beëindigt, omdat de database dan de tussenkast ziet in plaats van uw applicatiegroep. De RDS VPC-scenario's scheiden toegang binnen dezelfde VPC van de andere regelingen, en het is de moeite waard uw specifieke topologie daartegen te controleren voordat u aanneemt dat een regelstijl meegaat.

Los een ontbrekende route niet op door de database openbaar toegankelijk te maken. Dat is een andere blootstellingsbeslissing met een andere eigenaar, en zij wordt meestal voorgesteld door degene die het verst van de consequentie af staat.

Beslissing 3: welke identiteit de database accepteert

Netwerktoegang en database-authenticatie zijn afzonderlijke lagen, en het vermengen ervan levert de meest misleidende fouten op. De instantierol is een AWS-identiteit om AWS-API's aan te roepen. Het is geen databasegebruiker. IAM-database-authenticatie is een ondersteunde functie waar de engine en configuratie het toestaan, en het blijft een toewijzing aan een databasegebruiker, geen vervanging.

Gebruik de naam van het RDS-eindpunt in de configuratie van de applicatie in plaats van een adres dat uit één opzoeking is gehaald. Multi-AZ-failover verandert het adres achter die naam, en een applicatie die aan een IP is vastgezet, zal precies op het moment dat zij nodig is falen. Laat de TLS-verificatie van de engine aan staan in plaats van haar uit te schakelen om een fout te laten verdwijnen, want een verificatiefout vertelt u iets over het eindpunt dat u hebt bereikt.

Geef daarna het databaseaccount het minimum dat de applicatie nodig heeft, in het schema dat zij werkelijk gebruikt. Dat werk is saai, het is controleerbaar, en het is het deel waarover een incidentbeoordeling zal vragen.

Verifieer vanuit de uitgerolde omgeving

Test vanaf de instantie of vanaf een taak die met dezelfde groep, hetzelfde subnet en dezelfde rol draait. Vier fouten lijken vanaf een laptop op elkaar en zijn daar gemakkelijk te onderscheiden: een naam die niet wordt opgelost, een verbinding die een time-out krijgt, een TLS-validatiefout en een geweigerde databaselogin. Elk wijst op een andere grens, en het wijzigen van de blootstelling van de database voordat u weet welke u hebt, is giswerk.

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

Als de verbinding vanaf de instantie lukt en vanaf uw bureau mislukt, is het pad van de applicatie in orde en is uw toegang hetgeen moet worden gerepareerd. Als zij vanaf beide mislukt, begin dan met de groep- en routecontroles hierboven in plaats van met de inloggegevens. Die ene vergelijking voorkomt het grootste deel van de rompslomp die deze tickets veroorzaken.