AWS Validierung der CDK-Richtlinien zum Zeitpunkt der Synthese - AWS Cloud Development Kit (AWS CDK) v2

Dies ist der AWS CDK v2-Entwicklerhandbuch. Das ältere CDK v1 wurde am 1. Juni 2022 in die Wartung aufgenommen und der Support wurde am 1. Juni 2023 eingestellt.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

AWS Validierung der CDK-Richtlinien zum Zeitpunkt der Synthese

Validierung der Richtlinien zum Zeitpunkt der Synthese

Wenn Sie oder Ihre Organisation ein Tool zur Richtlinienvalidierung wie AWS CloudFormation Guard oder OPA verwenden, um Einschränkungen für Ihre AWS CloudFormation Vorlage zu definieren, können Sie diese bei der Synthese in das AWS CDK integrieren. Mithilfe des entsprechenden Plug-ins zur Richtlinienvalidierung können Sie die AWS CDK-Anwendung veranlassen, die generierte AWS CloudFormation Vorlage unmittelbar nach der Synthese mit Ihren Richtlinien zu vergleichen. Bei Verstößen schlägt die Synthese fehl und ein Bericht wird auf der Konsole gedruckt.

Die vom AWS CDK zum Zeitpunkt der Synthese durchgeführte Validierung validiert die Kontrollen an einem bestimmten Punkt im Bereitstellungszyklus, sie kann sich jedoch nicht auf Aktionen auswirken, die außerhalb der Synthese stattfinden. Beispiele hierfür sind Aktionen, die direkt in der Konsole oder über einen Dienst APIs ausgeführt werden. Sie sind nicht resistent gegen Änderungen von AWS CloudFormation Vorlagen nach der Synthese. Einige andere Mechanismen, um denselben Regelsatz autoritärer zu validieren, sollten unabhängig eingerichtet werden, wie AWS CloudFormation Hooks oder AWS Config. Dennoch ist die Fähigkeit des AWS CDK, den Regelsatz während der Entwicklung auszuwerten, nach wie vor nützlich, da dadurch die Erkennungsgeschwindigkeit und die Produktivität der Entwickler verbessert werden.

Das Ziel der Überprüfung der AWS CDK-Richtlinien besteht darin, den während der Entwicklung erforderlichen Einrichtungsaufwand zu minimieren und ihn so einfach wie möglich zu gestalten.

Anmerkung

Diese Funktion gilt als experimentell, und sowohl die Plugin-API als auch das Format des Validierungsberichts können sich in future ändern.

Für Anwendungsentwickler

Um ein oder mehrere Validierungs-Plugins in Ihrer Anwendung zu verwenden, verwenden Sie die policyValidationBeta1 Eigenschaft vonStage:

import { CfnGuardValidator } from '@cdklabs/cdk-validator-cfnguard'; const app = new App({ policyValidationBeta1: [ new CfnGuardValidator() ], }); // only apply to a particular stage const prodStage = new Stage(app, 'ProdStage', { policyValidationBeta1: [...], });

Unmittelbar nach der Synthese werden alle auf diese Weise registrierten Plugins aufgerufen, um alle Vorlagen zu validieren, die in dem von Ihnen definierten Bereich generiert wurden. Insbesondere wenn Sie die Vorlagen im App Objekt registrieren, werden alle Vorlagen einer Validierung unterzogen.

Warnung

Abgesehen von der Änderung der Cloud-Assembly können Plugins alles tun, was Ihre AWS CDK-Anwendung kann. Sie können Daten aus dem Dateisystem lesen, auf das Netzwerk zugreifen usw. Es liegt in Ihrer Verantwortung als Nutzer eines Plugins, zu überprüfen, ob es sicher zu verwenden ist.

AWS CloudFormation Plugin schützen

Mit dem CfnGuardValidatorPlugin können Sie AWS CloudFormation Guard verwenden, um Richtlinienvalidierungen durchzuführen. Das CfnGuardValidator Plugin verfügt über einen ausgewählten Satz von integrierten proaktiven AWS Control Tower Tower-Steuerungen. Das aktuelle Regelwerk finden Sie in der Projektdokumentation. Wie bereits im Abschnitt „Überprüfung der Richtlinien bei der Zusammenfassung“ erwähnt, empfehlen wir Organisationen, mithilfe von AWS CloudFormation Hooks eine aussagekräftigere Validierungsmethode einzuführen.

