Wiedererlangung der Kontrolle über verwaiste Ressourcen mit CDK

Manchmal sind AWS-Ressourcen verwaist. Das bedeutet, dass der CloudFormation-Stack zerstört wird, die Ressource aber erhalten bleibt. Dies kann entweder passieren, weil die CloudFormation-Vorlage diesen Wunsch in der DeletionPolicy angegeben hat oder nachdem Sie während der Zerstörung einen Fehler von CloudFormation erhalten haben und Sie sich entschieden haben, den Stack trotzdem zu löschen, obwohl Sie wussten, dass die betreffende Ressource erhalten bleiben wird.

Es ist durchaus möglich, mit der verwaisten Ressource zu arbeiten, denn Sie können immer auf sie verweisen, indem Sie ihre Arn verwenden, aber Sie können ihre Eigenschaften nicht mehr über Infrastructure as Code wie CloudFormation oder CDK manipulieren. In CDK verwenden Sie dazu die statischen Methoden von . Dies gibt Ihnen jedoch nicht die Kontrolle über die Eigenschaften der verwaisten Ressource zurück.

Verwaiste Ressourcen sind in der Praxis jedoch nicht immer einfach zu handhaben. Ein Beispiel: Wenn der Reifegrad Ihrer Organisation steigt, werden Sie mit einer neuen Regel konfrontiert, die besagt, dass alle Ihre S3-Buckets bestimmte Sicherheitsmaßnahmen wie SSL-Zugriff oder KMS-Verschlüsselung haben müssen. Wenn Ihr Sicherheitsbeauftragter nun auch Click-ops (die Verwaltung von Ressourcen über die AWS-Konsole) verbietet, brauchen Sie eine Möglichkeit, die Kontrolle über die verwaisten Buckets per Code wiederzuerlangen.

CloudFormation bietet diese Funktion bereits seit einiger Zeit, aber für CDK-Projekte müssen Sie eine experimentelle Funktion verwenden. Hier sind die Schritte, die Sie unternehmen müssen, um eine verwaiste Ressource zu übernehmen:

1. Entscheiden Sie, welche Anwendung / welcher Stack die neue übergeordnete Anwendung für Ihre Ressource werden soll.
2. Erstellen Sie die Ressource in diesem Stapel mithilfe von CDK-Code (die genauen Eigenschaften sind im Moment nicht wichtig)
3. Synthetisieren Sie Ihr Projekt und suchen Sie die logische ID der Ressource im generierten Stack in CDK.OUT
4. Erstellen Sie mapping.json, in dem Sie die logische ID mit der physischen ID der vorhandenen Ressource verknüpfen.
5. Laufen lassen cdk import -m mapping.json
6. Schauen Sie sich den Stack in der Konsole an und führen Sie eine Drifterkennung durch
7. Passen Sie nun den Code in Ihrem CDK-Projekt so an, dass die Ressource mit der Drift übereinstimmt
8. Laufen lassen cdk deploy

Es ist sehr wichtig zu verstehen, dass sich bei der Ausführung von Schritt 5 nichts anderes als das Hinzufügen der Ressource in Ihrem Stack geändert haben darf! Sollten sich mehr Dinge geändert haben, erhalten Sie eine Fehlermeldung.

Sie können auch ohne die mapping.json Datei arbeiten, aber der cdk import Prozess wird dann interaktiv und eignet sich nicht für eine CI/CD-Pipeline. Die json-Datei sollte wie folgt aussehen:

{
    "LogIdOfTheResourceYouLookedUp": {
        "BucketName": "my-existing-bucket-name"
    }
}

Ich habe dies nur mit einem Eimer getestet. Die tatsächliche Verknüpfung mit der physischen id-Eigenschaft kann je nach Ressourcentyp unterschiedlich sein.

In einer CI/CD-Pipeline-Automatisierung könnten Sie sich dafür entscheiden, einen cdk import -Schritt anstelle eines cdk deploy -Schrittes durchzuführen, wenn der mapping.json -Schritt vorhanden ist. Außerdem ist zu beachten, dass dies derzeit nur funktioniert, wenn Sie entweder ein Projekt mit einem Stack haben oder Sie den Stack angeben, mit dem Sie ausführen möchten. Ich könnte mir vorstellen, dass Sie einen stackname-mapping.json erstellen und Ihre Pipeline die Stack-Auswahl durchführen lassen können.

Joris Conijn hat hier bereits einen schönen Artikel über die Migration von Ressourcen zwischen CDK-Stacks geschrieben, ohne die experimentelle Funktion zu verwenden.

Die experimentelle cdk-Funktion wird hier beschrieben. Sie ist noch offen, so dass Sie vielleicht mitverfolgen oder beeinflussen können, wie sie sich stabilisiert.