Ceci est le guide du AWS CDK développeur de la version 2. L'ancienne CDK version 1 est entrée en maintenance le 1er juin 2022 et a pris fin le 1er juin 2023.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

AWS CDK validation des politiques au moment de la synthèse

Validation des politiques au moment de la synthèse

Si vous ou votre organisation utilisez un outil de validation des politiques, tel que AWS CloudFormation Guardou OPA, pour définir des contraintes sur votre AWS CloudFormation modèle, vous pouvez les intégrer AWS CDK au moment de la synthèse. En utilisant le plugin de validation des politiques approprié, vous pouvez faire en sorte que l' AWS CDK application vérifie le AWS CloudFormation modèle généré par rapport à vos politiques immédiatement après la synthèse. En cas de violation, la synthèse échouera et un rapport sera imprimé sur la console.

La validation effectuée AWS CDK au moment de la synthèse contrôle les contrôles à un moment donné du cycle de vie du déploiement, mais elle ne peut pas affecter les actions qui se produisent en dehors de la synthèse. Les exemples incluent les actions effectuées directement dans la console ou via le serviceAPIs. Ils ne résistent pas à l'altération des AWS CloudFormation modèles après la synthèse. Un autre mécanisme permettant de valider le même ensemble de règles avec plus d'autorité doit être configuré indépendamment, comme les AWS CloudFormation hooks ou AWS Config. Néanmoins, la capacité d' AWS CDK évaluer l'ensemble de règles pendant le développement est toujours utile car elle améliorera la vitesse de détection et la productivité des développeurs.

L'objectif de la validation des AWS CDK politiques est de minimiser la quantité de configuration nécessaire au cours du développement et de le rendre aussi simple que possible.

Pour les développeurs d'applications

Pour utiliser un ou plusieurs plugins de validation dans votre application, utilisez la policyValidationBeta1 propriété suivante Stage :

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

Immédiatement après la synthèse, tous les plugins enregistrés de cette manière seront invoqués pour valider tous les modèles générés dans le champ que vous avez défini. En particulier, si vous enregistrez les modèles dans l'Appobjet, tous les modèles seront soumis à validation.

AWS CloudFormation Guard plugin

L'utilisation du CfnGuardValidatorplugin vous permet d'AWS CloudFormation Guardeffectuer des validations de politiques. Le CfnGuardValidator plugin est livré avec un ensemble sélectionné de contrôles AWS Control Tower proactifs intégrés. L'ensemble de règles actuel se trouve dans la documentation du projet. Comme indiqué dansValidation des politiques au moment de la synthèse, nous recommandons aux organisations de mettre en place une méthode de validation plus fiable à l'aide de AWS CloudFormation crochets.

Pour les AWS Control Towerclients, ces mêmes contrôles proactifs peuvent être déployés dans l'ensemble de votre organisation. Lorsque vous activez des contrôles AWS Control Tower proactifs dans votre AWS Control Tower environnement, ils peuvent arrêter le déploiement de ressources non conformes déployées via AWS CloudFormation. Pour plus d'informations sur les contrôles proactifs gérés et leur fonctionnement, consultez la AWS Control Tower documentation.

Il est préférable d'utiliser conjointement ces contrôles AWS CDK groupés et ces contrôles AWS Control Tower proactifs gérés. Dans ce scénario, vous pouvez configurer ce plugin de validation avec les mêmes contrôles proactifs que ceux actifs dans votre environnement AWS Control Tower cloud. Vous pouvez alors rapidement être sûr que votre AWS CDK application passera les AWS Control Tower contrôles en s'exécutant cdk synth localement.

Rapport de validation

Lorsque vous synthétiserez l' AWS CDK application, les plugins de validation seront appelés et les résultats seront imprimés. Un exemple de rapport est présenté ci-dessous.

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

Par défaut, le rapport sera imprimé dans un format lisible par l'homme. Si vous souhaitez un rapport au JSON format, activez-le en utilisant le @aws-cdk/core:validationReportJson via CLI ou en le transmettant directement à l'application :

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

Vous pouvez également définir cette paire clé-valeur de contexte à l'aide des cdk.context.json fichiers cdk.json or du répertoire de votre projet (voirLes valeurs contextuelles et le AWS CDK).

Si vous choisissez le JSON format, le rapport de validation des politiques AWS CDK sera imprimé dans un fichier appelé policy-validation-report.json dans le répertoire d'assemblage du cloud. Pour le format par défaut lisible par l'homme, le rapport sera imprimé sur la sortie standard.

Pour les auteurs de plugins

Plugins

Le framework de AWS CDK base est chargé d'enregistrer et d'appeler les plugins, puis d'afficher le rapport de validation formaté. La responsabilité du plugin est d'agir en tant que couche de traduction entre le AWS CDK framework et l'outil de validation des politiques. Un plugin peut être créé dans n'importe quelle langue prise en charge par AWS CDK. Si vous créez un plugin susceptible d'être utilisé par plusieurs langues, il est recommandé de le créer TypeScript afin de pouvoir l'utiliser JSII pour le publier dans chaque AWS CDK langue.

Création de plugins

Le protocole de communication entre le module AWS CDK principal et votre outil de politique est défini par l'IPolicyValidationPluginBeta1interface. Pour créer un nouveau plugin, vous devez écrire une classe qui implémente cette interface. Il y a deux choses que vous devez implémenter : le nom du plugin (en remplaçant la name propriété) et la validate() méthode.

Le framework appellera validate() en passant un IValidationContextBeta1 objet. L'emplacement des modèles à valider est indiqué partemplatePaths. Le plugin doit renvoyer une instance deValidationPluginReportBeta1. Cet objet représente le rapport que l'utilisateur recevra à la fin de la synthèse.

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

Notez que les plugins ne sont pas autorisés à modifier quoi que ce soit dans l'assemblage du cloud. Toute tentative en ce sens entraînera l'échec de la synthèse.

Si votre plugin dépend d'un outil externe, n'oubliez pas que certains développeurs n'ont peut-être pas encore installé cet outil sur leur poste de travail. Pour minimiser les frictions, nous vous recommandons vivement de fournir un script d'installation avec votre package de plugin, afin d'automatiser l'ensemble du processus. Mieux encore, exécutez ce script dans le cadre de l'installation de votre package. Avecnpm, par exemple, vous pouvez l'ajouter au postinstall script du package.json fichier.

Gestion des exemptions

Si votre organisation dispose d'un mécanisme de gestion des exemptions, celui-ci peut être mis en œuvre dans le cadre du plug-in de validation.

Exemple de scénario illustrant un éventuel mécanisme d'exemption :

Dans ce scénario, le développeur demanderait une exception dans le système interne, puis aurait besoin d'un moyen « d'enregistrer » cette exception. Pour compléter l'exemple du plugin Guard, vous pouvez créer un plugin qui gère les exemptions en filtrant les violations associées à une exemption correspondante dans un système de billetterie interne.

Consultez les plugins existants pour des exemples d'implémentations.