Este é o Guia do desenvolvedor do AWS CDK v2. O CDK v1 antigo entrou em manutenção em 1º de junho de 2022 e encerrou o suporte em 1º de junho de 2023. As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Inicialize seu ambiente para uso com o CDK AWS Inicialize seu AWS ambiente para prepará-lo para implantações de pilhas do AWS Cloud Development Kit (AWS CDK). + Para uma introdução aos ambientes, consulte [Ambientes para o AWS CDK.](environments.md) + Para uma introdução ao bootstrapping, consulte [Bootstrapping do AWS CDK](bootstrapping.md). ## Como fazer bootstrapping em seu ambiente Você pode usar a AWS CDK Command Line Interface (AWS CDK CLI) ou sua ferramenta de AWS CloudFormation implantação preferida para inicializar seu ambiente. **Use a CLI do CDK** É possível usar o comando `cdk bootstrap` da CLI do CDK para fazer o bootstrapping em seu ambiente. Esse é o método que recomendamos se você não precisar de modificações significativas no bootstrapping. **Inicialize a partir de qualquer diretório de trabalho** Para fazer o bootstrapping a partir de qualquer diretório de trabalho, forneça o ambiente no qual fazer o bootstrapping como um argumento de linha de comandos. Este é um exemplo: ``` $ cdk bootstrap ``` Se você não tiver o número AWS da sua conta, poderá obtê-lo no AWS Management Console. Você também pode usar o seguinte comando da AWS CLI para exibir as informações padrão da sua conta, incluindo o número da sua conta: ``` $ aws sts get-caller-identity ``` Se você nomeou perfis em seus `credentials` arquivos AWS `config` e, use a `--profile` opção para recuperar as informações da conta de um perfil específico. Este é um exemplo: ``` $ aws sts get-caller-identity --profile ``` Para exibir a região padrão, use o comando `aws configure get`: ``` $ aws configure get region $ aws configure get region --profile ``` Ao fornecer um argumento, o prefixo `aws://` é opcional. Veja o que é válido a seguir: ``` $ cdk bootstrap <123456789012/us-east-1> ``` Para fazer o bootstrapping em vários ambientes ao mesmo tempo, forneça vários argumentos: ``` $ cdk bootstrap ``` **Bootstrap a partir do diretório principal de um projeto CDK** É possível executar `cdk bootstrap` a partir do diretório principal de um projeto do CDK contendo um arquivo `cdk.json`. Se você não fornecer um ambiente como argumento, a CLI do CDK obterá informações do ambiente de fontes padrão, como seus arquivos `config` e `credentials` ou qualquer informação de ambiente especificada para sua pilha do CDK. Quando você inicializa a partir do diretório principal de um projeto do CDK, os ambientes fornecidos a partir de argumentos de linha de comandos têm precedência sobre outras fontes. Para fazer o bootstrapping em um ambiente especificado em seus arquivos `config` e `credentials`, use a opção `--profile`: ``` $ cdk bootstrap --profile ``` Para obter mais informações sobre o comando `cdk bootstrap` e opções com suporte, consulte [cdk bootstrap](ref-cli-cmd-bootstrap.md). **Use qualquer AWS CloudFormation ferramenta** Você pode copiar o [modelo de bootstrap](https://github.com/aws/aws-cdk-cli/blob/main/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml) do *aws-cdk-cli GitHub repositório* ou obter o modelo com o `cdk bootstrap --show-template` comando. Em seguida, use qualquer AWS CloudFormation ferramenta para implantar o modelo em seu ambiente. Com esse método, você pode usar AWS CloudFormation StackSets nosso AWS Control Tower. Você também pode usar o AWS CloudFormation console ou a Interface de Linha de AWS Comando (AWS CLI). É possível fazer modificações no seu modelo antes de implantá-lo. Esse método pode ser mais flexível e adequado para implantações em grande escala. Veja a seguir um exemplo de como usar a opção `--show-template` para recuperar e salvar o modelo de bootstrapping em sua máquina local: **Example** ``` $ cdk bootstrap --show-template > bootstrap-template.yaml ``` No Windows, PowerShell deve ser usado para preservar a codificação do modelo. ``` powershell "cdk bootstrap --show-template | Out-File -encoding utf8 bootstrap-template.yaml" ``` Se os avisos do CDK estiverem aparecendo na saída AWS CloudFormation do modelo, forneça a `--no-notices` opção com seu comando. Para implantar esse modelo usando a CLI do CDK, é possível executar o seguinte: ``` $ cdk bootstrap --template ``` Veja a seguir um exemplo do uso da AWS CLI para implantar o modelo: **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 ``` Para obter informações sobre como usar CloudFormation StackSets para inicializar vários ambientes, consulte Como [inicializar várias AWS contas para AWS CDK usando CloudFormation StackSets](https://aws.amazon.com/blogs/mt/bootstrapping-multiple-aws-accounts-for-aws-cdk-using-cloudformation-stacksets/) no blog * AWS Cloud* Operations & Migrations. ## Quando fazer bootstrapping em seu ambiente Você deve inicializar cada AWS ambiente antes de implantá-lo no ambiente. Recomendamos que você fazer o bootstrapping proativamente em cada ambiente que planeja usar. É possível fazer isso antes de planejar realmente implantar aplicações do CDK no ambiente. Ao fazer o bootstrapping proativamente em seus ambientes, você evita possíveis problemas futuros, como conflitos de nomes de buckets do Amazon S3 ou implantação de aplicações do CDK em ambientes que não receberam o bootstrapping. Não há problema em fazer o bootstrapping em um ambiente mais de uma vez. Se um ambiente já tiver recebido o bootstrapping, a pilha de bootstrapping será atualizada, se necessário. Caso contrário, nada acontecerá. Se você tentar implantar uma pilha do CDK em um ambiente em que não foi feito o bootstrapping, você verá um erro como o seguinte: ``` $ 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) ``` **Atualize sua pilha de bootstrap** Periodicamente, a equipe do CDK atualizará o modelo de bootstrapping para uma nova versão. Quando isso acontece, recomendamos que você atualize a pilha de bootstrap. Se você não personalizou o processo de bootstrapping, é possível atualizar sua pilha de bootstrapping seguindo as mesmas etapas que você seguiu para fazer o bootstrapping originalmente em seu ambiente. Para obter mais informações, consulte [Histórico de versões de modelos de bootstrapping](#bootstrap-template-history). ## Recursos padrão criados durante o bootstrapping **Funções do IAM criadas durante a inicialização** Por padrão, a inicialização provisiona as seguintes funções de AWS Identity and Access Management (IAM) em seu ambiente: + `CloudFormationExecutionRole` + `DeploymentActionRole` + `FilePublishingRole` + `ImagePublishingRole` + `LookupRole` `CloudFormationExecutionRole` Essa função do IAM é uma função CloudFormation de serviço que concede CloudFormation permissão para realizar implantações de pilha em seu nome. Essa função dá CloudFormation permissão para realizar chamadas de AWS API em sua conta, incluindo a implantação de pilhas. Ao usar uma função de serviço, as permissões provisionadas para a função de serviço determinam quais ações podem ser executadas em seus CloudFormation recursos. Sem essa função de serviço, as credenciais de segurança que você fornece com a CLI do CDK determinariam o que CloudFormation é permitido fazer. `DeploymentActionRole` Esse perfil do IAM concede permissões para realizar implantações em seu ambiente. É assumido pela CLI do CDK durante as implantações. Ao usar uma função para implantações, você pode realizar implantações em várias contas, pois a função pode ser assumida por AWS identidades em uma conta diferente. `FilePublishingRole` Esse perfil do IAM concede permissões para a execução de ações no bucket de bootstrapping do Amazon Simple Storage Service (Amazon S3), incluindo o carregamento e a exclusão de ativos. É assumido pela CLI do CDK durante as implantações. `ImagePublishingRole` Esse perfil do IAM concede permissões para a execução de ações no repositório de bootstrapping do Amazon Elastic Container Registry (Amazon ECR). É assumido pela CLI do CDK durante as implantações. `LookupRole` Essa função do IAM concede `readOnly` permissão para pesquisar [valores de contexto](context.md) do AWS ambiente. É assumido pela CLI do CDK ao executar tarefas como síntese e implantações de modelos. **Recurso IDs criado durante a inicialização** Quando você implanta o modelo de bootstrap padrão, recursos físicos IDs para bootstrap são criados usando a seguinte estrutura:. `cdk----` + **Qualificador**: um valor de string exclusivo de nove caracteres de `hnb659fds`. O valor real não tem significado. + **Descrição**: uma descrição breve do recurso. Por exemplo, .`container-assets` + **ID da conta** — A ID da AWS conta do ambiente. + **Região** — A AWS região do meio ambiente. A seguir está um exemplo de ID físico do bucket de armazenamento do Amazon S3 criado durante a o bootstrapping: `cdk-hnb659fds-assets-012345678910-us-west-1`. ## Permissões para usar ao fazer bootstrapping em seu ambiente Ao inicializar um AWS ambiente, a identidade do IAM que executa a inicialização deve ter pelo menos as seguintes permissões: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*", "ecr:*", "ssm:*", "s3:*", "iam:*" ], "Resource": "*" } ] } ``` Com o tempo, a pilha de bootstrapping, incluindo os recursos criados e as permissões que eles exigem, pode mudar. Com futuras alterações, talvez seja necessário modificar as permissões necessárias para fazer bootstrapping em um ambiente. ## Personalizar o bootstrapping Se o modelo de bootstrapping padrão não atender às suas necessidades, é possível personalizar a o bootstrapping de recursos em seu ambiente das seguintes maneiras: + Use as opções da linha de comandos com o comando `cdk bootstrap`: esse método é melhor para fazer alterações pequenas e específicas que são compatíveis com as opções da linha de comandos. + Modifique o modelo de bootstrapping padrão e implante-o: esse método é melhor para fazer alterações complexas ou se você quiser controle total sobre a configuração dos recursos provisionados durante o bootstrapping. [Para obter mais informações sobre como personalizar a inicialização, consulte Personalizar a inicialização do CDK. AWS](bootstrapping-customizing.md) ## Bootstrapping com CDK Pipelines Se você estiver usando o CDK Pipelines para implantar no ambiente de outra conta e receber uma mensagem como a seguinte: ``` Policy contains a statement with one or more invalid principals ``` Essa mensagem de erro significa que os perfis do IAM apropriados não existem no outro ambiente. A causa mais provável é que o ambiente não tenha recebido o bootstrapping. Faça o bootstrapping no ambiente e tente novamente. **Proteger sua pilha de bootstrapping contra exclusão** Se uma pilha de bootstrap for excluída, os AWS recursos que foram originalmente provisionados no ambiente para suportar implantações de CDK também serão excluídos. Isso fará com que o pipeline pare de funcionar. Se isso acontecer, não há solução geral para recuperação. Depois que seu ambiente receber o bootstrapping, não exclua e recrie a pilha de bootstrapping do ambiente. Em vez disso, tente atualizar a pilha de bootstrapping para uma nova versão executando o comando `cdk bootstrap` novamente. Para se proteger contra a exclusão acidental de sua pilha de bootstrapping, recomendamos que você forneça a opção `--termination-protection` com o comando `cdk bootstrap` para ativar a proteção contra encerramento. É possível ativar a proteção contra encerramento em pilhas de bootstrapping novas ou existentes. Para instruções sobre como ativar a proteção contra encerramento, consulte [Habilitar proteção contra encerramento para a pilha de bootstrap](bootstrapping-customizing.md#bootstrapping-customizing-cli-protection). ## Histórico de versões do modelo de bootstrap O modelo de bootstrap é versionado e evolui com o tempo com o próprio CDK. AWS Se você fornecer seu próprio modelo de bootstrapping, mantenha-o atualizado com o modelo padrão canônico. Você quer garantir que seu modelo continue funcionando com todos os atributos do CDK. **nota** As versões anteriores do modelo de bootstrap criavam uma chave AWS KMS em cada ambiente inicializado por padrão. Para evitar cobranças pela chave do KMS, faça o bootstrapping nesses ambientes novamente usando o `--no-bootstrap-customer-key`. O padrão atual é a ausência de chave do KMS, o que ajuda a evitar essas cobranças. Esta seção contém uma lista das alterações feitas em cada versão. | Versão do modelo | AWS Versão CDK | Alterações | | --- | --- | --- | | **1** | 1.40.0 | Versão inicial do modelo com bucket, chave, repositório e perfis. | | **2** | 1.45,0 | Divida o perfil de publicação de ativos em perfis separados de publicação de arquivos e imagens. | | **3** | 1.46.0 | Adicione a exportação `FileAssetKeyArn` para poder adicionar permissões de descriptografia aos consumidores de ativos. | | **4** | 1.61.0 | AWS As permissões do KMS agora estão implícitas via Amazon S3 e não são mais necessárias. `FileAssetKeyArn` Adicione o parâmetro `CdkBootstrapVersion` do SSM para que a versão da pilha de bootstrapping possa ser verificada sem saber o nome da pilha. | | **5** | 1.87.0 | O perfil de implantação pode ler o parâmetro do SSM. | | **6** | 1.108.0 | Adicione um perfil de pesquisa separado do perfil de implantação. | | **6** | 1.109.0 | Anexe a tag `aws-cdk:bootstrap-role` aos perfis de implantação, publicação de arquivos e publicação de imagens. | | **7** | 1.10.0 | O perfil de implantação não pode mais ler buckets diretamente na conta de destino. (No entanto, essa função é efetivamente de administrador e, de qualquer forma, sempre pode usar suas AWS CloudFormation permissões para tornar o bucket legível). | | **8** | 1.14.0 | O perfil de pesquisa tem permissões somente leitura completas para o ambiente de destino e também tem uma tag `aws-cdk:bootstrap-role`. | | **9** | 2.1.0 | Impede que os carregamentos de ativos do Amazon S3 sejam rejeitados pela criptografia SCP comumente referenciada. | | **10** | 2.4.0 | O Amazon ECR agora ScanOnPush está habilitado por padrão. | | **11** | 2.18.0 | Adiciona uma política que permite que o Lambda extraia dos repositórios do Amazon ECR para que ele sobreviva à nova realização do bootstrapping. | | **12** | 2.20.0 | Adiciona suporte para `cdk import` experimentais. | | **13** | 2.25.0 | Torna imutáveis as imagens de contêiner nos repositórios do Amazon ECR criados pelo bootstrap. | | **14** | 2.34.0 | Por padrão, desativa a verificação de imagens do Amazon ECR no nível do repositório para permitir o bootstrapping de regiões que não oferecem suporte à verificação de imagens. | | **15** | 2.60,0 | As chaves do KMS não podem ser marcadas com tags. | | **16** | 2.69,0 | Aborda a descoberta [KMS.2](https://docs.aws.amazon.com/securityhub/latest/userguide/kms-controls.html#kms-2) do Security Hub. | | **17** | 2.72.0 | Aborda a descoberta [ECR.3](https://docs.aws.amazon.com/securityhub/latest/userguide/ecr-controls.html#ecr-3) do Security Hub. | | **18** | 2.80,0 | Alterações revertidas feitas para a versão 16, pois elas não funcionam em todas as partições e não são recomendadas. | | **19** | 2.106.1 | Alterações revertidas feitas na versão 18, em que a AccessControl propriedade foi removida do modelo. ([\$127.964](https://github.com/aws/aws-cdk/issues/27964)) | | **20** | 2.119.0 | Adicione `ssm:GetParameters` ação à função de AWS CloudFormation implantação do IAM. Para obter mais informações, consulte a [\$128336](https://github.com/aws/aws-cdk/pull/28336/files#diff-4fdac38426c4747aa17d515b01af4994d3d2f12c34f7b6655f24328259beb7bf). | | **21** | 2.149.0 | Adicione uma condição ao perfil de publicação de arquivos. | | **22** | 2.160,0 | Adicione permissões `sts:TagSession` à política de confiança dos perfis do IAM de bootstrap. | | **23** | 2.161,0 | Adicione as permissões `cloudformation:RollbackStack` e `cloudformation:ContinueUpdateRollback` à política de confiança do perfil do IAM de implantação. Isso fornece permissões para o comando `cdk rollback`. | | **24** | 2.165.0 | Alteração da duração dos dias em que os objetos não atuais no bucket de bootstrapping serão retidos, de 365 para 30 dias. Como o novo comando `cdk gc` introduz a capacidade de excluir objetos no bucket de bootstrapping, esse novo comportamento garante que os objetos excluídos permaneçam no bucket de bootstrapping por 30 dias em vez de 365 dias. Para obter mais informações sobre essa alteração, consulte `aws-cdk` PR [\$131949](https://github.com/aws/aws-cdk/pull/31949) | | **25** | 2.165.0 | Adição de suporte ao bucket de bootstrapping para a remoção de uploads incompletos de várias partes. Os uploads incompletos de várias partes serão excluídos após 1 dia. Para obter mais informações sobre essa alteração, consulte `aws-cdk` PR [\$131956](https://github.com/aws/aws-cdk/pull/31956) | | **26** | 2.1002.0 | Adição de duas políticas relacionadas à exclusão (`UpdateReplacePolicy` e `DeletionPolicy`) ao recurso `FileAssetsBucketEncryptionKey`. Essas políticas garantem que o recurso de chave AWS KMS antigo seja excluído adequadamente quando a pilha de bootstrap for atualizada ou excluída. Para obter mais informações sobre essa alteração, consulte `aws-cdk-cli` PR [\$1100](https://github.com/aws/aws-cdk-cli/pull/100) | | **27** | 2.1003.0 | Adição de uma nova política de recursos do Amazon EMR para conceder ao Amazon EMR Sem Servidor permissões específicas para a recuperação de imagens de contêineres. Para obter mais informações sobre essa alteração, consulte `aws-cdk-cli` PR [\$1112](https://github.com/aws/aws-cdk-cli/pull/112) | | **28** | 2.1015.0 | Adicione permissões para realizar ações do Stack Refactoring à função de implantação e TagSession permissões a todas as funções. Para obter mais informações sobre essa mudança, consulte `aws-cdk-cli` PR [\$1471](https://github.com/aws/aws-cdk-cli/pull/471). | | **29** | 2.1026.0 | Todas as AssumeRole chamadas que fornecem um ExternalId serão rejeitadas por padrão, a menos que sejam desativadas. Para obter mais informações sobre essa mudança, consulte `aws-cdk-cli` PR [\$1811](https://github.com/aws/aws-cdk-cli/pull/811). | | **30** | 2.1034,0 | Adicione permissões para descrever eventos de pilha à função de implantação para poder mostrar erros de validação CloudFormation antecipada com precisão. Para obter mais informações sobre essa mudança, consulte `aws-cdk-cli` PR [\$1970](https://github.com/aws/aws-cdk-cli/pull/970). | ## Atualizar do modelo de bootstrapping legado para o moderno O AWS CDK v1 suportava dois modelos de bootstrap, antigos e modernos. O CDK v2 oferece suporte somente ao modelo moderno. Para referência, aqui estão as diferenças de alto nível entre esses dois modelos. | Recurso | Legado (somente v1) | Moderno (v1 e v2) | | --- | --- | --- | | **Implantação entre contas** | Não permitido | Permitido | | ** AWS CloudFormation Permissões** | Implanta usando as permissões atuais do usuário (determinadas pelo AWS perfil, variáveis de ambiente etc.) | Implanta usando as permissões especificadas quando a pilha de bootstrapping foi provisionada (por exemplo, usando `--trust`) | | **Versionamento** | Apenas uma versão da pilha de bootstrapping está disponível | A pilha do Bootstrap tem versão; novos recursos podem ser adicionados em versões futuras e os aplicativos AWS CDK podem exigir uma versão mínima | | **Recursos**\$1 | Bucket do Amazon S3. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/cdk/v2/guide/bootstrapping-env.html) | | ** AWS Chave KMS** | Perfis do IAM | Repositório do Amazon ECR | | **Nomenclatura de recursos** | Gerado automaticamente | Deterministic | | **Criptografia do bucket** | Chave padrão | AWS chave gerenciada por padrão. É possível personalizar o uso de uma chave gerenciada pelo cliente. | + *Adicionaremos recursos extras ao modelo de bootstrapping conforme necessário.* Um ambiente em que foi feito o bootstrapping usando o modelo legado deve ser atualizado para usar o modelo moderno do CDK v2 por meio de um novo bootstrapping. Reimplante todos os aplicativos AWS CDK no ambiente pelo menos uma vez antes de excluir o bucket legado. ## Abordar descobertas do Security Hub Se você estiver usando o AWS Security Hub, poderá ver descobertas relatadas sobre alguns dos recursos criados pelo processo de inicialização do AWS CDK. As descobertas do Security Hub ajudam você a encontrar configurações de recursos que você deve verificar novamente quanto à precisão e segurança. Analisamos essas configurações específicas de recursos com a AWS Security e temos certeza de que elas não constituem um problema de segurança. **[KMS.2] Os diretores do IAM não devem ter políticas embutidas do IAM que permitam ações de descriptografia em todas as chaves do KMS** O *perfil de implantação* (`DeploymentActionRole`) concede permissão para ler dados criptografados, o que é necessário para implantações entre contas com o CDK Pipelines. As políticas nesse perfil não concedem permissão a todos os dados. Ele só concede permissão para ler dados criptografados do Amazon S3 e do AWS KMS, e somente quando esses recursos permitem isso por meio de seu bucket ou política de chaves. Veja a seguir um trecho dessas duas declarações no *perfil de implantação* do modelo de 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 ... ``` **Por que o Security Hub sinaliza isso?** As políticas contêm uma cláusula `Resource: *` combinada com uma `Condition`. O Security Hub sinaliza o curinga `*`. Esse caractere curinga é usado porque, no momento em que a conta é inicializada, a chave AWS KMS criada pelo CDK Pipelines para o repositório de CodePipeline artefatos ainda não existe e, portanto, não pode ser referenciada no modelo de bootstrap pelo ARN. Além disso, o Security Hub não considera a cláusula `Condition` ao levantar essa bandeira. Isso `Resource: *` se `Condition` restringe às solicitações feitas da mesma AWS conta da chave AWS KMS. Essas solicitações devem vir do Amazon S3 na mesma AWS região da chave AWS KMS. **Preciso corrigir essa descoberta?** Desde que você não tenha modificado a chave AWS KMS em seu modelo de bootstrap para ser excessivamente permissiva, a *função de implantação* não permite mais acesso do que o necessário. Portanto, não é necessário corrigir essa descoberta. **E se eu quiser corrigir essa descoberta?** A forma como você corrige essa descoberta depende se você usará ou não o CDK Pipelines para implantações entre contas. **Para corrigir o Security Hub, encontre e use o CDK Pipelines para implantações entre contas** 1. Se ainda não o tiver feito isso, implante a pilha de bootstrapping do CDK usando o comando `cdk bootstrap`. 1. Se ainda não o tiver feito isso, crie e implante o Pipeline do CDK. Para obter instruções, consulte [Integração e entrega contínuas (CI/CD) usando CDK Pipelines](cdk-pipeline.md). 1. Obtenha o ARN da chave AWS KMS do bucket de artefatos CodePipeline . Esse recurso é criado durante a criação do pipeline. 1. Obtenha uma cópia do modelo de bootstrapping do CDK para modificá-lo. Veja a seguir um exemplo, usando a CLI do AWS CDK: ``` $ cdk bootstrap --show-template > bootstrap-template.yaml ``` 1. Modifique o modelo substituindo o `Resource: *` da declaração `PipelineCrossAccountArtifactsKey` pelo valor do ARN. 1. Implante o modelo para atualizar sua pilha de bootstrap. Veja a seguir um exemplo, usando a CLI do CDK: ``` $ cdk bootstrap aws:/// --template bootstrap-template.yaml ``` **Para corrigir a descoberta do Security Hub se você não está usando o CDK Pipelines para implantações entre contas** 1. Obtenha uma cópia do modelo de bootstrapping do CDK para modificá-lo. Veja a seguir um exemplo, usando a CLI do CDK: ``` $ cdk bootstrap --show-template > bootstrap-template.yaml ``` 1. Exclua as instruções `PipelineCrossAccountArtifactsBucket` e `PipelineCrossAccountArtifactsKey` do modelo. 1. Implante o modelo para atualizar sua pilha de bootstrap. Veja a seguir um exemplo, usando a CLI do CDK: ``` $ cdk bootstrap aws:/// --template bootstrap-template.yaml ``` ## Considerações Como o bootstrapping provisiona recursos em seu ambiente, você pode incorrer em AWS cobranças quando esses recursos são usados com o CDK. AWS # Personalização do bootstrapping do AWS CDK É possível personalizar o bootstrapping do kit de desenvolvimento em nuvem da AWS (CDK da AWS) usando a interface de linha de comandos do CDK da AWS (CLI do CDK da AWS) ou modificando e implantando o modelo de bootstrapping do AWS CloudFormation. Para uma introdução ao bootstrapping, consulte [Bootstrapping do CDK da AWS](bootstrapping.md). ## Use a CLI do CDK para personalizar o bootstrapping A seguir estão alguns exemplos de como é possível personalizar o bootstrapping usando a CLI do CDK. Para obter uma lista de todas as opções do `cdk bootstrap`, consulte [cdk bootstrap](ref-cli-cmd-bootstrap.md). **Substituir o nome do bucket do Amazon S** Use a opção `--bootstrap-bucket-name` para substituir o nome do bucket padrão do Amazon S3. Isso pode exigir que você modifique a síntese do modelo. Para obter mais informações, consulte [Personalização da síntese de pilhas do CDK](configure-synth.md#bootstrapping-custom-synth). **Modificar as chaves de criptografia no lado do servidor de bucket do Amazon S** Por padrão, o bucket do Amazon S3 na pilha de bootstrapping é configurado para usar chaves gerenciadas da AWS para criptografia do lado do servidor. Para usar uma chave gerenciada pelo cliente existente, use a opção `--bootstrap-kms-key-id` e forneça um valor para a chave do AWS Key Management Service (AWS KMS) a usar. Se você quiser mais controle sobre a chave de criptografia, forneça `--bootstrap-customer-key` para usar uma chave gerenciada pelo cliente. **Anexe políticas gerenciadas ao perfil de implantação assumido pelo AWS CloudFormation** Por padrão, as pilhas são implantadas com permissões totais de administrador usando a política `AdministratorAccess`. Para usar suas próprias políticas gerenciadas, use a opção `--cloudformation-execution-policies` e forneça os ARNs das políticas gerenciadas a serem anexadas ao perfil de implantação. Para fornecer várias políticas, passe a elas uma única string, separada por vírgulas: ``` $ cdk bootstrap --cloudformation-execution-policies "arn:aws:iam::aws:policy/AWSLambda_FullAccess,arn:aws:iam::aws:policy/AWSCodeDeployFullAccess" ``` Para evitar falhas na implantação, verifique se as políticas especificadas são suficientes para qualquer implantação que você executará no ambiente que está sendo inicializado. **Alterar o qualificador que é adicionado aos nomes dos recursos em sua pilha de bootstrap** Por padrão, o qualificador `hnb659fds` é adicionado ao ID físico dos recursos em sua pilha de bootstrap. Para alterar esse valor, use a opção `--qualifier`. Essa modificação é útil ao provisionar várias pilhas de bootstrapping no mesmo ambiente para evitar conflitos de nomes. A alteração do qualificador visa o isolamento de nomes entre testes automatizados do próprio CDK. A menos que você possa definir com precisão as permissões do IAM concedidas ao perfil de execução do CloudFormation, não há benefícios de isolamento de permissão em ter duas pilhas de bootstrapping diferentes em uma única conta. Portanto, geralmente não há necessidade de alterar esse valor. Quando você altera o qualificador, sua aplicação CDK deve passar o valor alterado para o sintetizador de pilha. Para obter mais informações, consulte [Personalização da síntese de pilhas do CDK](configure-synth.md#bootstrapping-custom-synth). **Adicionar tags à pilha de bootstrap** Use a opção `--tags` no formato de `KEY=VALUE` para adicionar tags do CloudFormation à sua pilha de bootstrap. **Especifique outras contas da AWS que possam implantar no ambiente que está sofrendo bootstrapping** Use a opção `--trust` para fornecer outras contas da AWS que têm permissão para implantar no ambiente que está sofrendo bootstrapping. Por padrão, a conta que executa o bootstrapping sempre será confiável. Essa opção é útil quando você está fazendo bootstrapping em um ambiente no qual um Pipeline do CDK de outro ambiente será implantado. Ao usar essa opção, você também deve fornecer `--cloudformation-execution-policies`. Para adicionar contas confiáveis a uma pilha de bootstrapping existente, é necessário especificar todas as contas confiáveis, incluindo aquelas que podem ter sido fornecidas anteriormente. Se você fornecer apenas novas contas confiáveis, as contas anteriormente confiáveis serão removidas. Veja a seguir um exemplo que confia em duas contas: ``` $ 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. ``` **Especifique outras contas da AWS que possam pesquisar informações no ambiente que está sofrendo bootstrapping** Use a opção `--trust-for-lookup` para especificar contas da AWS que têm a permissão de pesquisar informações de contexto do ambiente que está sofrendo bootstrapping. Essa opção é útil para dar permissão às contas para sintetizar pilhas que serão implantadas no ambiente, sem realmente dar a elas permissão para implantar essas pilhas diretamente. **Ative a proteção de encerramento para a pilha de bootstrap** Se uma pilha de bootstrapping for excluída, os recursos da AWS que foram originalmente provisionados no ambiente também serão excluídos. Depois que seu ambiente sofreu bootstrapping, recomendamos que você não exclua e recrie a pilha de bootstrapping do ambiente, a menos que esteja fazendo isso intencionalmente. Em vez disso, tente atualizar a pilha de bootstrapping para uma nova versão executando o comando `cdk bootstrap` novamente. Use a opção `--termination-protection` para gerenciar as configurações de proteção contra encerramento da pilha de bootstrap. Ao ativar a proteção contra encerramento na pilha, é possível impedir que uma pilha de bootstrapping e seus recursos sejam excluídos acidentalmente. Isso é especialmente importante se você usa Pipelines do CDK, pois não há opção geral de recuperação se você excluir acidentalmente a pilha de bootstrap. Depois de ativar a proteção contra encerramento, será possível usar a AWS CLI ou o console do AWS CloudFormation para verificar. **Para habilitar a proteção contra encerramento** 1. Execute o comando a seguir para ativar a proteção contra encerramento em uma pilha de bootstrapping nova ou existente: ``` $ cdk bootstrap --termination-protection ``` 1. Use a AWS CLI ou o console do CloudFormation para verificar. Veja a seguir um exemplo usando a AWS CLI. Se você modificou o nome da pilha de bootstrapping, substitua `CDKToolkit` pelo nome da pilha: ``` $ aws cloudformation describe-stacks --stack-name --query "Stacks[0].EnableTerminationProtection" true ``` ## Modificar o modelo de bootstrapping padrão Quando você precisar de mais personalização do que a CLI do CDK pode fornecer, é possível modificar o modelo de bootstrapping conforme necessário. Em seguida, implante o modelo para fazer o bootstrapping em seu ambiente. **Para modificar e implantar o modelo de bootstrapping padrão** 1. Obtenha o modelo de bootstrapping padrão usando a opção `--show-template`. Por padrão, a CLI do CDK exibirá o modelo na janela do terminal. É possível modificar o comando da CLI do CDK para salvar o modelo em sua máquina local. Veja um exemplo a seguir: ``` $ cdk bootstrap --show-template > ``` 1. Modifique o modelo de bootstrapping conforme necessário. Todas as alterações que você fizer devem seguir o modelo de contrato de bootstrap. Para obter mais informações sobre o modelo de contrato de bootstrapping, consulte [Siga o contrato de bootstrapping](#bootstrapping-contract). Para garantir que suas personalizações não sejam substituídas por acidente posteriormente por alguém executando o `cdk bootstrap` usando o modelo padrão, altere o valor padrão do parâmetro do modelo `BootstrapVariant`. A CLI do CDK só permitirá substituir a pilha de bootstrapping por modelos que tenham a mesma `BootstrapVariant` e uma versão igual ou superior ao modelo atualmente implantado. 1. Implante seu modelo modificado usando o método de implantação do AWS CloudFormation de sua preferência. Veja a seguir um exemplo que usa a CLI do CDK: ``` $ cdk bootstrap --template ``` ## Siga o contrato de bootstrap Para que suas aplicações do CDK sejam implantadas adequadamente, os modelos do CloudFormation produzidos durante a síntese devem especificar corretamente os recursos criados durante o bootstrapping. Esses recursos são comumente chamados de *recursos de bootstrap*. O bootstrapping cria recursos em seu ambiente da AWS que são usados pelo AWS CDK para realizar implantações e gerenciar ativos de aplicações. A síntese produz modelos do CloudFormation a partir de cada pilha do CDK em sua aplicação. Esses modelos não definem apenas os recursos da AWS que serão provisionados pela sua aplicação. Eles também especificam os recursos de bootstrapping a serem usados durante a implantação. Durante a síntese, a CLI do CDK não sabe especificamente como seu ambiente da AWS recebeu o bootstrapping. Em vez disso, a CLI do CDK produz modelos do CloudFormation com base no sintetizador que você configura. Portanto, ao personalizar o bootstrapping, talvez seja necessário personalizar a síntese. Para obter instruções sobre a personalização da síntese, consulte [Personalização da síntese de pilha do CDK](configure-synth.md#bootstrapping-custom-synth). O objetivo é garantir que seus modelos sintetizados do CloudFormation sejam compatíveis com seu ambiente que recebeu o bootstrapping. Essa compatibilidade é conhecida como *contrato de bootstrap*. O método mais simples para personalizar a síntese de pilhas é modificar a classe `DefaultStackSynthesizer` na sua instância de `Stack`. Se você precisar de personalização além do que essa classe pode oferecer, você pode escrever seu próprio sintetizador como uma classe que implementa ` [IStackSynthesizer](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.IStackSynthesizer.html) ` (talvez derivado de `DefaultStackSynthesizer`). Ao personalizar o bootstrapping, siga o contrato modelo de bootstrapping para permanecer compatível com `DefaultStackSynthesizer`. Se você modificar o bootstrapping além do contrato do modelo de bootstrapping, precisará escrever seu próprio sintetizador. ### Versionamento O modelo de bootstrapping deve conter um recurso para criar um parâmetro do Amazon EC2 Systems Manager (SSM) com um nome conhecido e uma saída que reflita a versão do modelo: ``` 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] ``` ### Perfis O `DefaultStackSynthesizer` requer cinco perfis do IAM para cinco propósitos diferentes. Se você não estiver usando os perfis padrão, deverá especificar os ARNs do perfil do IAM em seu objeto `DefaultStackSynthesizer`. Os perfis são os seguintes: + O *perfil de implantação* é assumido pela CLI do CDK e pelo AWS CodePipeline para implantar em um ambiente. O `AssumeRolePolicy` controla quem pode ser implantado no ambiente. No modelo, você pode ver as permissões que esse perfil precisa. + O *perfil de pesquisa* é assumido pela CLI do CDK para realizar pesquisas de contexto em um ambiente. O `AssumeRolePolicy` controla quem pode ser implantado no ambiente. As permissões que esse perfil precisa podem ser vistas no modelo. + O *perfil de publicação de arquivos* e o *perfil de publicação de imagens* são assumidos pela CLI do CDK e pelos projetos do AWS CodeBuild para publicar de ativos em um ambiente. Eles são usados para gravar no bucket do Amazon S3 e no repositório do Amazon ECR, respectivamente. Esses perfis exigem acesso de gravação a esses recursos. + *O perfil de execução do AWS CloudFormation* é passado ao AWS CloudFormation para realizar a implantação real. Suas permissões são as permissões sob as quais a implantação será executada. As permissões são passadas para a pilha como um parâmetro que lista os ARNs de políticas gerenciadas. ### Saídas A CLI do CDK exige que as saídas do CloudFormation a seguir existam na pilha de bootstrapping: + `BucketName`: o nome do bucket de ativos de arquivo. + `BucketDomainName`: o bucket de ativos de arquivo em formato de nome de domínio. + `BootstrapVersion`: a versão atual da pilha de bootstrap. ### Histórico do modelo O modelo de bootstrapping é versionado e evolui ao longo do tempo com o próprio AWS CDK. Se você fornecer seu próprio modelo de bootstrapping, mantenha-o atualizado com o modelo padrão canônico. Você quer garantir que seu modelo continue funcionando com todos os atributos do CDK. Para obter mais informações, consulte [Histórico de versões de modelos de bootstrapping](bootstrapping-env.md#bootstrap-template-history). # Criar e aplicar limites de permissões para o AWS CDK Um *limite de permissões* é um atributo avançado do AWS Identity and Access Management (IAM) que pode ser usado para definir o máximo de permissões que uma entidade do IAM, como um usuário ou um perfil, pode ter. É possível usar limites de permissões para restringir as ações que as entidades do IAM podem realizar ao usar o kit de desenvolvimento em nuvem da AWS (CDK da AWS). Para saber mais sobre limites de permissões, consulte [Limites de permissões para identidades do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) no *Guia do Usuário do IAM*. ## Quando usar limites de permissões com o AWS CDK Considere aplicar limites de permissões quando precisar impedir que os desenvolvedores em sua organização realizem determinadas ações com o AWS CDK. Por exemplo, se houver recursos específicos em seu ambiente da AWS que você não deseja que os desenvolvedores modifiquem, você pode criar e aplicar um limite de permissões. ## Como aplicar limites de permissões com o AWS CDK ### Criar o limite de permissões Primeiro, você cria um limite de permissões usando uma política gerenciada pela AWS ou uma política gerenciada pelo cliente para definir o limite para uma entidade (usuário ou perfil) do IAM. Essa política limita o número máximo de permissões para o usuário ou o perfil. Para obter mais instruções sobre a criação de limites de permissões, consulte [Limites de permissões para entidades do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) no *Guia do usuário do IAM*. Os limites de permissões definem o máximo de permissões que uma entidade do IAM pode ter, mas não concedem permissões sozinhas. É necessário usar limites de permissões com as políticas do IAM para limitar e conceder efetivamente as permissões adequadas para sua organização. Você também deve impedir que entidades do IAM consigam escapar dos limites que você definiu. Por exemplo, consulte [Delegar responsabilidade a outras pessoas usando limites de permissões](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-delegate) no *Guia do usuário do IAM*. ### Aplique o limite de permissões durante o bootstrapping Depois de criar o limite de permissões, é possível impô-lo ao AWS CDK ao aplicá-lo durante o bootstrapping. Use a opção [`--custom-permissions-boundary`](ref-cli-cmd-bootstrap.md#ref-cli-cmd-bootstrap-options-custom-permissions-boundary) e especifique o nome do limite de permissões a ser aplicado. Veja a seguir um exemplo que aplica um limite de permissões chamado `cdk-permissions-boundary`: ``` $ cdk bootstrap --custom-permissions-boundary ``` Por padrão, o CDK usa o perfil do IAM `CloudFormationExecutionRole`, definido no modelo de bootstrapping, para receber permissões para realizar implantações. Ao aplicar o limite de permissões personalizado durante o bootstrapping, o limite de permissões é anexado a esse perfil. O limite de permissões definirá então as permissões máximas que podem ser executadas pelos desenvolvedores em sua organização ao usar o AWS CDK. Para saber mais sobre esse perfil, consulte [Perfis do IAM criados durante o bootstrapping](bootstrapping-env.md#bootstrapping-env-roles). Quando você aplica limites de permissões desta forma, eles são aplicados ao ambiente específico que você inicializa. Para usar o mesmo limite de permissões em vários ambientes, você deve aplicar o limite de permissões para cada ambiente durante o bootstrapping. Você também pode aplicar limites de permissões diferentes para ambientes diferentes. ## Saiba mais Para obter mais informações sobre limites de permissões, consulte [Quando e onde usar os limites de permissões do IAM](https://aws.amazon.com/blogs/security/when-and-where-to-use-iam-permissions-boundaries/) no *Blog de segurança da AWS*. # Solução de problemas de bootstrapping do AWS CDK Solucione problemas comuns ao fazer o bootstrapping em seu ambiente com o kit de desenvolvimento em nuvem da AWS (CDK da AWS). + Para uma introdução ao bootstrapping, consulte [Bootstrapping do CDK da AWS](bootstrapping.md). + Para obter instruções sobre bootstrapping, consulte [Bootstrapping do seu ambiente para uso com o AWSCDK](bootstrapping-env.md). ## Ao inicializar usando o modelo padrão, você recebe um erro “CREATE\$1FAILED” para o bucket do Amazon S3 Ao fazer o bootstrapping usando o comando `cdk bootstrap` da interface de linha de comandos do AWS CDK (CLI do CDK) com o modelo de bootstrapping padrão, você recebe o seguinte erro: ``` CREATE_FAILED | AWS::S3::Bucket | already exists ``` Antes de solucionar o problema, verifique se está usando a versão mais recente da CLI do CDK. + Para verificar a versão, execute `cdk --version`. + Para instalar a versão mais recente, execute `npm install -g aws-cdk`. Depois de instalar a versão mais recente, tente fazer o bootstrapping em seu ambiente novamente. Se você ainda receber o mesmo erro, continue com a solução de problemas. ### Causas comuns Quando você faz o bootstrapping em seu ambiente, o AWS CDK gera IDs físicos para seus recursos de bootstrapping. Para obter mais informações, consulte [IDs de recursos criados durante o bootstrapping](bootstrapping-env.md#bootstrapping-env-default-id). Ao contrário dos outros recursos de bootstrapping, os nomes dos buckets do Amazon S3 são globais. Isso significa que cada nome de bucket deve ser exclusivo em todas as contas da AWS em todas as regiões da AWS dentro de uma partição. Para obter mais informações, consulte [Visão geral dos buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) no *Guia do usuário do Amazon S3*. Portanto, a causa mais comum desse erro é que o ID físico gerado como nome do bucket já existe em algum lugar dentro da partição. Isso pode acontecer na sua conta ou em outra conta. Veja a seguir um exemplo de nome de bucket: `cdk-hnb659fds-assets-012345678910-us-west-1`. Embora seja improvável, devido ao qualificador e ao ID da conta fazerem parte do nome, é possível que esse nome de um bucket do Amazon S3 seja usado por outra conta da AWS. Como os nomes dos buckets têm escopo global, eles não podem ser usados por você se forem usados por uma conta diferente na mesma partição. Provavelmente, existe um bucket com o mesmo nome em algum lugar da sua conta. Isso pode estar na região em que você está tentando fazer o bootstrapping ou em outra região. Geralmente, a solução é localizar esse bucket na sua conta e determinar o que fazer com ele, ou personalizar o bootstrapping para criar recursos de bootstrapping com um nome diferente. ### Resolução Primeiro, determine se existe um bucket com o mesmo nome na sua conta da AWS. Usando uma identidade da AWS com permissões válidas para pesquisar buckets do Amazon S3 em sua conta, você pode fazer isso das seguintes formas: + Use o comando `aws s3 ls` da interface de linha de comandos (AWS CLI) da AWS para ver uma lista de todos os seus buckets. + Procure nomes de bucket para cada região em sua conta usando o [console do Amazon S3](https://console.aws.amazon.com/s3). Se existir um bucket com o mesmo nome, determine se ele está sendo usado. Se ele não estiver sendo usado, considere excluir o bucket e tentar fazer o bootstrapping em seu ambiente novamente. Se existir um bucket com o mesmo nome e você não quiser excluí-lo, determine se ele já está associado a uma pilha de bootstrapping na sua conta. Talvez seja necessário verificar várias regiões. A região no nome do bucket do Amazon S3 não significa necessariamente que o bucket esteja nessa região. Para verificar se ela está associada à pilha de bootstrapping `CDKToolkit`, será possível seguir um destes procedimentos para cada região: + Use o comando `aws cloudformation describe-stack-resources --stack-name --region ` da AWS CLI para visualizar os recursos em sua pilha de bootstrapping e verificar se o bucket está relacionado. + No [console do AWS CloudFormation](https://console.aws.amazon.com/cloudformation), localize a pilha `CDKToolkit`. Em seguida, na guia **Recursos**, verifique se o bucket existe. Se o bucket estiver associado a uma pilha de bootstrapping, determine se a pilha de bootstrapping está na mesma região em que você está tentando fazer o bootstrapping. Se estiver, seu ambiente já recebeu o bootstrapping e você deve ser capaz de começar a usar o CDK para implantar aplicações em seu ambiente. Se o bucket do Amazon S3 estiver associado a uma pilha de bootstrapping em uma região diferente, você precisará determinar o que fazer. As possíveis soluções incluem renomear o bucket do Amazon S3 existente, excluir o bucket atual do Amazon S3 se ele não estiver sendo usado ou usar um novo nome para o bucket do Amazon S3 que você está tentando criar. Se você não conseguir localizar um bucket do Amazon S3 com o mesmo nome em sua conta, ele poderá existir em uma conta diferente. Para resolver isso, você precisará personalizar o bootstrapping para criar novos nomes para todos os seus recursos de bootstrapping ou apenas para seu bucket do Amazon S3. Para criar novos nomes para todos os recursos de bootstrapping, é possível modificar o qualificador. Para criar um novo nome somente para seu bucket do Amazon S3, será possível fornecer um novo nome de bucket. Para personalizar o bootstrapping, é possível usar as opções com o comando `cdk bootstrap` da CLI do CDK ou modificar o modelo de bootstrapping. Para obter instruções, consulte [Personalização do bootstrapping do AWS CDK](bootstrapping-customizing.md). Se você personalizar o bootstrapping, precisará aplicar as mesmas alterações à síntese antes de poder implantar adequadamente uma aplicação. Para instruções, consulte [Personalização da síntese de pilha do CDK](configure-synth.md#bootstrapping-custom-synth). Por exemplo, você pode fornecer um novo qualificador com `cdk bootstrap`: ``` $ cdk bootstrap --qualifier ``` Veja a seguir um exemplo de nome de bucket do Amazon S3 que será criado com essa modificação: `cdk-abcde0123-assets-012345678910-us-west-1`. Todos os recursos de bootstrapping criados durante o bootstrapping usarão esse qualificador. Ao desenvolver sua aplicação do CDK, você deve especificar seu qualificador personalizado em seu sintetizador. Isso ajuda o CDK a identificar seus recursos de bootstrapping durante a síntese e a implantação. Veja a seguir um exemplo de como personalizar o sintetizador padrão para sua instância de pilha: **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 } ``` Você também pode especificar o novo qualificador no arquivo `cdk.json` do seu projeto do CDK: ``` { "app": "...", "context": { "@aws-cdk/core:bootstrapQualifier": "abcde0123" } } ``` Para modificar somente o nome do bucket do Amazon S3, você pode usar a opção ` --bootstrap-bucket-name `. Veja um exemplo a seguir: ``` $ cdk bootstrap --bootstrap-bucket-name '' ``` Ao desenvolver sua aplicação do CDK, você deve especificar o nome do novo bucket no sintetizador. Veja a seguir um exemplo de como personalizar o sintetizador padrão para sua instância de pilha: **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 } ``` ### Prevenção Recomendamos que você fazer o bootstrapping proativamente em cada ambiente da AWS que planeja usar. Para obter mais informações, consulte [Quando fazer o bootstrapping do seu ambiente](bootstrapping-env.md#bootstrapping-env-when). Especificamente para o problema de nomenclatura do bucket do Amazon S3, isso criará buckets do Amazon S3 em cada ambiente da AWS e impedirá que outros usem o nome do seu bucket do Amazon S3.