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
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 CfnGuardValidator
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
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
Skriptpackage.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.