Für AWS Control Tower Tower-Kunden können dieselben proaktiven Kontrollen in Ihrem gesamten Unternehmen eingesetzt werden. Wenn Sie die proaktiven AWS Control Tower Tower-Steuerungen in Ihrer AWS Control Tower Tower-Umgebung aktivieren, können die Kontrollen den Einsatz von nicht konformen Ressourcen verhindern, die über AWS CloudFormation bereitgestellt werden. Weitere Informationen zu verwalteten proaktiven Kontrollen und deren Funktionsweise finden Sie in der AWS Control Tower Tower-Dokumentation.

Diese im AWS CDK-Paket enthaltenen Steuerungen und die proaktiven Managed AWS Control Tower Tower-Kontrollen lassen sich am besten zusammen verwenden. In diesem Szenario können Sie dieses Validierungs-Plugin mit denselben proaktiven Kontrollen konfigurieren, die in Ihrer AWS Control Tower Tower-Cloud-Umgebung aktiv sind. Sie können sich dann schnell darauf verlassen, dass Ihre AWS CDK-Anwendung die AWS Control Tower-Kontrollen besteht, indem sie cdk synth lokal ausgeführt wird.

Validierungsbericht

Wenn Sie die AWS CDK-App synthetisieren, werden die Validator-Plugins aufgerufen und die Ergebnisse werden gedruckt. Ein Beispielbericht wird unten angezeigt.

Validation Report (CfnGuardValidator) ------------------------------------- (Summary) ╔═══════════╤════════════════════════╗ ║ Status │ failure ║ ╟───────────┼────────────────────────╢ ║ Plugin │ CfnGuardValidator ║ ╚═══════════╧════════════════════════╝ (Violations) Ensure S3 Buckets are encrypted with a KMS CMK (1 occurrences) Severity: medium Occurrences: - Construct Path: MyStack/MyCustomL3Construct/Bucket - Stack Template Path: ./cdk.out/MyStack.template.json - Creation Stack: └── MyStack (MyStack) │ Library: aws-cdk-lib.Stack │ Library Version: 2.50.0 │ Location: Object.<anonymous> (/home/johndoe/tmp/cdk-tmp-app/src/main.ts:25:20) └── MyCustomL3Construct (MyStack/MyCustomL3Construct) │ Library: N/A - (Local Construct) │ Library Version: N/A │ Location: new MyStack (/home/johndoe/tmp/cdk-tmp-app/src/main.ts:15:20) └── Bucket (MyStack/MyCustomL3Construct/Bucket) │ Library: aws-cdk-lib/aws-s3.Bucket │ Library Version: 2.50.0 │ Location: new MyCustomL3Construct (/home/johndoe/tmp/cdk-tmp-app/src/main.ts:9:20) - Resource Name: amzn-s3-demo-bucket - Locations: > BucketEncryption/ServerSideEncryptionConfiguration/0/ServerSideEncryptionByDefault/SSEAlgorithm Recommendation: Missing value for key `SSEAlgorithm` - must specify `aws:kms` How to fix: > Add to construct properties for `cdk-app/MyStack/Bucket` `encryption: BucketEncryption.KMS` Validation failed. See above reports for details

Standardmäßig wird der Bericht in einem für Menschen lesbaren Format gedruckt. Wenn Sie einen Bericht im JSON-Format wünschen, aktivieren Sie ihn @aws-cdk/core:validationReportJson über die CLI oder übergeben Sie ihn direkt an die Anwendung:

const app = new App({ context: { '@aws-cdk/core:validationReportJson': true }, });

Alternativ können Sie dieses Kontext-Schlüssel-Wert-Paar mithilfe der cdk.json cdk.context.json Oder-Dateien in Ihrem Projektverzeichnis festlegen (siehe Kontextwerte und AWS CDK).

Wenn Sie das JSON-Format wählen, druckt das AWS CDK den Richtlinienvalidierungsbericht in einer Datei aus, die policy-validation-report.json im Cloud-Assembly-Verzeichnis aufgerufen wird. Für das menschenlesbare Standardformat wird der Bericht in der Standardausgabe gedruckt.

Für Plugin-Autoren

Plug-ins

