Privates RDS von EC2: gleiche VPC, Peering oder etwas anderes?

Der Laptop des Entwicklers erreicht die private RDS-Instanz über das Mitarbeiter-VPN, doch die Anwendung auf EC2 kann überhaupt keine Verbindung herstellen. Das ist kein kaputtes Deployment. Der Laptop hat einen Tunnel, den die EC2-Instanz nie erbt, und „privat“ bedeutet bei RDS, dass die Datenbank keinen öffentlichen Endpunkt hat, nicht dass menschliche VPN-Nutzer die einzigen erlaubten Aufrufer sind. Die Anwendung braucht ihren eigenen autorisierten Pfad, ihre eigene Beziehung zur Sicherheitsgruppe und ihre eigene Datenbankidentität, und die Reihenfolge, in der Sie diese drei wählen, spart den größten Teil der Fehlersuche. Entscheiden Sie zuerst über die Route, dann über die Berechtigungen, und prüfen Sie anschließend aus der bereitgestellten Umgebung statt von Ihrem Schreibtisch aus.

Das Laptop-VPN ist nicht der Pfad der Anwendung

Was auch immer das Mitarbeiter-VPN für Menschen tut, für eine Instanz tut es nichts, es sei denn, diese Instanz ist ausdrücklich Teil desselben Netzwerkpfads. Eine EC2-Instanz in einem privaten Subnetz erreicht RDS über VPC-Routing, Sicherheitsgruppen und Netzwerk-ACLs. Sie erbt keinen menschlichen Tunnel, keine menschliche Sitzung und keine menschlichen Anmeldedaten, und das sollte sie auch nicht: unbeaufsichtigte Anwendungskonnektivität und der Fernzugriff der Mitarbeiter müssen unabhängig voneinander betreibbar sein.

Diese Unabhängigkeit ist ein Vorteil. Wenn das VPN ausfällt, arbeitet die Anwendung weiter. Wenn sich die Anwendung falsch verhält, verliert niemand seinen Fernzugriff. Entwürfe, die beides zu einem Pfad zusammenlegen, werden meist während eines Vorfalls entdeckt, im schlechtesten möglichen Moment.

Entscheidung 1: gleiche VPC, direkter Pfad

Wenn Anwendung und Datenbank in derselben VPC mit direktem Routing und ohne Inspektions-Middlebox dazwischen liegen, ist der Pfad einfach und die Sicherheitsgruppenreferenz das stärkste verfügbare Werkzeug. Geben Sie der Anwendung ihre eigene Gruppe und erlauben Sie dann den Datenbankport aus dieser Gruppe statt aus einem Adressbereich:

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

Der Port ist illustrativ und muss zur Engine passen. Eine Gruppenreferenz autorisiert Verkehr von den Instanzen der Anwendung; sie kopiert deren Regeln nicht und erstellt keine Datenbankanmeldung. Zwei getrennte Probleme, zwei getrennte Lösungen.

Prüfen Sie dann den Rest des Pfads, statt bei der gerade hinzugefügten Regel stehen zu bleiben. Die ausgehende Richtlinie der Anwendung, der vollständige Satz der an die Datenbank angehängten Gruppen, die Routentabellen des Subnetzes und etwaige Netzwerk-ACLs müssen alle übereinstimmen. Sicherheitsgruppenregeln sind zustandsbehaftet, während eine benutzerdefinierte Netzwerk-ACL die Anfrage und den Rückverkehr in getrennten Regeln zulassen muss, einschließlich der ephemeren Ports. Eine enge neue Datenbankregel hebt außerdem keine ältere breite Freigabe auf, die bereits angehängt war.

Entscheidung 2: andere VPC oder anderes Konto

