Este é o Guia do Desenvolvedor AWS CDK v2. A versão CDK 1 mais antiga 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 AWS CDK
Inicialize seu AWS ambiente para prepará-lo para implantações em AWS Cloud Development Kit (AWS CDK) pilhas.
-
Para uma introdução aos ambientes, consulteAmbientes para o AWS CDK.
-
Para uma introdução ao bootstrapping, consulte. AWS CDK bootstrapping
Como inicializar seu ambiente
Você pode usar a interface de linha de AWS CDK comando (AWS CDK CLI) ou sua ferramenta de AWS CloudFormation implantação preferida para inicializar seu ambiente.
Use o CDK CLI
Você pode usar o CDK CLI cdk bootstrap
comando para inicializar seu ambiente. Esse é o método que recomendamos se você não precisar de modificações significativas na inicialização.
- Inicialize a partir de qualquer diretório de trabalho
-
Para inicializar a partir de qualquer diretório de trabalho, forneça o ambiente para inicializar como um argumento de linha de comando. Veja um exemplo a seguir:
$
cdk bootstrap
aws://123456789012/us-east-1
dica
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 AWS CLI comando a seguir 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 AWSconfig
e, use a--profile
opção para recuperar as informações da conta de um perfil específico. Veja um exemplo a seguir:$
aws sts get-caller-identity --profile
prod
Para exibir a região padrão, use o
aws configure get
comando:$
aws configure get region
$
aws configure get region --profile
prod
Ao fornecer um argumento, o
aws://
prefixo é opcional. O seguinte é válido:$
cdk bootstrap
123456789012/us-east-1
Para inicializar vários ambientes ao mesmo tempo, forneça vários argumentos:
$
cdk bootstrap
aws://123456789012/us-east-1 aws://123456789012/us-east-2
- Bootstrap a partir do diretório principal de um projeto CDK
-
Você pode executar a
cdk bootstrap
partir do diretório principal de um CDK projeto que contém umcdk.json
arquivo. Se você não fornecer um ambiente como argumento, o CDK CLI obterá informações do ambiente de fontes padrão, como seuscredentials
arquivosconfig
e ou qualquer informação de ambiente especificada para sua CDK pilha.Quando você inicializa a partir do diretório principal de um CDK projeto, os ambientes fornecidos pelos argumentos da linha de comando têm precedência sobre outras fontes.
Para inicializar um ambiente especificado em seus
credentials
arquivosconfig
e, use a--profile
opção:$
cdk bootstrap --profile
prod
Para obter mais informações sobre o cdk bootstrap
comando e as opções suportadas, consultecdk bootstrap.
Use qualquer AWS CloudFormation ferramenta
Você pode copiar o modelo de bootstrap do aws-cdkcdk 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 ou AWS Control Tower. Você também pode usar o AWS CloudFormation console ou o AWS Command Line Interface (AWS CLI). Você pode 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 --show-template
opção de recuperar e salvar o modelo de bootstrap em sua máquina local:
Para implantar esse modelo usando o CDK CLI, você pode executar o seguinte:
$
cdk bootstrap --template
bootstrap-template.yaml
Veja a seguir um exemplo de uso do AWS CLI para implantar o modelo:
Para obter informações sobre como usar CloudFormation StackSets para inicializar vários ambientes, consulte Bootstrapping multiple Contas da AWS for AWS CDK use CloudFormation StackSets
Quando inicializar seu ambiente
Você deve inicializar cada AWS ambiente antes de implantá-lo. Recomendamos que você inicialize proativamente cada ambiente que planeja usar. Você pode fazer isso antes de planejar realmente a implantação de CDK aplicativos no ambiente. Ao inicializar proativamente seus ambientes, você evita possíveis problemas futuros, como conflitos de nomes de buckets do Amazon S3 ou implantação de CDK aplicativos em ambientes que não foram inicializados.
Não há problema em inicializar um ambiente mais de uma vez. Se um ambiente já tiver sido inicializado, a pilha de bootstrap será atualizada, se necessário. Caso contrário, nada acontecerá.
Se você tentar implantar uma CDK pilha em um ambiente que não foi inicializado, 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 CDK equipe atualizará o modelo de bootstrap para uma nova versão. Quando isso acontece, recomendamos que você atualize sua pilha de bootstrap. Se você não personalizou o processo de inicialização, você pode atualizar sua pilha de bootstrap seguindo as mesmas etapas que você seguiu para inicializar originalmente seu ambiente. Para obter mais informações, consulte Histórico de versões do modelo Bootstrap.
Recursos padrão criados durante a inicialização
IAMfunções criadas durante a inicialização
Por padrão, a inicialização provisiona as seguintes funções AWS Identity and Access Management (IAM) em seu ambiente:
-
CloudFormationExecutionRole
-
DeploymentActionRole
-
FilePublishingRole
-
ImagePublishingRole
-
LookupRole
CloudFormationExecutionRole
-
Essa IAM função é 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 AWS API chamadas 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 o CDK CLI determinaria o que CloudFormation é permitido fazer.
DeploymentActionRole
-
Essa IAM função concede permissão para realizar implantações em seu ambiente. É assumido pelo CDK CLI durante 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
-
Essa IAM função concede permissão para realizar ações no bucket inicializado do Amazon Simple Storage Service (Amazon S3), incluindo o upload e a exclusão de ativos. É assumido pelo CDK CLI durante implantações.
ImagePublishingRole
-
Essa IAM função concede permissão para realizar ações no repositório inicializado do Amazon Elastic Container Registry (ECRAmazon). É assumido pelo CDK CLI durante implantações.
LookupRole
-
Essa IAM função concede
readOnly
permissão para pesquisar valores de contexto do AWS ambiente. É assumido pelo CDK CLI 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-
qualifier
-description
-account-ID
-Region
-
Qualificador — Um valor de cadeia de caracteres exclusivo de nove caracteres de
hnb659fds
. O valor real não tem significado. -
Descrição — Uma breve descrição do recurso. Por exemplo,
container-assets
. -
ID da conta — A Conta da AWS ID do ambiente.
-
Região — O Região da AWS do meio ambiente.
A seguir está um exemplo de ID física do bucket de armazenamento do Amazon S3 criado durante a inicialização:. cdk-hnb659fds-assets-012345678910-us-west-1
Permissões para usar ao inicializar seu ambiente
Ao inicializar um AWS ambiente, a IAM identidade 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 bootstrap, 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 inicializar um ambiente.
Personalize o bootstrapping
Se o modelo de bootstrap padrão não atender às suas necessidades, você pode personalizar a inicialização de recursos em seu ambiente das seguintes maneiras:
-
Use as opções da linha de
cdk bootstrap
comando com o comando — Esse método é melhor para fazer alterações pequenas e específicas que são suportadas pelas opções da linha de comando. -
Modifique o modelo de bootstrap 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 a inicialização.
Para obter mais informações sobre como personalizar a inicialização, consulte. Personalize o AWS CDK bootstrapping
Inicialização com pipelines CDK
Se você estiver usando 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 as IAM funções apropriadas não existem no outro ambiente. A causa mais provável é que o ambiente não tenha sido inicializado. Inicialize o ambiente e tente novamente.
Protegendo sua pilha de bootstrap contra exclusão
Se uma pilha de bootstrap for excluída, os AWS recursos que foram originalmente provisionados no ambiente para dar suporte às CDK implantações 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 for inicializado, não exclua e recrie a pilha de bootstrap do ambiente. Em vez disso, tente atualizar a pilha de bootstrap para uma nova versão executando o cdk bootstrap
comando novamente.
Para se proteger contra a exclusão acidental de sua pilha de bootstrap, recomendamos que você forneça a --termination-protection
opção com o cdk bootstrap
comando para ativar a proteção contra encerramento. Você pode ativar a proteção contra encerramento em pilhas de bootstrap novas ou existentes. Para obter instruções sobre como ativar a proteção contra encerramento, consulte Habilitar proteção contra encerramento para a pilha de bootstrap.
Histórico de versões do modelo Bootstrap
O modelo de bootstrap é versionado e evolui ao longo do tempo com o próprio. AWS CDK Se você fornecer seu próprio modelo de bootstrap, mantenha-o atualizado com o modelo padrão canônico. Você quer garantir que seu modelo continue funcionando com todos os CDK recursos.
nota
As versões anteriores do modelo de bootstrap criavam um AWS KMS key em cada ambiente inicializado por padrão. Para evitar cobranças pela KMS chave, reinicialize esses ambientes usando o. --no-bootstrap-customer-key
O padrão atual é sem KMS chave, 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 CDK versão | Alterações |
---|---|---|
1 | 1.40.0 | Versão inicial do modelo com Bucket, Key, Repository e Roles. |
2 | 1.45.0 | Divida a função de publicação de ativos em funções separadas de publicação de arquivos e imagens. |
3 | 1.46.0 | Adicione FileAssetKeyArn exportação para poder adicionar permissões de descriptografia aos consumidores de ativos. |
4 | 1.61.0 | AWS KMS as permissões agora estão implícitas via Amazon S3 e não são mais necessárias. FileAsetKeyArn Adicione um CdkBootstrapVersion SSM parâmetro para que a versão da pilha de bootstrap possa ser verificada sem saber o nome da pilha. |
5 | 1.87.0 | A função de implantação pode ler SSM o parâmetro. |
6 | 1.108.0 | Adicione uma função de pesquisa separada da função de implantação. |
6 | 1.109.0 | Anexe a aws-cdk:bootstrap-role tag às funções de implantação, publicação de arquivos e publicação de imagens. |
7 | 1.10.0 | A função 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 | A função de pesquisa tem permissões completas de somente leitura para o ambiente de destino e também tem uma aws-cdk:bootstrap-role tag. |
9 | 2.1.0 | Impede que os uploads de ativos do Amazon S3 sejam rejeitados pela criptografia comumente referenciada. SCP |
10 | 2.4.0 | A Amazon agora ECR ScanOnPush está habilitada por padrão. |
11 | 2.18.0 | Adiciona uma política que permite que o Lambda extraia dos ECR repositórios da Amazon para que ele sobreviva à reinicialização. |
12 | 2.20.0 | Adiciona suporte para testes experimentaiscdk import. |
13 | 2.25.0 | Torna imutáveis as imagens de contêiner nos repositórios Amazon ECR criados pelo bootstrap. |
14 | 2.34.0 | Por padrão, desativa a digitalização de ECR imagens da Amazon no nível do repositório para permitir a inicialização de regiões que não suportam a digitalização de imagens. |
15 | 2.60,0 | KMSas chaves não podem ser marcadas. |
16 | 2.69,0 | Aborda a descoberta do Security Hub KMS.2. |
17 | 2.72.0 | Aborda a descoberta do Security Hub ECR.3. |
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. (#27964 |
20 | 2.119.0 | Adicione ssm:GetParameters ação à IAM função de AWS CloudFormation implantação. Para obter mais informações, consulte #28336 |
21 | 2.149.0 | Adicione condição à função de publicação de arquivos. |
22 | 2.160,0 | Adicione sts:TagSession permissões à política de confiança das IAM funções de bootstrap. |
23 | 2.161.0 | Adição cloudformation:RollbackStack e cloudformation:ContinueUpdateRollback permissões à política de confiança da IAM função de implantação. Isso fornece permissões para o cdk
rollback comando. |
Atualize do modelo de bootstrap legado para o moderno
A AWS CDK v1 suportava dois modelos de bootstrap, antigos e modernos. CDKA v2 suporta apenas o modelo moderno. Para referência, aqui estão as diferenças de alto nível entre esses dois modelos.
Atributo | Legacy (somente v1) | Moderno (v1 e v2) |
---|---|---|
Implantações 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 bootstrap foi provisionada (por exemplo, usando) --trust |
Versionamento | Apenas uma versão da pilha de bootstrap está disponível | A pilha do Bootstrap é versionada; novos recursos podem ser adicionados em versões futuras e os AWS CDK aplicativos podem exigir uma versão mínima |
Recursos * | Bucket do Amazon S3 | Bucket do Amazon S3 |
AWS KMS key | ||
IAMfunções | ||
ECRRepositório Amazon | ||
SSMparâmetro para controle de versão | ||
Nomeação de recursos | Gerado automaticamente | Deterministic |
Criptografia de bucket | Tecla padrão | AWS chave gerenciada por padrão. Você pode personalizar para usar uma chave gerenciada pelo cliente. |
* Adicionaremos recursos adicionais ao modelo de bootstrap conforme necessário.
Um ambiente que foi inicializado usando o modelo legado deve ser atualizado para usar o modelo moderno para v2 por CDK meio da reinicialização. Reimplante todos os AWS CDK aplicativos no ambiente pelo menos uma vez antes de excluir o bucket legado.
Aborde as descobertas do Security Hub
Se você estiver usando AWS Security Hub, poderá ver descobertas relatadas sobre alguns dos recursos criados pelo processo de AWS CDK inicialização. 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] IAM os diretores não devem ter políticas IAM embutidas que permitam ações de descriptografia em todas as chaves KMS
A função deploy (DeploymentActionRole
) concede permissão para ler dados criptografados, o que é necessário para implantações entre contas com CDK Pipelines. As políticas nessa função não concedem permissão a todos os dados. Ele só concede permissão para ler dados criptografados do Amazon S3 e AWS KMS 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 na função 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 Condition
cláusula Resource: *
combinada com uma. O Security Hub sinaliza o *
curinga. Esse curinga é usado porque, no momento em que a conta é inicializada, a AWS KMS chave 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 Condition
cláusula ao levantar essa bandeira. Isso Resource: *
se Condition
restringe às solicitações feitas com Conta da AWS a mesma AWS KMS chave. Essas solicitações devem vir do Amazon S3 da Região da AWS mesma forma que a chave. AWS KMS
Preciso corrigir essa descoberta?
Desde que você não tenha modificado a AWS KMS chave 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 esse achado.
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, encontrar e usar CDK Pipelines para implantações entre contas
-
Se você não tiver feito isso, implante a pilha de CDK bootstrap usando o
cdk bootstrap
comando. -
Se você ainda não tiver feito isso, crie e implante seu CDK PipelinePara obter instruções, consulte Integração e entrega contínuas (CI/CD) usando CDK Pipelines.
-
Obtenha a AWS KMS chave ARN do balde de CodePipeline artefatos. Esse recurso é criado durante a criação do pipeline.
-
Obtenha uma cópia do modelo de CDK bootstrap para modificá-lo. Veja a seguir um exemplo, usando o AWS CDK CLI:
$
cdk bootstrap --show-template > bootstrap-template.yaml
-
Modifique o modelo
Resource: *
substituindo aPipelineCrossAccountArtifactsKey
declaração pelo seu ARN valor. -
Implante o modelo para atualizar sua pilha de bootstrap. Veja a seguir um exemplo, usando o CDK CLI:
$
cdk bootstrap aws://
account-id
/region
--template bootstrap-template.yaml
Para corrigir a descoberta do Security Hub se você não está usando CDK Pipelines para implantações entre contas
-
Obtenha uma cópia do modelo de CDK bootstrap para modificá-lo. Veja a seguir um exemplo, usando o CDK CLI:
$
cdk bootstrap --show-template > bootstrap-template.yaml
-
Exclua as
PipelineCrossAccountArtifactsKey
instruçõesPipelineCrossAccountArtifactsBucket
e do modelo. -
Implante o modelo para atualizar sua pilha de bootstrap. Veja a seguir um exemplo, usando o CDK CLI:
$
cdk bootstrap aws://
account-id
/region
--template bootstrap-template.yaml
Considerações
Como a inicialização provisiona recursos em seu ambiente, você pode incorrer em AWS cobranças quando esses recursos são usados com o. AWS CDK