Ceci est le guide du développeur du AWS CDK v2. L'ancien CDK v1 est entré 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. # Démarrez votre environnement pour l'utiliser avec le CDK AWS Démarrez votre AWS environnement pour le préparer aux déploiements de stack AWS Cloud Development Kit (AWS CDK). + Pour une présentation des environnements, consultez [Environnements pour le AWS CDK.](environments.md) + Pour une introduction au bootstrapping, voir [AWS CDK](bootstrapping.md) bootstrapping. ## Comment démarrer votre environnement Vous pouvez utiliser l'interface de ligne de commande AWS CDK (AWS CDK CLI) ou votre outil de AWS CloudFormation déploiement préféré pour démarrer votre environnement. **Utiliser la CLI CDK** Vous pouvez utiliser la `cdk bootstrap` commande CDK CLI pour démarrer votre environnement. C'est la méthode que nous recommandons si vous n'avez pas besoin de modifications importantes au démarrage. **Bootstrap depuis n'importe quel répertoire de travail** Pour démarrer à partir de n'importe quel répertoire de travail, fournissez l'environnement de démarrage en tant qu'argument de ligne de commande. Voici un exemple : ``` $ cdk bootstrap ``` Si vous n'avez pas votre numéro de AWS compte, vous pouvez l'obtenir depuis la console de AWS gestion. Vous pouvez également utiliser la commande AWS CLI suivante pour afficher les informations de votre compte par défaut, y compris votre numéro de compte : ``` $ aws sts get-caller-identity ``` Si vous avez nommé des profils dans vos `credentials` fichiers AWS `config` et, utilisez l'`--profile`option permettant de récupérer les informations de compte pour un profil spécifique. Voici un exemple : ``` $ aws sts get-caller-identity --profile ``` Pour afficher la région par défaut, utilisez la `aws configure get` commande : ``` $ aws configure get region $ aws configure get region --profile ``` Lorsque vous fournissez un argument, le `aws://` préfixe est facultatif. Ce qui suit est valide : ``` $ cdk bootstrap <123456789012/us-east-1> ``` Pour démarrer plusieurs environnements en même temps, fournissez plusieurs arguments : ``` $ cdk bootstrap ``` **Bootstrap depuis le répertoire parent d'un projet CDK** Vous pouvez exécuter `cdk bootstrap` depuis le répertoire parent d'un projet CDK contenant un `cdk.json` fichier. Si vous ne fournissez pas d'environnement comme argument, la CLI CDK obtiendra des informations sur l'environnement à partir de sources par défaut, telles que vos `credentials` fichiers `config` et ou toute information d'environnement spécifiée pour votre pile CDK. Lorsque vous démarrez à partir du répertoire parent d'un projet CDK, les environnements fournis par des arguments de ligne de commande ont priorité sur les autres sources. Pour démarrer un environnement spécifié dans vos `credentials` fichiers `config` et, utilisez l'`--profile`option : ``` $ cdk bootstrap --profile ``` Pour plus d'informations sur la `cdk bootstrap` commande et les options prises en charge, consultez [cdk bootstrap](ref-cli-cmd-bootstrap.md). **Utilisez n'importe quel AWS CloudFormation outil** Vous pouvez copier le modèle de [bootstrap](https://github.com/aws/aws-cdk-cli/blob/main/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml) depuis le *aws-cdk-cli GitHub référentiel* ou obtenir le modèle à l'aide de la `cdk bootstrap --show-template` commande. Utilisez ensuite n'importe quel AWS CloudFormation outil pour déployer le modèle dans votre environnement. Avec cette méthode, vous pouvez utiliser AWS CloudFormation StackSets AWS Control Tower. Vous pouvez également utiliser la AWS CloudFormation console ou l'interface de ligne de AWS commande (AWS CLI). Vous pouvez apporter des modifications à votre modèle avant de le déployer. Cette méthode peut être plus flexible et adaptée aux déploiements à grande échelle. Voici un exemple d'utilisation de l'`--show-template`option permettant de récupérer et d'enregistrer le modèle de bootstrap sur votre machine locale : **Example** ``` $ cdk bootstrap --show-template > bootstrap-template.yaml ``` Sous Windows, PowerShell doit être utilisé pour préserver le codage du modèle. ``` powershell "cdk bootstrap --show-template | Out-File -encoding utf8 bootstrap-template.yaml" ``` Si des notifications CDK apparaissent dans la sortie de votre AWS CloudFormation modèle, fournissez l'`--no-notices`option avec votre commande. Pour déployer ce modèle à l'aide de la CLI CDK, vous pouvez exécuter les opérations suivantes : ``` $ cdk bootstrap --template ``` Voici un exemple d'utilisation de la AWS CLI pour déployer le modèle : **Example** ``` aws cloudformation create-stack \ --stack-name CDKToolkit \ --template-body file://bootstrap-template.yaml \ --capabilities CAPABILITY_NAMED_IAM \ --region ``` ``` aws cloudformation create-stack ^ --stack-name CDKToolkit ^ --template-body file://bootstrap-template.yaml ^ --capabilities CAPABILITY_NAMED_IAM ^ --region ``` Pour plus d'informations sur l'utilisation CloudFormation StackSets pour démarrer plusieurs environnements, consultez la section [Démarrage de plusieurs AWS comptes pour AWS CDK à l'aide](https://aws.amazon.com/blogs/mt/bootstrapping-multiple-aws-accounts-for-aws-cdk-using-cloudformation-stacksets/) du blog * AWS Cloud Operations CloudFormation StackSets* & Migrations. ## Quand démarrer votre environnement Vous devez amorcer chaque AWS environnement avant de le déployer dans l'environnement. Nous vous recommandons de démarrer de manière proactive chaque environnement que vous prévoyez d'utiliser. Vous pouvez le faire avant de planifier le déploiement des applications CDK dans l'environnement. En démarrant vos environnements de manière proactive, vous évitez les problèmes futurs potentiels tels que les conflits de noms de compartiment Amazon S3 ou le déploiement d'applications CDK dans des environnements qui n'ont pas été démarrés. Vous pouvez démarrer un environnement plusieurs fois. Si un environnement a déjà été amorcé, la pile de bootstrap sera mise à niveau si nécessaire. Sinon, il ne se passera rien. Si vous tentez de déployer une pile de CDK dans un environnement qui n'a pas été amorcé, une erreur semblable à la suivante s'affichera : ``` $ cdk deploy ✨ Synthesis time: 2.02s ❌ Deployment failed: Error: BootstrapExampleStack: SSM parameter /cdk-bootstrap/hnb659fds/version not found. Has the environment been bootstrapped? Please run 'cdk bootstrap' (see https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html) ``` **Mettez à jour votre stack bootstrap** Régulièrement, l'équipe du CDK mettra à jour le modèle de bootstrap vers une nouvelle version. Dans ce cas, nous vous recommandons de mettre à jour votre stack bootstrap. Si vous n'avez pas personnalisé le processus d'amorçage, vous pouvez mettre à jour votre pile de bootstrap en suivant les mêmes étapes que lors du démarrage initial de votre environnement. Pour plus d'informations, consultez l'[historique des versions du modèle Bootstrap](#bootstrap-template-history). ## Ressources par défaut créées lors de l'amorçage **Rôles IAM créés lors du démarrage** Par défaut, le bootstrap fournit les rôles AWS Identity and Access Management (IAM) suivants dans votre environnement : + `CloudFormationExecutionRole` + `DeploymentActionRole` + `FilePublishingRole` + `ImagePublishingRole` + `LookupRole` `CloudFormationExecutionRole` Ce rôle IAM est un rôle de CloudFormation service qui accorde CloudFormation l'autorisation d'effectuer des déploiements de stack en votre nom. Ce rôle donne CloudFormation l'autorisation d'effectuer des appels AWS d'API dans votre compte, notamment de déployer des stacks. En utilisant un rôle de service, les autorisations accordées pour le rôle de service déterminent les actions qui peuvent être effectuées sur vos CloudFormation ressources. Sans ce rôle de service, les informations d'identification de sécurité que vous fournissez avec la CLI CDK détermineraient ce qui CloudFormation est autorisé à faire. `DeploymentActionRole` Ce rôle IAM accorde l'autorisation d'effectuer des déploiements dans votre environnement. Il est assumé par la CLI CDK lors des déploiements. En utilisant un rôle pour les déploiements, vous pouvez effectuer des déploiements entre comptes, car le rôle peut être assumé par AWS des identités d'un autre compte. `FilePublishingRole` Ce rôle IAM autorise l'exécution d'actions sur le compartiment Amazon Simple Storage Service (Amazon S3) amorcé, notamment le téléchargement et la suppression d'actifs. Il est assumé par la CLI CDK lors des déploiements. `ImagePublishingRole` Ce rôle IAM autorise l'exécution d'actions sur le référentiel Amazon Elastic Container Registry (Amazon ECR) amorcé. Il est assumé par la CLI CDK lors des déploiements. `LookupRole` Ce rôle IAM `readOnly` autorise la recherche de [valeurs de contexte dans](context.md) l' AWS environnement. Il est assumé par la CLI CDK lors de l'exécution de tâches telles que la synthèse de modèles et les déploiements. **Ressource IDs créée lors du bootstrap** Lorsque vous déployez le modèle de bootstrap par défaut, les ressources physiques IDs pour le bootstrap sont créées à l'aide de la structure suivante :. `cdk----` + **Qualificateur** : valeur de chaîne unique de neuf caractères de`hnb659fds`. La valeur réelle n'a aucune importance. + **Description** — Brève description de la ressource. Par exemple, `container-assets`. + **ID de compte** : identifiant de AWS compte de l'environnement. + **Région** — La AWS région de l'environnement. Voici un exemple d'identifiant physique du compartiment intermédiaire Amazon S3 créé lors du démarrage :. `cdk-hnb659fds-assets-012345678910-us-west-1` ## Autorisations à utiliser lors du démarrage de votre environnement Lors du démarrage d'un AWS environnement, l'identité IAM effectuant le démarrage doit disposer au moins des autorisations suivantes : ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*", "ecr:*", "ssm:*", "s3:*", "iam:*" ], "Resource": "*" } ] } ``` Au fil du temps, la pile bootstrap, y compris les ressources créées et les autorisations requises, peut changer. Lors des modifications futures, il se peut que vous deviez modifier les autorisations requises pour démarrer un environnement. ## Personnaliser le bootstrap Si le modèle de bootstrap par défaut ne répond pas à vos besoins, vous pouvez personnaliser l'amorçage des ressources dans votre environnement de la manière suivante : + Utiliser les options de ligne de commande avec la `cdk bootstrap` commande : cette méthode est idéale pour apporter de petites modifications spécifiques prises en charge par les options de ligne de commande. + Modifiez le modèle de bootstrap par défaut et déployez-le : cette méthode est idéale pour apporter des modifications complexes ou si vous souhaitez contrôler totalement la configuration des ressources provisionnées pendant le démarrage. Pour plus d'informations sur la personnalisation du bootstrap, voir [Personnaliser AWS](bootstrapping-customizing.md) le bootstrap CDK. ## Bootstrapping avec CDK Pipelines Si vous utilisez CDK Pipelines pour effectuer un déploiement dans l'environnement d'un autre compte et que vous recevez un message comme celui-ci : ``` Policy contains a statement with one or more invalid principals ``` Ce message d'erreur signifie que les rôles IAM appropriés n'existent pas dans l'autre environnement. La cause la plus probable est que l'environnement n'a pas été amorcé. Démarrez l'environnement et réessayez. **Protéger votre stack bootstrap contre la suppression** Si une pile bootstrap est supprimée, les AWS ressources initialement provisionnées dans l'environnement pour prendre en charge les déploiements de CDK seront également supprimées. Cela empêchera le pipeline de fonctionner. Dans ce cas, il n'existe pas de solution générale pour le rétablissement. Une fois votre environnement amorcé, ne supprimez pas et ne recréez pas la pile d'amorçage de l'environnement. Essayez plutôt de mettre à jour la pile bootstrap vers une nouvelle version en exécutant à nouveau la `cdk bootstrap` commande. Pour vous protéger contre la suppression accidentelle de votre stack bootstrap, nous vous recommandons de fournir l'`--termination-protection`option avec la `cdk bootstrap` commande permettant d'activer la protection contre la résiliation. Vous pouvez activer la protection contre la résiliation sur les piles de bootstrap nouvelles ou existantes. Pour obtenir des instructions sur l'activation de la protection contre la [résiliation, voir Activer la protection contre la résiliation pour la pile bootstrap.](bootstrapping-customizing.md#bootstrapping-customizing-cli-protection) ## Historique des versions du modèle Bootstrap Le modèle bootstrap est versionné et évolue au fil du temps avec le AWS CDK lui-même. Si vous fournissez votre propre modèle de bootstrap, maintenez-le à jour avec le modèle canonique par défaut. Vous devez vous assurer que votre modèle continue de fonctionner avec toutes les fonctionnalités du CDK. **Note** Les versions antérieures du modèle bootstrap créaient par défaut une clé AWS KMS dans chaque environnement bootstrap. Pour éviter de payer la clé KMS, redémarrez ces environnements à l'aide de. `--no-bootstrap-customer-key` La valeur par défaut actuelle est l'absence de clé KMS, ce qui permet d'éviter ces frais. Cette section contient une liste des modifications apportées dans chaque version. | Version du modèle | AWS Version du CDK | Modifications | | --- | --- | --- | | **1** | 1.40.0 | Version initiale du modèle avec compartiment, clé, référentiel et rôles. | | **2** | 1,45,0 | Divisez le rôle de publication de ressources en rôles de publication de fichiers et d'images distincts. | | **3** | 1.46,0 | Ajoutez `FileAssetKeyArn` l'exportation pour pouvoir ajouter des autorisations de déchiffrement aux consommateurs d'actifs. | | **4** | 1,61,0 | AWS Les autorisations KMS sont désormais implicites via Amazon S3 et ne sont plus nécessaires`FileAssetKeyArn`. Ajoutez le paramètre `CdkBootstrapVersion` SSM afin que la version de la pile bootstrap puisse être vérifiée sans connaître le nom de la pile. | | **5** | 1,87,0 | Le rôle de déploiement peut lire le paramètre SSM. | | **6** | 1,108,0 | Ajoutez un rôle de recherche distinct du rôle de déploiement. | | **6** | 1,109,0 | Attachez une `aws-cdk:bootstrap-role` balise aux rôles de déploiement, de publication de fichiers et de publication d'images. | | **7** | 1,110,0 | Le rôle de déploiement ne peut plus lire directement les buckets dans le compte cible. (Cependant, ce rôle est en fait un administrateur et peut toujours utiliser ses AWS CloudFormation autorisations pour rendre le bucket lisible de toute façon). | | **8** | 1,114,0 | Le rôle de recherche dispose d'autorisations complètes en lecture seule sur l'environnement cible et possède également une `aws-cdk:bootstrap-role` balise. | | **9** | 2.1.0 | Empêche les téléchargements de ressources Amazon S3 d'être rejetés par le SCP de chiffrement couramment référencé. | | **10** | 2.4.0 | Amazon ECR ScanOnPush est désormais activé par défaut. | | **11** | 2.18.0 | Ajoute une politique permettant à Lambda d'extraire des dépôts Amazon ECR afin de survivre au redémarrage. | | **12** | 2.20.0 | Ajoute le support pour les expériences`cdk import`. | | **13** | 2.25.0 | Rend les images de conteneur dans les référentiels Amazon ECR créés par bootstrap immuables. | | **14** | 2.34.0 | Désactive la numérisation d'images Amazon ECR au niveau du référentiel par défaut pour autoriser le démarrage des régions qui ne prennent pas en charge la numérisation d'images. | | **15** | 2,60,0 | Les clés KMS ne peuvent pas être étiquetées. | | **16** | 2,69,0 | Adresses du Security Hub détectant [KMS.2.](https://docs.aws.amazon.com/securityhub/latest/userguide/kms-controls.html#kms-2) | | **17** | 2,72,0 | Adresses au Security Hub détectant l'[ECR.3.](https://docs.aws.amazon.com/securityhub/latest/userguide/ecr-controls.html#ecr-3) | | **18** | 2,80,0 | Les modifications apportées à la version 16 ont été annulées car elles ne fonctionnent pas dans toutes les partitions et ne sont donc pas recommandées. | | **19** | 2,106,1 | Annulation des modifications apportées à la version 18 où AccessControl la propriété avait été supprimée du modèle. ([\$127964](https://github.com/aws/aws-cdk/issues/27964)) | | **20** | 2,119,0 | Ajoutez une `ssm:GetParameters` action au rôle IAM de AWS CloudFormation déploiement. Pour plus d'informations, voir [\$128336](https://github.com/aws/aws-cdk/pull/28336/files#diff-4fdac38426c4747aa17d515b01af4994d3d2f12c34f7b6655f24328259beb7bf). | | **21** | 2,149,0 | Ajoutez une condition au rôle de publication de fichiers. | | **22** | 2,160,0 | Ajoutez `sts:TagSession` des autorisations à la politique de confiance des rôles IAM bootstrap. | | **23** | 2,161,0 | Ajoutez `cloudformation:RollbackStack` des `cloudformation:ContinueUpdateRollback` autorisations à la politique de confiance du rôle IAM de déploiement. Cela fournit des autorisations pour la `cdk rollback` commande. | | **24** | 2,165,0 | Modifiez la durée de conservation des objets non courants du bucket bootstrap, de 365 à 30 jours. Étant donné que la nouvelle `cdk gc` commande permet de supprimer des objets dans le compartiment bootstrap, ce nouveau comportement garantit que les objets supprimés restent dans le compartiment bootstrap pendant 30 jours au lieu de 365 jours. Pour plus d'informations sur ce changement, voir `aws-cdk` PR [\$131949](https://github.com/aws/aws-cdk/pull/31949). | | **25** | 2,165,0 | Ajoutez un support au bucket bootstrap pour la suppression des téléchargements partitionnés incomplets. Les téléchargements partitionnés incomplets seront supprimés au bout d'un jour. Pour plus d'informations sur ce changement, voir `aws-cdk` PR [\$131956](https://github.com/aws/aws-cdk/pull/31956). | | **26** | 2,1002,0 | Ajoutez deux politiques relatives à la suppression (`UpdateReplacePolicy`et `DeletionPolicy` à la`FileAssetsBucketEncryptionKey`) ressource. Ces politiques garantissent que l'ancienne ressource clé AWS KMS sera correctement supprimée lors de la mise à jour ou de la suppression de la pile bootstrap. Pour plus d'informations sur ce changement, voir `aws-cdk-cli` PR [\$1100](https://github.com/aws/aws-cdk-cli/pull/100). | | **27** | 2,1003,0 | Ajoutez une nouvelle politique de ressources Amazon ECR pour accorder à Amazon EMR Serverless des autorisations spécifiques pour la récupération d'images de conteneurs. Pour plus d'informations sur ce changement, voir `aws-cdk-cli` PR [\$1112](https://github.com/aws/aws-cdk-cli/pull/112). | | **28** | 2,1015,0 | Ajoutez des autorisations pour effectuer des actions de Stack Refactoring au rôle de déploiement, ainsi que des TagSession autorisations pour tous les rôles. Pour plus d'informations sur ce changement, voir `aws-cdk-cli` PR [\$1471](https://github.com/aws/aws-cdk-cli/pull/471). | | **29** | 2,1026,0 | Tous les AssumeRole appels fournissant un ExternalId seront rejetés par défaut, sauf s'ils sont désactivés. Pour plus d'informations sur ce changement, voir `aws-cdk-cli` PR [\$1811](https://github.com/aws/aws-cdk-cli/pull/811). | | **30** | 2,1304,0 | Ajoutez des autorisations pour décrire les événements de pile au rôle de déploiement, afin de pouvoir afficher avec précision les erreurs de validation CloudFormation précoce. Pour plus d'informations sur ce changement, voir `aws-cdk-cli` PR [\$1970](https://github.com/aws/aws-cdk-cli/pull/970). | ## Passez d'un ancien modèle Bootstrap à un modèle moderne Le AWS CDK v1 supportait deux modèles d'amorçage, anciens et modernes. CDK v2 ne prend en charge que le modèle moderne. À titre de référence, voici les principales différences entre ces deux modèles. | Fonctionnalité | Legacy (v1 uniquement) | Moderne (v1 et v2) | | --- | --- | --- | | **Déploiements entre comptes** | Non autorisée | Autorisé | | ** AWS CloudFormation Autorisations** | Déploie en utilisant les autorisations de l'utilisateur actuel (déterminées par le AWS profil, les variables d'environnement, etc.) | Déploie en utilisant les autorisations spécifiées lors du provisionnement de la pile bootstrap (par exemple, en utilisant) `--trust` | | **Contrôle de version** | Une seule version de bootstrap stack est disponible | La pile Bootstrap est versionnée ; de nouvelles ressources peuvent être ajoutées dans les versions futures, et les applications AWS CDK peuvent nécessiter une version minimale | | **Ressources\$1** | Compartiment Amazon S3 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/cdk/v2/guide/bootstrapping-env.html) | | ** AWS clé KMS** | Rôles IAM | Référentiel Amazon ECR | | **Désignation des ressources** | Généré automatiquement | Déterministe | | **Chiffrement des compartiments** | Clé par défaut | AWS clé gérée par défaut. Vous pouvez le personnaliser pour utiliser une clé gérée par le client. | + *Nous ajouterons des ressources supplémentaires au modèle de bootstrap selon les besoins.* Un environnement qui a été amorcé à l'aide de l'ancien modèle doit être mis à niveau pour utiliser le modèle moderne de CDK v2 en redémarrant. Redéployez toutes les applications AWS CDK de l'environnement au moins une fois avant de supprimer l'ancien compartiment. ## Conclusions du Address Security Hub Si vous utilisez AWS Security Hub, vous pouvez voir des résultats publiés sur certaines ressources créées par le processus de démarrage du AWS CDK. Les résultats du Security Hub vous aident à trouver des configurations de ressources dont vous devez vérifier l'exactitude et la sécurité. Nous avons examiné ces configurations de ressources spécifiques avec AWS Security et nous sommes convaincus qu'elles ne constituent pas un problème de sécurité. **[KMS.2] Les principaux IAM ne devraient pas avoir de politiques IAM en ligne autorisant les actions de déchiffrement sur toutes les clés KMS** Le *rôle de déploiement* (`DeploymentActionRole`) autorise la lecture des données chiffrées, ce qui est nécessaire pour les déploiements entre comptes avec CDK Pipelines. Les politiques associées à ce rôle n'accordent pas d'autorisation à toutes les données. Il accorde uniquement l'autorisation de lire les données chiffrées depuis Amazon S3 et AWS KMS, et uniquement lorsque ces ressources l'autorisent par le biais de leur politique de compartiment ou de clé. Voici un extrait de ces deux instructions dans le *rôle de déploiement à partir du modèle* bootstrap : ``` DeploymentActionRole: Type: AWS::IAM::Role Properties: ... Policies: - PolicyDocument: Statement: ... - Sid: PipelineCrossAccountArtifactsBucket Effect: Allow Action: - s3:GetObject* - s3:GetBucket* - s3:List* - s3:Abort* - s3:DeleteObject* - s3:PutObject* Resource: "*" Condition: StringNotEquals: s3:ResourceAccount: Ref: AWS::AccountId - Sid: PipelineCrossAccountArtifactsKey Effect: Allow Action: - kms:Decrypt - kms:DescribeKey - kms:Encrypt - kms:ReEncrypt* - kms:GenerateDataKey* Resource: "*" Condition: StringEquals: kms:ViaService: Fn::Sub: s3.${AWS::Region}.amazonaws.com ... ``` **Pourquoi Security Hub signale-t-il cela ?** Les politiques contiennent une `Condition` clause `Resource: *` combinée. Security Hub signale le `*` joker. Ce caractère générique est utilisé car au moment du démarrage du compte, la clé AWS KMS créée par CDK Pipelines pour CodePipeline le bucket d'artefacts n'existe pas encore et ne peut donc pas être référencée sur le modèle de bootstrap par l'ARN. En outre, Security Hub ne tient pas compte de cette `Condition` clause lorsqu'il lève ce drapeau. Cela `Condition` se limite `Resource: *` aux demandes effectuées à partir du même AWS compte que la clé AWS KMS. Ces demandes doivent provenir d'Amazon S3 situé dans la même AWS région que la clé AWS KMS. **Dois-je corriger cette constatation ?** Tant que vous n'avez pas modifié la clé AWS KMS de votre modèle de bootstrap pour qu'elle soit trop permissive, le *rôle de déploiement* n'autorise pas un accès supérieur à ce dont il a besoin. Il n'est donc pas nécessaire de corriger cette constatation. **Et si je voulais corriger ce résultat ?** La manière de corriger ce problème dépend du fait que vous utiliserez ou non les CDK Pipelines pour les déploiements entre comptes. **Pour corriger la situation dans laquelle Security Hub trouve et utilise les CDK Pipelines pour les déploiements entre comptes** 1. Si vous ne l'avez pas encore fait, déployez la pile de bootstrap CDK à l'aide de la `cdk bootstrap` commande. 1. Si vous ne l'avez pas encore fait, créez et déployez votre CDK. Pipeline Pour obtenir des instructions, voir [Intégration et livraison continues (CI/CD) à l'aide de CDK Pipelines](cdk-pipeline.md). 1. Obtenez l'ARN de la clé AWS KMS du bucket d' CodePipeline artefacts. Cette ressource est créée lors de la création du pipeline. 1. Procurez-vous une copie du modèle de bootstrap CDK pour le modifier. Voici un exemple d'utilisation de la CLI AWS CDK : ``` $ cdk bootstrap --show-template > bootstrap-template.yaml ``` 1. Modifiez le modèle en remplaçant `Resource: *` l'`PipelineCrossAccountArtifactsKey`instruction par votre valeur ARN. 1. Déployez le modèle pour mettre à jour votre stack bootstrap. Voici un exemple d'utilisation de la CLI CDK : ``` $ cdk bootstrap aws:/// --template bootstrap-template.yaml ``` **Pour corriger le problème rencontré par Security Hub si vous n'utilisez pas CDK Pipelines pour les déploiements entre comptes** 1. Procurez-vous une copie du modèle de bootstrap CDK pour le modifier. Voici un exemple d'utilisation de la CLI CDK : ``` $ cdk bootstrap --show-template > bootstrap-template.yaml ``` 1. Supprimez les `PipelineCrossAccountArtifactsKey` instructions `PipelineCrossAccountArtifactsBucket` et du modèle. 1. Déployez le modèle pour mettre à jour votre stack bootstrap. Voici un exemple d'utilisation de la CLI CDK : ``` $ cdk bootstrap aws:/// --template bootstrap-template.yaml ``` ## Considérations Étant donné que le bootstrap fournit des ressources dans votre environnement, des AWS frais peuvent vous être facturés lorsque ces ressources sont utilisées avec le CDK. AWS # Personnaliser le AWS bootstrap du CDK Vous pouvez personnaliser le bootstrap du AWS Cloud Development Kit (AWS CDK) à l'aide de l'interface de ligne de commande AWS CDK (CDK AWS CLI) ou en modifiant et en déployant le modèle de bootstrap. AWS CloudFormation Pour une introduction au bootstrapping, voir [AWS CDK](bootstrapping.md) bootstrapping. ## Utilisez la CLI CDK pour personnaliser le bootstrap Voici quelques exemples de la façon dont vous pouvez personnaliser le bootstrap à l'aide de la CLI CDK. Pour une liste de toutes les `cdk bootstrap` options, voir [cdk bootstrap](ref-cli-cmd-bootstrap.md). **Remplacer le nom du compartiment Amazon S3** Utilisez `--bootstrap-bucket-name` cette option pour remplacer le nom du compartiment Amazon S3 par défaut. Cela peut nécessiter que vous modifiiez la synthèse du modèle. Pour plus d'informations, consultez [Personnaliser la synthèse de la pile CDK](configure-synth.md#bootstrapping-custom-synth). **Modifier les clés de chiffrement côté serveur pour le compartiment Amazon S3** Par défaut, le compartiment Amazon S3 de la pile bootstrap est configuré pour utiliser des clés AWS gérées pour le chiffrement côté serveur. Pour utiliser une clé gérée par le client existante, utilisez l'`--bootstrap-kms-key-id`option et fournissez une valeur pour la AWS clé du service de gestion des clés (AWS KMS) à utiliser. Si vous souhaitez mieux contrôler la clé de chiffrement, proposez `--bootstrap-customer-key` d'utiliser une clé gérée par le client. **Associez des politiques gérées au rôle de déploiement assumé par AWS CloudFormation** Par défaut, les piles sont déployées avec des autorisations d'administrateur complètes à l'aide de cette `AdministratorAccess` politique. Pour utiliser vos propres politiques gérées, utilisez l'`--cloudformation-execution-policies`option et fournissez ARNs les politiques gérées à associer au rôle de déploiement. Pour fournir plusieurs politiques, transmettez-leur une seule chaîne, séparée par des virgules : ``` $ cdk bootstrap --cloudformation-execution-policies "arn:aws:iam::aws:policy/AWSLambda_FullAccess,arn:aws:iam::aws:policy/AWSCodeDeployFullAccess" ``` Pour éviter les échecs de déploiement, assurez-vous que les politiques que vous spécifiez sont suffisantes pour tous les déploiements que vous allez effectuer dans l'environnement en cours de démarrage. **Modifiez le qualificatif ajouté aux noms des ressources de votre pile bootstrap** Par défaut, le `hnb659fds` qualificatif est ajouté à l'identifiant physique des ressources de votre pile bootstrap. Pour modifier cette valeur, utilisez l'`--qualifier`option. Cette modification est utile lors du provisionnement de plusieurs piles de bootstrap dans le même environnement afin d'éviter les conflits de noms. La modification du qualificatif est destinée à isoler les noms entre les tests automatisés du CDK lui-même. À moins que vous ne puissiez définir très précisément les autorisations IAM accordées au rôle CloudFormation d'exécution, le fait d'avoir deux piles de bootstrap différentes dans un seul compte ne présente aucun avantage en termes d'isolation des autorisations. Il n'est donc généralement pas nécessaire de modifier cette valeur. Lorsque vous modifiez le qualificatif, votre application CDK doit transmettre la valeur modifiée au synthétiseur de pile. Pour plus d'informations, consultez [Personnaliser la synthèse de la pile CDK](configure-synth.md#bootstrapping-custom-synth). **Ajouter des balises à la pile bootstrap** Utilisez l'`--tags`option au format de `KEY=VALUE` pour ajouter des CloudFormation balises à votre stack bootstrap. **Spécifiez AWS les comptes supplémentaires qui peuvent être déployés dans l'environnement en cours de démarrage** Utilisez `--trust` cette option pour fournir des AWS comptes supplémentaires autorisés à être déployés dans l'environnement en cours de démarrage. Par défaut, le compte effectuant le bootstrap sera toujours fiable. Cette option est utile lorsque vous démarrez un environnement dans lequel un CDK Pipeline depuis un autre environnement sera déployé dans. Lorsque vous utilisez cette option, vous devez également fournir`--cloudformation-execution-policies`. Pour ajouter des comptes fiables à une pile bootstrap existante, vous devez spécifier tous les comptes auxquels faire confiance, y compris ceux que vous avez fournis précédemment. Si vous ne fournissez que de nouveaux comptes auxquels faire confiance, les comptes précédemment approuvés seront supprimés. Voici un exemple qui fait confiance à deux comptes : ``` $ cdk bootstrap aws://123456789012/us-west-2 --trust 234567890123 --trust 987654321098 --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess ⏳ Bootstrapping environment aws://123456789012/us-west-2... Trusted accounts for deployment: 234567890123, 987654321098 Trusted accounts for lookup: (none) Execution policies: arn:aws:iam::aws:policy/AdministratorAccess CDKToolkit: creating CloudFormation changeset... ✅ Environment aws://123456789012/us-west-2 bootstrapped. ``` **Spécifiez des AWS comptes supplémentaires qui peuvent rechercher des informations dans l'environnement en cours de démarrage** Utilisez `--trust-for-lookup` cette option pour spécifier les AWS comptes autorisés à rechercher des informations contextuelles à partir de l'environnement en cours d'amorçage. Cette option est utile pour autoriser les comptes à synthétiser les piles qui seront déployées dans l'environnement, sans pour autant leur donner l'autorisation de déployer ces piles directement. **Activer la protection de terminaison pour la pile bootstrap** Si une pile bootstrap est supprimée, les AWS ressources initialement provisionnées dans l'environnement seront également supprimées. Une fois votre environnement amorcé, nous vous recommandons de ne pas supprimer ni recréer la pile d'amorçage de l'environnement, sauf si vous le faites intentionnellement. Essayez plutôt de mettre à jour la pile bootstrap vers une nouvelle version en exécutant à nouveau la `cdk bootstrap` commande. Utilisez `--termination-protection` cette option pour gérer les paramètres de protection contre la résiliation pour la pile bootstrap. En activant la protection contre la résiliation, vous empêchez la suppression accidentelle de la pile bootstrap et de ses ressources. Ceci est particulièrement important si vous utilisez CDK Pipelines car il n'existe aucune option de restauration générale si vous supprimez accidentellement la pile bootstrap. Après avoir activé la protection contre la résiliation, vous pouvez utiliser la AWS CLI ou AWS CloudFormation la console pour vérifier. **Pour activer la protection contre les licenciements** 1. Exécutez la commande suivante pour activer la protection contre la résiliation sur une pile bootstrap nouvelle ou existante : ``` $ cdk bootstrap --termination-protection ``` 1. Utilisez la AWS CLI ou CloudFormation la console pour vérifier. Voici un exemple d'utilisation de la AWS CLI. Si vous avez modifié le nom de votre pile bootstrap, remplacez-le `CDKToolkit` par le nom de votre pile : ``` $ aws cloudformation describe-stacks --stack-name --query "Stacks[0].EnableTerminationProtection" true ``` ## Modifier le modèle de bootstrap par défaut Lorsque vous avez besoin d'une personnalisation supérieure à celle que peut fournir la CLI CDK, vous pouvez modifier le modèle de bootstrap selon vos besoins. Déployez ensuite le modèle pour démarrer votre environnement. **Pour modifier et déployer le modèle de bootstrap par défaut** 1. Obtenez le modèle de bootstrap par défaut à l'aide de l'`--show-template`option. Par défaut, la CLI CDK affichera le modèle dans la fenêtre de votre terminal. Vous pouvez modifier la commande CDK CLI pour enregistrer le modèle sur votre machine locale. Voici un exemple : ``` $ cdk bootstrap --show-template > ``` 1. Modifiez le modèle de bootstrap selon vos besoins. Toutes les modifications que vous apportez doivent respecter le modèle de contrat de démarrage. Pour plus d'informations sur le modèle de contrat de démarrage, voir [Suivre le contrat de démarrage](#bootstrapping-contract). Pour vous assurer que vos personnalisations ne seront pas accidentellement remplacées ultérieurement par une personne `cdk bootstrap` utilisant le modèle par défaut, modifiez la valeur par défaut du paramètre du `BootstrapVariant` modèle. La CLI CDK autorise uniquement le remplacement de la pile bootstrap par des modèles dont la version est identique `BootstrapVariant` ou supérieure à celle du modèle actuellement déployé. 1. Déployez votre modèle modifié à l'aide de votre méthode AWS CloudFormation de déploiement préférée. Voici un exemple d'utilisation de la CLI CDK : ``` $ cdk bootstrap --template ``` ## Suivez le contrat Bootstrap Pour que vos applications CDK soient correctement déployées, les CloudFormation modèles produits lors de la synthèse doivent spécifier correctement les ressources créées lors du démarrage. Ces ressources sont communément appelées *ressources bootstrap.* Le bootstrapping crée des ressources dans votre AWS environnement qui sont utilisées par le AWS CDK pour effectuer des déploiements et gérer les actifs de l'application. Synthesis produit des CloudFormation modèles à partir de chaque pile CDK de votre application. Ces modèles ne définissent pas uniquement les AWS ressources qui seront mises à disposition à partir de votre application. Ils spécifient également les ressources d'amorçage à utiliser lors du déploiement. Pendant la synthèse, la CLI CDK ne sait pas précisément comment votre AWS environnement a été amorcé. Au lieu de cela, la CLI CDK produit des CloudFormation modèles basés sur le synthétiseur que vous configurez. Par conséquent, lorsque vous personnalisez le bootstrap, vous devrez peut-être personnaliser la synthèse. Pour obtenir des instructions sur la personnalisation de la synthèse, voir [Personnaliser la synthèse de la pile CDK](configure-synth.md#bootstrapping-custom-synth). L'objectif est de garantir que vos CloudFormation modèles synthétisés sont compatibles avec votre environnement d'amorçage. Cette compatibilité est appelée *contrat bootstrap.* La méthode la plus simple pour personnaliser la synthèse de pile consiste à modifier la `DefaultStackSynthesizer` classe de votre `Stack` instance. Si vous avez besoin d'une personnalisation allant au-delà de ce que cette classe peut offrir, vous pouvez écrire votre propre synthétiseur sous la forme d'une classe qui implémente ` [IStackSynthesizer](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.IStackSynthesizer.html) ` (peut-être `DefaultStackSynthesizer` dérivée de). Lorsque vous personnalisez le bootstrap, suivez le modèle de contrat bootstrap pour rester compatible avec. `DefaultStackSynthesizer` Si vous modifiez le bootstrap au-delà du contrat type de bootstrap, vous devrez écrire votre propre synthétiseur. ### Gestion des versions Le modèle bootstrap doit contenir une ressource permettant de créer un paramètre Amazon EC2 Systems Manager (SSM) avec un nom connu et une sortie reflétant la version du modèle : ``` Resources: CdkBootstrapVersion: Type: AWS::SSM::Parameter Properties: Type: String Name: Fn::Sub: '/cdk-bootstrap/${Qualifier}/version' Value: 4 Outputs: BootstrapVersion: Value: Fn::GetAtt: [CdkBootstrapVersion, Value] ``` ### Rôles `DefaultStackSynthesizer`Cela nécessite cinq rôles IAM pour cinq objectifs différents. Si vous n'utilisez pas les rôles par défaut, vous devez spécifier votre rôle IAM ARNs dans votre `DefaultStackSynthesizer` objet. Les rôles sont les suivants : + Le *rôle de déploiement* est assumé par la CLI CDK et par AWS CodePipeline le déploiement dans un environnement. Il `AssumeRolePolicy` contrôle qui peut être déployé dans l'environnement. Dans le modèle, vous pouvez voir les autorisations dont ce rôle a besoin. + Le *rôle de recherche* est assumé par la CLI CDK pour effectuer des recherches contextuelles dans un environnement. Il `AssumeRolePolicy` contrôle qui peut être déployé dans l'environnement. Les autorisations dont ce rôle a besoin sont indiquées dans le modèle. + Le rôle de *publication de fichiers et le rôle* de *publication d'images* sont assumés par la CLI CDK et par les AWS CodeBuild projets visant à publier des actifs dans un environnement. Ils sont utilisés pour écrire dans le compartiment Amazon S3 et dans le référentiel Amazon ECR, respectivement. Ces rôles nécessitent un accès en écriture à ces ressources. + *Le rôle AWS CloudFormation d'exécution* est transmis AWS CloudFormation pour effectuer le déploiement proprement dit. Ses autorisations sont celles sous lesquelles le déploiement s'exécutera. Les autorisations sont transmises à la pile sous forme de paramètre répertoriant les politiques gérées ARNs. ### Outputs La CLI CDK nécessite que les CloudFormation sorties suivantes existent sur la pile bootstrap : + `BucketName`— Nom du compartiment de ressources du fichier. + `BucketDomainName`— Le compartiment des actifs de fichiers au format nom de domaine. + `BootstrapVersion`— La version actuelle de la pile bootstrap. ### Historique du modèle Le modèle bootstrap est versionné et évolue au fil du temps avec le AWS CDK lui-même. Si vous fournissez votre propre modèle de bootstrap, maintenez-le à jour avec le modèle canonique par défaut. Vous devez vous assurer que votre modèle continue de fonctionner avec toutes les fonctionnalités du CDK. Pour plus d'informations, consultez l'[historique des versions du modèle Bootstrap](bootstrapping-env.md#bootstrap-template-history). # Création et application de limites d'autorisations pour le AWS CDK Une *limite d'autorisations* est une fonctionnalité avancée de AWS Identity and Access Management (IAM) que vous pouvez utiliser pour définir le maximum d'autorisations qu'une entité IAM, telle qu'un utilisateur ou un rôle, peut avoir. Vous pouvez utiliser des limites d'autorisations pour restreindre les actions que les entités IAM peuvent effectuer lors de l'utilisation du AWS Cloud Development Kit (AWS CDK). Pour en savoir plus sur les limites d'autorisations, consultez la section Limites d'[autorisations pour les entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le guide de l'*utilisateur IAM*. ## Quand utiliser les limites d'autorisations avec le AWS CDK Envisagez d'appliquer des limites d'autorisations lorsque vous devez empêcher les développeurs de votre organisation d'effectuer certaines actions avec le AWS CDK. Par exemple, s'il existe des ressources spécifiques dans votre AWS environnement que vous ne souhaitez pas que les développeurs modifient, vous pouvez créer et appliquer une limite d'autorisations. ## Comment appliquer des limites d'autorisations avec le AWS CDK ### Création de la limite des autorisations Tout d'abord, vous créez la limite des autorisations, à l'aide d'une politique AWS gérée ou d'une politique gérée par le client pour définir la limite d'une entité IAM (utilisateur ou rôle). Cette politique limite les autorisations maximales pour l'utilisateur ou le rôle. Pour obtenir des instructions sur la création de limites d'autorisations, consultez la section Limites d'[autorisations pour les entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le guide de l'*utilisateur IAM*. Les limites d'autorisations définissent le nombre maximum d'autorisations qu'une entité IAM peut avoir, mais elles n'accordent pas d'autorisations à elles seules. Vous devez utiliser les limites d'autorisations associées aux politiques IAM afin de limiter et d'accorder efficacement les autorisations appropriées à votre organisation. Vous devez également empêcher les entités IAM d'échapper aux limites que vous avez définies. Par exemple, consultez la section [Délégation de responsabilités à d'autres personnes à l'aide de limites d'autorisations](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-delegate) dans le guide de l'*utilisateur IAM*. ### Appliquer la limite d'autorisations lors du démarrage Après avoir créé la limite d'autorisations, vous pouvez l'appliquer au AWS CDK en l'appliquant lors du démarrage. Utilisez l'[`--custom-permissions-boundary`](ref-cli-cmd-bootstrap.md#ref-cli-cmd-bootstrap-options-custom-permissions-boundary)option et spécifiez le nom de la limite d'autorisation à appliquer. Voici un exemple d'application d'une limite d'autorisation nommée `cdk-permissions-boundary` : ``` $ cdk bootstrap --custom-permissions-boundary ``` Par défaut, le CDK utilise le rôle `CloudFormationExecutionRole` IAM, défini dans le modèle de bootstrap, pour recevoir les autorisations nécessaires pour effectuer des déploiements. En appliquant la limite d'autorisations personnalisée lors du démarrage, la limite d'autorisations est attachée à ce rôle. La limite des autorisations définira ensuite le nombre maximum d'autorisations pouvant être accordées par les développeurs de votre organisation lors de l'utilisation du AWS CDK. Pour en savoir plus sur ce rôle, consultez la section [Rôles IAM créés lors du démarrage](bootstrapping-env.md#bootstrapping-env-roles). Lorsque vous appliquez des limites d'autorisations de cette manière, elles sont appliquées à l'environnement spécifique que vous démarrez. Pour utiliser la même limite d'autorisations dans plusieurs environnements, vous devez appliquer la limite d'autorisations pour chaque environnement lors du démarrage. Vous pouvez également appliquer des limites d'autorisations différentes pour différents environnements. ## En savoir plus Pour plus d'informations sur les limites d'autorisations, voir [Quand et où utiliser les limites d'autorisations IAM](https://aws.amazon.com/blogs/security/when-and-where-to-use-iam-permissions-boundaries/) dans le *blog AWS de sécurité*. # Résoudre les problèmes de AWS démarrage du CDK Résolvez les problèmes courants lors du démarrage de votre environnement à l'aide du AWS Cloud Development Kit (AWS CDK). + Pour une introduction au bootstrapping, voir [AWS CDK](bootstrapping.md) bootstrapping. + Pour obtenir des instructions sur le bootstrap, voir [Bootstrap your environment for use with](bootstrapping-env.md) the CDK. AWS ## Lors du démarrage à l'aide du modèle par défaut, vous obtenez une erreur « CREATE\$1FAILED » pour le compartiment Amazon S3 Lors du démarrage à l'aide de la commande AWS CDK Command Line Interface (CDK CLI) `cdk bootstrap` avec le modèle d'amorçage par défaut, le message d'erreur suivant s'affiche : ``` CREATE_FAILED | AWS::S3::Bucket | already exists ``` Avant le dépannage, assurez-vous que vous utilisez la dernière version de la CLI CDK. + Pour vérifier votre version, lancez`cdk --version`. + Pour installer la dernière version, exécutez`npm install -g aws-cdk`. Après avoir installé la dernière version, réessayez de démarrer votre environnement. Si le message d'erreur persiste, poursuivez le dépannage. ### Causes courantes Lorsque vous démarrez votre environnement, le AWS CDK génère des ressources physiques IDs pour votre amorçage. Pour plus d'informations, consultez la section [Ressource IDs créée lors du démarrage](bootstrapping-env.md#bootstrapping-env-default-id). Contrairement aux autres ressources bootstrap, les noms des compartiments Amazon S3 sont globaux. Cela signifie que le nom de chaque compartiment doit être unique pour tous les AWS comptes de toutes les AWS régions d'une partition. Pour plus d'informations, consultez la [présentation des buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) dans le *guide de l'utilisateur Amazon S3*. Par conséquent, la cause la plus courante de cette erreur est que l'identifiant physique généré sous le nom de votre bucket existe déjà quelque part dans la partition. Cela peut se trouver dans votre compte ou dans un autre compte. Voici un exemple de nom de compartiment :`cdk-hnb659fds-assets-012345678910-us-west-1`. Bien que cela soit peu probable, étant donné que le qualificatif et l'ID de compte font partie du nom, il est possible que le nom d'un compartiment Amazon S3 soit utilisé par un autre AWS compte. Comme les noms de bucket ont une portée globale, vous ne pouvez pas les utiliser s'ils sont utilisés par un autre compte dans la même partition. Il est fort probable qu'un bucket portant le même nom existe quelque part dans votre compte. Cela peut se trouver dans la région que vous essayez de démarrer ou dans une autre région. En général, la solution consiste à localiser ce compartiment dans votre compte et à déterminer ce qu'il faut en faire, ou à personnaliser le bootstrap pour créer des ressources d'amorçage portant un nom différent. ### Résolution Tout d'abord, déterminez si un bucket portant le même nom existe dans votre AWS compte. En utilisant une AWS identité dotée d'autorisations valides pour rechercher des compartiments Amazon S3 dans votre compte, vous pouvez procéder de la manière suivante : + Utilisez la AWS commande Command Line Interface (AWS CLI) `aws s3 ls` pour afficher la liste de tous vos buckets. + Recherchez les noms de compartiment pour chaque région de votre compte à l'aide de la [console Amazon S3](https://console.aws.amazon.com/s3). S'il existe un bucket portant le même nom, déterminez s'il est utilisé. S'il n'est pas utilisé, pensez à supprimer le compartiment et à réessayer de démarrer votre environnement. Si un bucket portant le même nom existe et que vous ne souhaitez pas le supprimer, déterminez s'il est déjà associé à une pile bootstrap dans votre compte. Il se peut que vous deviez vérifier plusieurs régions. La région dans le nom du compartiment Amazon S3 ne signifie pas nécessairement que le compartiment se trouve dans cette région. Pour vérifier s'il est associé à la pile `CDKToolkit` bootstrap, vous pouvez effectuer l'une des opérations suivantes pour chaque région : + Utilisez la `aws cloudformation describe-stack-resources --stack-name --region ` commande AWS CLI pour afficher les ressources de votre pile bootstrap et vérifier si le bucket est répertorié. + Dans la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation), localisez la `CDKToolkit` pile. Ensuite, dans l'onglet **Ressources**, vérifiez si le bucket existe. Si le bucket est associé à une pile bootstrap, déterminez si la pile bootstrap se trouve dans la même région que celle dans laquelle vous essayez de démarrer. Si tel est le cas, votre environnement est déjà amorcé et vous devriez pouvoir commencer à utiliser le CDK pour déployer des applications dans votre environnement. Si le compartiment Amazon S3 est associé à une pile bootstrap dans une autre région, vous devez déterminer la marche à suivre. Les solutions possibles incluent le changement de nom du compartiment Amazon S3 existant, la suppression du compartiment Amazon S3 actuel s'il n'est pas utilisé ou l'utilisation d'un nouveau nom pour le compartiment Amazon S3 que vous essayez de créer. Si vous ne parvenez pas à trouver un compartiment Amazon S3 portant le même nom dans votre compte, il se peut qu'il existe dans un autre compte. Pour résoudre ce problème, vous devez personnaliser le bootstrap afin de créer de nouveaux noms pour toutes vos ressources bootstrap ou uniquement pour votre compartiment Amazon S3. Pour créer de nouveaux noms pour toutes les ressources bootstrap, vous pouvez modifier le qualificatif. Pour créer un nouveau nom uniquement pour votre compartiment Amazon S3, vous pouvez fournir un nouveau nom de compartiment. Pour personnaliser le bootstrap, vous pouvez utiliser les options avec la commande CDK `cdk bootstrap` CLI ou en modifiant le modèle de bootstrap. Pour obtenir des instructions, voir [Personnaliser le démarrage du AWS CDK](bootstrapping-customizing.md). Si vous personnalisez le bootstrap, vous devrez appliquer les mêmes modifications à la synthèse avant de pouvoir déployer correctement une application. Pour obtenir des instructions, voir [Personnaliser la synthèse de la pile CDK](configure-synth.md#bootstrapping-custom-synth). Par exemple, vous pouvez fournir un nouveau qualificatif avec `cdk bootstrap` : ``` $ cdk bootstrap --qualifier ``` Voici un exemple de nom de compartiment Amazon S3 qui sera créé avec cette modification : `cdk-abcde0123-assets-012345678910-us-west-1` Toutes les ressources bootstrap créées pendant le bootstrap utiliseront ce qualificatif. Lorsque vous développez votre application CDK, vous devez spécifier votre qualificatif personnalisé dans votre synthétiseur. Cela aide le CDK à identifier vos ressources bootstrap lors de la synthèse et du déploiement. Voici un exemple de personnalisation du synthétiseur par défaut pour votre instance de stack : **Example** ``` new MyStack(this, 'MyStack', { synthesizer: new DefaultStackSynthesizer({ qualifier: 'abcde0123', }), }); ``` ``` new MyStack(this, 'MyStack', { synthesizer: new DefaultStackSynthesizer({ qualifier: 'abcde0123', }), }) ``` ``` MyStack(self, "MyStack", synthesizer=DefaultStackSynthesizer( qualifier="abcde0123" )) ``` ``` new MyStack(app, "MyStack", StackProps.builder() .synthesizer(DefaultStackSynthesizer.Builder.create() .qualifier("abcde0123") .build()) .build(); ) ``` ``` new MyStack(app, "MyStack", new StackProps { Synthesizer = new DefaultStackSynthesizer(new DefaultStackSynthesizerProps { Qualifier = "abcde0123" }) }); ``` ``` func NewMyStack(scope constructs.Construct, id string, props *MyStackProps) awscdk.Stack { var sprops awscdk.StackProps if props != nil { sprops = props.StackProps } stack := awscdk.NewStack(scope, &id, &sprops) synth := awscdk.NewDefaultStackSynthesizer(&awscdk.DefaultStackSynthesizerProps{ Qualifier: jsii.String("abcde0123"), }) stack.SetSynthesizer(synth) return stack } ``` Vous pouvez également spécifier le nouveau qualificatif dans le `cdk.json` fichier de votre projet CDK : ``` { "app": "...", "context": { "@aws-cdk/core:bootstrapQualifier": "abcde0123" } } ``` Pour modifier uniquement le nom du compartiment Amazon S3, vous pouvez utiliser l'` --bootstrap-bucket-name `option. Voici un exemple : ``` $ cdk bootstrap --bootstrap-bucket-name '' ``` Lorsque vous développez votre application CDK, vous devez spécifier le nom de votre nouveau bucket dans votre synthétiseur. Voici un exemple de personnalisation du synthétiseur par défaut pour votre instance de stack : **Example** ``` new MyStack(this, 'MyStack', { synthesizer: new DefaultStackSynthesizer({ fileAssetsBucketName: 'my-new-bucket-name', }), }); ``` ``` new MyStack(this, 'MyStack', { synthesizer: new DefaultStackSynthesizer({ fileAssetsBucketName: 'my-new-bucket-name', }), }) ``` ``` MyStack(self, "MyStack", synthesizer=DefaultStackSynthesizer( file_assets_bucket_name='my-new-bucket-name' )) ``` ``` new MyStack(app, "MyStack", StackProps.builder() .synthesizer(DefaultStackSynthesizer.Builder.create() .fileAssetsBucketName("my-new-bucket-name") .build()) .build(); ) ``` ``` new MyStack(app, "MyStack", new StackProps { Synthesizer = new DefaultStackSynthesizer(new DefaultStackSynthesizerProps { FileAssetsBucketName = "my-new-bucket-name" }) }); ``` ``` func NewMyStack(scope constructs.Construct, id string, props *MyStackProps) awscdk.Stack { var sprops awscdk.StackProps if props != nil { sprops = props.StackProps } stack := awscdk.NewStack(scope, &id, &sprops) synth := awscdk.NewDefaultStackSynthesizer(&awscdk.DefaultStackSynthesizerProps{ FileAssetsBucketName: jsii.String("my-new-bucket-name"), }) stack.SetSynthesizer(synth) return stack } ``` ### Prévention Nous vous recommandons de démarrer de manière proactive chaque AWS environnement que vous prévoyez d'utiliser. Pour plus d'informations, consultez [Quand démarrer votre environnement.](bootstrapping-env.md#bootstrapping-env-when) Spécifiquement pour le problème de dénomination des compartiments Amazon S3, cela créera des compartiments Amazon S3 dans chaque AWS environnement et empêchera les autres d'utiliser le nom de votre compartiment Amazon S3.