合成時の AWS CDK ポリシー検証 - AWS Cloud Development Kit (AWS CDK) v2

これは v2 AWS CDK デベロッパーガイドです。古い CDKv1 は 2022 年 6 月 1 日にメンテナンスを開始し、2023 年 6 月 1 日にサポートを終了しました。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

合成時の AWS CDK ポリシー検証

合成時のポリシー検証

ユーザーまたは組織が AWS CloudFormation GuardOPA などのポリシー検証ツールを使用して AWS CloudFormation テンプレートの制約を定義する場合、合成時に AWS CDK と統合できます。適切なポリシー検証プラグインを使用すると、合成直後に AWS CDK アプリケーションが生成された AWS CloudFormation テンプレートとポリシーを照合させることができます。違反がある場合、合成は失敗してレポートがコンソールに出力されます。

合成時に AWS CDK によって実行される検証は、デプロイライフサイクルのある時点で制御を検証しますが、合成以外で発生するアクションに影響を与えることはできせん。例には、コンソールで直接実行されるアクションやサービス API を介したアクションが含まれます。合成後、AWS CloudFormation テンプレートの変更には耐性がありません。「AWS CloudFormation フック」や「AWS Config」など、同じルールセットをより権威的に検証する他のメカニズムを個別に設定する必要があります。ただし、検出速度およびデベロッパーの生産性を向上させるため、AWS CDK が開発中にルールセットを評価する能力は依然として便利です。

AWS CDK ポリシー検証の目的は、開発時に必要なセットアップ量を最小限に抑え、可能な限り簡単にすることです。

注記

この機能は実験的なものとして考えられているため、プラグイン API および検証レポートの形式の両方は今後変更の対象となります。

アプリケーションデベロッパー向け

アプリケーションで 1 つ以上の検証プラグインを使用するには、StagepolicyValidationBeta1 プロパティを使用します。

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: [...], });

合成の直後、この方法で登録されたすべてのプラグインが呼び出され、定義したスコープで生成されたすべてのテンプレートが検証されます。特に、App オブジェクトにテンプレートを登録した場合、すべてのテンプレートが検証の対象となります。

警告

クラウドアセンブリを変更することに加え、プラグインは AWS CDK アプリケーションができることをすべてできます。ファイルシステムからデータを読み取ったり、ネットワークにアクセスしたりすることができます。プラグインを安全に使用できることを確認することは、プラグインのコンシューマーとしてユーザーの責任です。

AWS CloudFormation Guard プラグイン

CfnGuardValidator」プラグインを使用すると、「AWS CloudFormation Guard」を使用してポリシーの検証を実行できます。CfnGuardValidator プラグインには、厳選された一連の「AWS Control Towerプロアクティブコントロール」が組み込まれています。現在のルールのセットは、「プロジェクトドキュメント」にあります。合成時のポリシー検証 で説明したように、組織は「AWS CloudFormation フック」を使用してより権威的な検証方法を設定することをお勧めします。

AWS Control Tower」の顧客の場合、これらの同じプロアクティブコントロールは組織全体にデプロイできます。AWS Control Tower 環境で AWS Control Tower プロアクティブコントロールを有効にすると、コントロールは AWS CloudFormation を介してデプロイされた非準拠リソースのデプロイを阻止できます。マネージドプロアクティブコントロールとその仕組みの詳細については、「AWS Control Tower ドキュメント」を参照してください。

これらの AWS CDK でバンドルされたコントロールおよびマネージド AWS Control Tower プロアクティブコントロールは、一緒に使用すると最適です。このシナリオでは、AWS Control Tower クラウド環境でアクティブなプロアクティブコントロールを使用し、この検証プラグインを設定できます。その後、cdk synth をローカルで実行し、AWS CDK アプリケーションが AWS Control Tower コントロールを渡すことに対して短時間で安心を得ることができます。

検証レポート

AWS CDK アプリを合成すると、検証プラグインが呼び出されて結果が出力されます。レポートの例が以下に示されます。

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

デフォルトでは、レポートは人間が読み取れる形式で出力されます。JSON 形式のレポートが必要な場合、CLI を介して @aws-cdk/core:validationReportJson を使用して有効にするか、アプリケーションに直接渡します。

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

または、プロジェクトディレクトリの cdk.json または cdk.context.json ファイルを使用し、このコンテキストキーと値のペアを設定できます (「コンテキスト値と AWS CDK」を参照)。

JSON 形式を選択した場合、AWS CDK はポリシー検証レポートをクラウドアセンブリディレクトリの policy-validation-report.json というファイルに出力します。デフォルトの人間が読める形式の場合、レポートは標準出力で出力されます。

プラグイン作成者向け

プラグイン

AWS CDK コアフレームワークは、プラグインを登録して呼び出したら、フォーマットされた検証レポートを表示する役割を果たしています。プラグインの役割は、AWS CDK フレームワークとポリシー検証ツール間の変換レイヤーとして機能することです。プラグインは、AWS CDK でサポートされているすべての言語で作成できます。複数の言語を使用するプラグインを作成する場合、JSII を使用してプラグインを各 AWS CDK 言語で公開できるように、プラグインを TypeScript で作成することをお勧めします。

プラグインの作成

AWS CDK コアモジュールとポリシーツール間の通信プロトコルは、IPolicyValidationPluginBeta1 インターフェイスによって定義されます。新しいプラグインを作成するには、このインターフェイスを実装するクラスを記述する必要があります。実装する必要があるものは 2 つあり、プラグイン名 (name プロパティを上書きすることで実装) および validate() メソッドです。

フレームワークは validate() を呼び出し、IValidationContextBeta1 オブジェクトを渡します。検証するテンプレートの場所は templatePaths によって指定されます。プラグインは ValidationPluginReportBeta1 のインスタンスを返します。このオブジェクトは、合成の最後にユーザーが受け取るレポートを表します。

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', }], }], }; }

プラグインは、クラウドアセンブリのものを一切変更できないことに注意してください。変更しようとすると合成が失敗します。

プラグインが外部ツールに依存している場合、一部のデベロッパーがまだそのツールをワークステーションにインストールしていない場合があることに注意してください。わずらわしさを最小限に抑えるには、プロセス全体を自動化するため、プラグインパッケージと共にインストールスクリプトを提供することを強くお勧めします。さらに、パッケージのインストールの一環として、そのスクリプトを実行することをお勧めします。例えば、npm を使用すると、package.json ファイルの postinstallスクリプト」に追加できます。

適用除外の処理

組織に適用除外を処理するメカニズムがある場合、検証プラグインの一部として実装できます。

実現可能な適用除外メカニズムを説明するシナリオの例

  • 特定のシナリオを除き、ある組織にはパブリック Amazon S3 バケットが許可されないというルールがあります。

  • デベロッパーはこれらのシナリオのいずれかに該当する Amazon S3 バケットを作成し、適用除外を要求します (チケットの作成など)。

  • セキュリティのツールは、適用除外を登録する内部システムからの読み取る方法を知っています

このシナリオでは、デベロッパーは内部システムで例外を要求し、その例外を「登録」する方法が必要になります。ガードプラグインの例に追加すると、内部チケットシステムに一致する適用除外がある違反をフィルタリングすることにより、適用除外を処理するプラグインを作成できます。

実装例については、既存のプラグインを参照してください。