Erweitern Sie Ihre AWS CDK Projekte mit Testing

Automatisierte Unit- und Integrationstests validieren Systemkomponenten und erhöhen das Vertrauen in Ihren Infrastrukturcode, aber leider ist dies ein sehr vernachlässigtes Thema beim CDK. Vor ein paar Wochen haben wir beschlossen, eine neue Version einer CDK-Konstrukt-Bibliothek in einem Projekt zu starten – das bedeutete, unsere CDK-Tests auf ein neues Niveau zu heben.

Wir wollten jedes benutzerdefinierte Konstrukt mit mehreren Unit- und Integrationstests testen. Hier ist eine Erklärung des Unterschieds zwischen einem Unit-Test und einem Integrationstest:

Unit-Tests im CDK konzentrieren sich auf das Testen der Logik innerhalb von CDK-Konstrukten, bei denen es sich um wiederverwendbare Komponenten handelt, die Cloud-Ressourcen definieren und konfigurieren. Diese Tests synthetisieren einfach CDK-Code zu einer CloudFormation-Vorlage, ohne tatsächlich AWS-Ressourcen bereitzustellen. Kurz gesagt, AWS-Dienste werden einfach gemockt und wir vergleichen die generierte Vorlage mit unseren Prüfungen.

Integrationstests stellen hingegen die tatsächlichen Ressourcen in einem AWS-Konto bereit, um sicherzustellen, dass die bereitgestellten Ressourcen ordnungsgemäß zusammenarbeiten. Diese Tests überprüfen das Verhalten der gesamten AWS-Anwendung, einschließlich Berechtigungen, Netzwerken und Service-Integrationen. Wir verwenden das @aws-cdk/integ-tests-alpha Modul für Integrationstests im CDK.

Da wir gerade erst mit diesem neuen Thema anfingen, haben wir recherchiert. Leider mangelt es im Internet an guten Beispielen. Diese Situation hat nun ein Ende. Nach dem Fehlerbeheben, Testen und Sammeln von Erfahrungen können wir nun unsere Erkenntnisse und Code-Beispiele mit Ihnen teilen.

Unit Testing

"Nein, Sie müssen nicht jede Zeile Ihrer CDK-Anwendung testen" - Yan Cui

Wenn Sie nur offizielle CDK-Konstrukte deklarieren und verwenden, müssen wir nicht zwingend testen. Ich würde nur testen, um die Einhaltung von Sicherheits- und Compliance-Vorgaben sicherzustellen (Shift-Left-Prinzip). Dies sollte jedoch nicht als Alternative, sondern nur als Ergänzung zu AWS Config und Conformance Packs genutzt werden.

Da Security jeden etwas angeht, sollten wir testen, ob alle RDS-Instanzen verschlüsselt werden. Das geht ganz einfach so:

template.allResourcesProperties("AWS::RDS::DBInstance", {
  StorageEncrypted: true,
});

Zusätzlich sollten wir prüfen, ob ein KMS-Schlüssel verwendet wird, der regelmäßig rotiert wird:

// KMS Key rotation Check
template.allResourcesProperties("AWS::KMS::Key", {
  EnableKeyRotation: true
});

// RDS Instance Check
template.allResourcesProperties("AWS::RDS::DBInstance", {
  StorageEncrypted: true,
  KmsKeyId: Match.anyValue(),
});

Stellen Sie sich vor, Sie haben ein Plattformteam, das den App-Teams leicht bereitstellbaren Infrastrukturcode zur Verfügung stellen möchte, der den Sicherheitsrichtlinien Ihres Unternehmens entspricht. Oft sind dafür Custom Resources nötig. Um diese im synthetisierten Stack zu finden, prüfen wir, ob die Referenzen korrekt gesetzt sind:

function logicalIdFromResource(resource: any) {
  try {
    const resKeys = Object.keys(resource);
    if (resKeys.length === 0) throw new Error("No Resource found.");
    if (resKeys.length !== 1) throw new Error("Resource is not unique.");
    const [logicalId] = resKeys;
    return logicalId;
  } catch (err) {
    console.log(resource);
    throw err;
  }
}

const testKmsKey = template.findResources("AWS::KMS::Key", {
  Properties: {"Description": "DescriptionTestKey"}
});

const testKmsKeyLogicalId = logicalIdFromResource(testKmsKey);

template.findResources("AWS::SecretsManager::Secret", {
  Properties: {
    "Name": "test",
    "KmsKeyId": {
      "Fn::GetAtt": [
        `${testKmsKeyLogicalId}`,
        "Arn"
      ]
    },
  }
});

Integration Testing

Wie anfangs erwähnt, befassen sich Integrationstests mit dem Bereitstellen von Ressourcen in einer Testumgebung, um die App von Anfang bis Ende zu testen.

Hier ist ein Beispiel, bei dem wir einen Secret-Inhalt mit einem awsApiCall überprüfen:

// Check whether the secret was created with the correct content
const assertion = integTest.assertions.awsApiCall("secrets-manager", "GetSecretValue", {
  SecretId: SECRETARN,
}, ["SecretString"]);

assertion.provider.addToRolePolicy({
  Effect: "Allow",
  Action: ["kms:Decrypt*"],
  Resource: ["*"],
});

assertion.assertAtPath("SecretString.username", ExpectedResult.stringLikeRegexp("test"));
assertion.assertAtPath("SecretString.password", ExpectedResult.stringLikeRegexp(".*?"));

Dabei nutzen wir ein nützliches Feature: Anstatt am Ende das gesamte Response-Objekt zu prüfen, verwenden wir assertAtPath, um nur Teile des Secret-Strings abzurufen und eine Regex darauf auszuführen.

Während des Integrationstests einer CDK-App werden zwei Stacks bereitgestellt (Ressourcen und Testressourcen). CloudFormation Outputs können verwendet werden, um ARNs zwischen den Stacks zu übergeben:

new cdk.CfnOutput(testStack, "AdminSecretArn", {
  value: adminSecret.secretArn,
  exportName: testStack.stackName+"-AdminSecretArn"
});

const SECRETARN = cdk.Fn.importValue(testStack.stackName+"-AdminSecretArn");

Neben awsApiCalls gibt es auch invokeFunction. Dies löst eine AWS-Lambda-Funktion aus, die weitaus komplexere Tests ausführen kann. Mit waitForAssertions kann definiert werden, in welchem Intervall und wie lange eine Lambda-Funktion ausgelöst werden soll:

// Invoke the assertion Lambda function to validate the received payload in s3
integTest.assertions.invokeFunction({
  functionName: assertionLambda.functionName,
}).expect(ExpectedResult.objectLike({
  Payload: "200"
})).waitForAssertions({
  totalTimeout: Duration.minutes(5),
  interval: Duration.seconds(30),
});

Fazit

Automatisierte Unit- und Integrationstests sind entscheidend, um CDK-Konstrukte zu validieren und die Sicherheit von Infrastrukturcode zu gewährleisten. Es gibt jedoch noch Herausforderungen, da sich die Testkonstrukte noch im Alpha-Stadium befinden. Wir hoffen, dass Ihnen unsere Einblicke den Einstieg erleichtert haben.