Stapelübergreifende RDS-Benutzerbereitstellung und Schema-Migrationen mit AWS Lambda

Waren Sie schon einmal in einer Situation, in der Sie Dinge stapelübergreifend bereitstellen oder konfigurieren wollten? Eine Aufteilung in logische Stacks ist immer dann sinnvoll, wenn Sie mit komplexeren Umgebungen zu tun haben. Ich habe dies bereits in einem meiner früheren Blogs beschrieben. Aber das bringt auch ein anderes Problem mit sich!

Zugriff auf Ihre Datenbank gewähren

Wenn Sie DynamoDB verwenden, müssen Sie IAM verwenden, um Zugriff zu gewähren. Andere Datenbanken wie MySQL haben jedoch auch eine interne Authentifizierungsmethode. Sie haben einige Möglichkeiten, wenn Sie die Datenbank in einem Stack erstellen und ein anderer Stack auf die Datenbank zugreifen möchte.

1. Verwenden Sie die Anmeldedaten, die Sie bei der Einrichtung erstellt haben.
2. Verwenden Sie die Identitäts- und Zugriffsverwaltung (AWS IAM).
3. Erstellen Sie einen lokalen Benutzer pro Anwendungsfall.

Nun, alle Optionen werden am Ende funktionieren, aber sie haben ihre Vor- und Nachteile. Ich bin ein großer Fan des Prinzips der geringsten Privilegien. Für mich ist die Verwendung der Anmeldeinformationen, die Sie bei der Einrichtung erstellt haben, zu privilegiert. Mit diesen Zugangsdaten können Sie Datenbanken und Tabellen erstellen. Das bedeutet auch, dass Sie Tabellen löschen und Datenbanken löschen können. Sie können diese Anmeldeinformationen mit den Root-Anmeldeinformationen eines Linux-Systems oder dem Root-Konto für Ihr AWS-Konto vergleichen. Das Root-Konto ist aus einem bestimmten Grund da. Dieser Grund ist nicht für die alltägliche Arbeit. Sie sollten diese Anmeldeinformationen für administrative Aufgaben verwenden, nicht für operative Aufgaben.

Sie können AWS IAM verwenden, und das gibt uns die Möglichkeit, weniger privilegiert zu sein. Das liegt daran, dass Sie einen Benutzer in der Datenbank anlegen müssen. Dieser Benutzer erhält die Berechtigungen, die er in der Datenbank und den Tabellen ausführen kann. Sie können eine Nur-Lese-Rolle erstellen, wenn Sie nur in der Datenbank lesen müssen. Wenn Sie auch schreiben müssen, können Sie diese Berechtigung einfach hinzufügen. Unabhängig davon, ob Sie sich für Option 2 oder 3 entscheiden, müssen Sie immer noch den Benutzer und die Berechtigungen in der Datenbank einrichten.

RDS-Benutzer einrichten

Nachdem Sie eine RDS-Instanz erstellt haben, haben Sie die "Root"-Zugangsdaten für die Datenbank konfiguriert. Der Secrets Manager sollte diese Anmeldeinformationen generieren. Benutzer sollten diese Zugangsdaten nie haben, aber falls doch, sind sie nur für den Fall da. Da wir die Root-Zugangsdaten nicht verwenden möchten, benötigen wir einen Benutzer, der über unsere Anwendung auf die Datenbank zugreift. Hierfür können wir eine Provisioner-Lambda-Funktion verwenden. Diese Lambda-Funktion erstellt die lokalen Benutzer in der Datenbank. Sie können die Lambda-Funktion einfach als benutzerdefinierte Ressource aufrufen, indem Sie die gleiche Vorlage wie die RDS-Instanz verwenden.

Die Lambda-Funktion kann die "Root"-Zugangsdaten von Secrets Manager abrufen. Mit diesen Zugangsdaten kann sie sich mit der Datenbank verbinden, sie erstellen und das anfängliche Schema laden. Als nächstes erstellt sie den Benutzer und die Berechtigungen, die der Benutzer benötigt. Sie brauchen kein Passwort zu vergeben, wenn Sie IAM verwenden möchten. Wenn Sie IAM nicht verwenden möchten, sollten Sie die Anmeldedaten in Secrets Manager erstellen und sie dynamisch an die benutzerdefinierte Ressource übergeben. Danach ist Ihr Benutzer bereit, Ihre Anwendung zu nutzen.

RDS-Benutzer stapelübergreifend einrichten

Was aber, wenn Sie mehrere Stacks haben und die in einem anderen Stack erstellte RDS-Instanz verwenden möchten? Hier gilt das gleiche Prinzip. Sie müssen den Provisioner immer noch mit der RDS-Instanz erstellen. Aber anstatt die benutzerdefinierte Ressource in der Vorlage der RDS-Instanz zu erstellen, erstellen Sie sie in der anderen Vorlage. Hierfür benötigen Sie den ARN der Lambda-Funktion. Sie können ein Benennungsschema verwenden oder den ARN in einem SSM-Parameter speichern.

Dies hat den Vorteil, dass Sie die Erstellung von Datenbankbenutzern in der Vorlage aufrufen können, in der sie verwendet werden. Und wenn Sie den Provisioner intelligent genug machen, können Sie die Berechtigungen, die der Benutzer benötigt, weitergeben. Auf diese Weise kapseln Sie den Benutzer, die Rechte und die Anwendung in ein und derselben Vorlage. Dadurch verringert sich der Wartungsaufwand für Ihre Anwendung und deren Infrastruktur.

Schema-Migrationen

Einer der weiteren Vorteile eines Provisioners ist, dass Sie auch Schemamigrationen verwalten können. Die Änderung des Schemas kann genauso einfach aufgerufen werden wie die Erstellung eines Benutzers. Dies gibt Ihnen die Möglichkeit, diese Migrationen während der CloudFormation-Bereitstellungen durchzuführen. Sie müssen jedoch sicherstellen, dass die Anwendung abwärtskompatibel ist.

Fazit

Die Aufteilung der Infrastruktur in mehrere Stacks sorgt für Ordnung, bringt aber auch Herausforderungen mit sich, wie die Verwaltung von Datenbankzugriffen und Schemaänderungen. Mit einer Lambda-Funktion als Provisioner können Sie die Erstellung von Benutzern und Schemamigrationen als Teil Ihrer CloudFormation-Bereitstellungen automatisieren. Dieser Ansatz sorgt für einen engen Rahmen, gewährleistet das Prinzip der geringsten Privilegien und reduziert den betrieblichen Overhead. Unabhängig davon, ob Sie die IAM-Authentifizierung oder lokale Benutzer verwenden, ist der Provisioner so intelligent, dass er beides handhaben kann und so für Flexibilität sorgt. Mit Schemamigrationen, die in Ihre Bereitstellungen integriert sind, erhalten Sie eine zuverlässige und wiederholbare Möglichkeit, Ihre Datenbank ohne manuelle Eingriffe weiterzuentwickeln.

Foto von Muhammed Ensar