Liegt die Anwendung in einer anderen VPC, wählen die Netzwerkeigentümer eine unterstützte private Verbindung: Peering, ein Transit-Design oder eine gemeinsame VPC-Regelung. Dann müssen beide Routingrichtungen existieren, die Namensauflösung muss für den RDS-Endpunkt funktionieren, und die Quelle, die die Datenbankrichtlinie auswertet, muss dem entsprechen, was tatsächlich ankommt. Übereinstimmende Kontonamen oder eine gemeinsame Abrechnungsbeziehung liefern davon nichts.

Die Sicherheitsgruppenreferenz ist der Teil, der variiert. Sie funktioniert in mehreren Designs privater Verbindungen, hört aber in dem Moment auf zu funktionieren, in dem eine Middlebox die Quelle umschreibt oder die Verbindung beendet, weil die Datenbank dann die Middlebox statt Ihrer Anwendungsgruppe sieht. Die RDS-VPC-Szenarien trennen den Zugriff innerhalb derselben VPC von den anderen Arrangements, und es lohnt sich, Ihre konkrete Topologie dagegen zu prüfen, bevor Sie annehmen, dass ein Regelstil übertragbar ist.

Lösen Sie eine fehlende Route nicht dadurch, dass Sie die Datenbank öffentlich zugänglich machen. Das ist eine andere Exponierungsentscheidung mit einem anderen Eigentümer, und sie wird meist von demjenigen vorgeschlagen, der am weitesten von der Konsequenz entfernt ist.

Entscheidung 3: welche Identität die Datenbank akzeptiert

Netzwerkzugriff und Datenbankauthentifizierung sind getrennte Schichten, und ihre Vermischung erzeugt die irreführendsten Fehler. Die Instanzrolle ist eine AWS-Identität zum Aufrufen von AWS-APIs. Sie ist kein Datenbankbenutzer. Die IAM-Datenbankauthentifizierung ist eine unterstützte Funktion, wo Engine und Konfiguration sie zulassen, und sie bleibt eine Zuordnung zu einem Datenbankbenutzer statt eines Ersatzes dafür.

Verwenden Sie in der Konfiguration der Anwendung den Namen des RDS-Endpunkts statt einer Adresse, die aus einer einmaligen Abfrage stammt. Ein Multi-AZ-Failover ändert die Adresse hinter diesem Namen, und eine an eine IP gebundene Anwendung scheitert genau in dem Moment, in dem sie gebraucht wird. Lassen Sie die TLS-Verifikation der Engine aktiviert, statt sie abzuschalten, damit ein Fehler verschwindet, denn ein Verifikationsfehler sagt Ihnen etwas über den Endpunkt, den Sie erreicht haben.

Gewähren Sie dem Datenbankkonto dann das Minimum, das die Anwendung benötigt, und zwar im Schema, das sie tatsächlich verwendet. Diese Arbeit ist langweilig, sie ist prüfbar, und sie ist der Teil, nach dem eine Vorfalluntersuchung fragen wird.

Prüfen Sie aus der bereitgestellten Umgebung

Testen Sie von der Instanz aus oder von einer Aufgabe, die mit derselben Gruppe, demselben Subnetz und derselben Rolle läuft. Vier Fehler sehen von einem Laptop aus ähnlich und lassen sich von dort leicht unterscheiden: ein Name, der nicht aufgelöst wird, eine Verbindung, die in einen Timeout läuft, ein TLS-Validierungsfehler und eine abgelehnte Datenbankanmeldung. Jeder weist auf eine andere Grenze hin, und die Exponierung der Datenbank zu ändern, bevor man weiß, welchen man hat, ist Raterei.

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

Wenn die Verbindung von der Instanz gelingt und von Ihrem Schreibtisch aus scheitert, ist der Pfad der Anwendung in Ordnung, und Ihr Zugang ist das, was repariert werden muss. Wenn sie von beiden Stellen scheitert, beginnen Sie mit den Gruppen- und Routenprüfungen oben statt mit den Anmeldedaten. Dieser eine Vergleich verhindert den größten Teil des Aufwands, den diese Tickets erzeugen.