Das AWS CDK-Kernframework ist dafür verantwortlich, Plugins zu registrieren und aufzurufen und dann den formatierten Validierungsbericht anzuzeigen. Die Verantwortung des Plugins besteht darin, als Übersetzungsebene zwischen dem AWS CDK-Framework und dem Tool zur Richtlinienvalidierung zu fungieren. Ein Plugin kann in jeder von AWS CDK unterstützten Sprache erstellt werden. Wenn Sie ein Plugin erstellen, das möglicherweise in mehreren Sprachen verwendet wird, wird empfohlen, das Plugin in zu erstellen, TypeScript sodass Sie JSII verwenden können, um das Plugin in jeder AWS CDK-Sprache zu veröffentlichen.

Plugins erstellen

Das Kommunikationsprotokoll zwischen dem AWS CDK-Kernmodul und Ihrem Policy-Tool wird durch die IPolicyValidationPluginBeta1 Schnittstelle definiert. Um ein neues Plugin zu erstellen, müssen Sie eine Klasse schreiben, die diese Schnittstelle implementiert. Es gibt zwei Dinge, die du implementieren musst: den Namen des Plugins (indem du die name Eigenschaft überschreibst) und die validate() Methode.

Das Framework ruft auf validate() und übergibt ein IValidationContextBeta1 Objekt. Der Speicherort der zu validierenden Vorlagen ist gegeben durchtemplatePaths. Das Plugin sollte eine Instanz von zurückgebenValidationPluginReportBeta1. Dieses Objekt stellt den Bericht dar, den der Benutzer am Ende der Synthese erhält.

validate(context: IPolicyValidationContextBeta1): PolicyValidationReportBeta1 { // First read the templates using context.templatePaths... // ...then perform the validation, and then compose and return the report. // Using hard-coded values here for better clarity: return { success: false, violations: [{ ruleName: 'CKV_AWS_117', description: 'Ensure that AWS Lambda function is configured inside a VPC', fix: 'https://docs.bridgecrew.io/docs/ensure-that-aws-lambda-function-is-configured-inside-a-vpc-1', violatingResources: [{ resourceName: 'MyFunction3BAA72D1', templatePath: '/home/johndoe/myapp/cdk.out/MyService.template.json', locations: 'Properties/VpcConfig', }], }], }; }

Beachten Sie, dass Plugins nichts in der Cloud-Assembly ändern dürfen. Jeder Versuch, dies zu tun, führt zu einem Synthesefehler.

Wenn Ihr Plugin von einem externen Tool abhängt, denken Sie daran, dass einige Entwickler dieses Tool möglicherweise noch nicht auf ihren Workstations installiert haben. Um Reibungsverluste zu minimieren, empfehlen wir Ihnen dringend, Ihrem Plugin-Paket ein Installationsskript beizufügen, um den gesamten Prozess zu automatisieren. Besser noch, führe dieses Skript als Teil der Installation deines Pakets aus. Mit npm können Sie es beispielsweise dem postinstall Skript in der package.json Datei hinzufügen.

Umgang mit Ausnahmen

Wenn Ihre Organisation über einen Mechanismus zur Behandlung von Ausnahmen verfügt, kann dieser als Teil des Validator-Plug-ins implementiert werden.

Ein Beispielszenario zur Veranschaulichung eines möglichen Ausnahmemechanismus:

  • In einer Organisation gilt die Regel, dass öffentliche Amazon S3 S3-Buckets nicht erlaubt sind, außer in bestimmten Szenarien.

  • Ein Entwickler erstellt einen Amazon S3 S3-Bucket, der unter eines dieser Szenarien fällt, und beantragt eine Ausnahme (z. B. ein Ticket erstellen).

  • Sicherheitstools können aus dem internen System, das Ausnahmen registriert, lesen

In diesem Szenario würde der Entwickler eine Ausnahme im internen System beantragen und dann eine Möglichkeit benötigen, diese Ausnahme zu „registrieren“. Als Ergänzung zum Beispiel für das Guard-Plugin könnten Sie ein Plugin erstellen, das Ausnahmen behandelt, indem es die Verstöße herausfiltert, für die es eine entsprechende Ausnahme in einem internen Ticketsystem gibt.

Beispiele für Implementierungen finden Sie in den vorhandenen Plugins.