Kontoübergreifender Zugriff auf AWS-Ressourcen mit Terraform

Vor kurzem hatten wir das Problem, dass einer unserer Lambdas eine Pinpoint-Anwendung in einem sekundären Konto erreichen musste. Wir untersuchten eine Reihe verschiedener Optionen, kamen aber schließlich zu dem Schluss, eine Rolle zu verwenden, die Zugriff auf Pinpoint im sekundären Konto hat, und STS zu verwenden, um die Rolle zu übernehmen. Beachten Sie, dass dies die Kontrolle über beide Konten erfordert, da Sie Ressourcen in beiden Konten bereitstellen müssen. Zunächst ein kurzer Überblick über die Lösung: In unserem speziellen Szenario haben wir eine Verbindung zu Pinpoint hergestellt, aber diese Technik kann auch für SES, DynamoDB usw. verwendet werden. Zerlegen wir das in handliche Teile!

Einrichten der Rolle im Pinpoint-Konto

Zunächst erstellen wir eine Rolle im pinpoint-Konto, die berechtigt ist, Operationen in der pinpoint-Anwendung durchzuführen. Nach dem Prinzip der geringsten Berechtigung erlauben wir dem externen Lambda nur das Abrufen und Aktualisieren von Enpoints. Auf diese Weise sind wir sicher, dass das Lambda keine anderen Ressourcen im sekundären Konto beeinflussen kann. Notieren Sie sich den Rollennamen (role-for-external-lambda), da wir diesen im Terraform-Code für das primäre Konto benötigen werden. Die Terraform-Vorlage enthält eine Reihe von Variablen:

• var.region: AWS-Region, in der der Pinpoint bereitgestellt wird
• var.account_id: Die AWS-Kontonummer, unter der Pinpoint gehostet wird (im Übersichtsbild als sekundäres Konto bezeichnet)
• var.pinpoint_app_id: Die Eigenschaft application_id der Pinpoint-Ressource
• var.lambda_account_id: Die AWS-Kontonummer, unter der der Lambda gehostet wird (im Übersichtsbild als primäres Konto bezeichnet)

  Nun, da wir das sekundäre Konto eingerichtet haben, können wir mit dem primären Konto fortfahren.

Dem Lambda erlauben, die Rolle zu übernehmen

Als nächstes erstellen wir eine Richtlinie, die es unserem Lambda im anderen Konto erlaubt, die Rolle im sekundären Konto zu übernehmen. Dazu benötigen wir den ARN der Rolle, die wir im vorherigen Schritt erstellt haben. Wir verknüpfen diese Richtlinie mit dem Lambda über die Eigenschaft managed_policy_arns. Die Terraform-Vorlage verwendet die folgende Variable:

• var.pinpoint_aws_account_id: Die AWS-Kontonummer, unter der Pinpoint bereitgestellt wird (im Übersichtsbild als sekundäres Konto bezeichnet)

Nun, da wir unserem Lambda erlaubt haben, die Remote-Rolle zu übernehmen, können wir mit dem letzten Schritt fortfahren.

Rollenannahme zum Lambda hinzufügen

Wenn wir eine Verbindung zu einer Pinpoint-Anwendung herstellen, die in demselben AWS-Konto läuft, können wir uns normalerweise direkt mit der Anwendung verbinden, indem wir new PinpointClient(). In diesem Fall müssen wir zunächst die Anmeldeinformationen für eine Rollensitzung als die Rolle im sekundären Konto erhalten. Dazu rufen wir den STS-Client auf und geben an, dass wir die Rolle im sekundären Konto übernehmen möchten. Wenn dieser Aufruf erfolgreich ist und Anmeldeinformationen zurückgibt, können wir diese Anmeldeinformationen an den Konstruktor des Pinpoint-Clients weitergeben, der damit eine Verbindung zur Pinpoint-Anwendung im sekundären Konto herstellen kann . Beachten Sie, dass wir die region angeben müssen, in der die Pinpoint-Anwendung bereitgestellt wird.

Einpacken

Wir haben eine dedizierte Rolle für den Zugriff im sekundären Konto erstellt und dem Lambda im primären Konto erlaubt, diese Rolle zu übernehmen. Schließlich fügten wir einen STS-Aufruf zu unserem Lambda hinzu, um Anmeldeinformationen für die Verbindung zu Pinpoint im sekundären Konto zu erhalten. Auf diese Weise können wir sicher eine kontenübergreifende Verbindung herstellen und trotzdem das Prinzip der geringsten Privilegien befolgen.