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.

Como fazer bootstrapping em 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.

Usar o CDK  CLI

Você pode usar o CDK CLI cdk bootstrapcomando para inicializar seu ambiente. Esse é o método que recomendamos se você não precisar de modificações significativas no bootstrapping.

Para obter mais informações sobre o comando cdk bootstrap e opções compatíveis, consulte cdk bootstrap.

Use qualquer AWS CloudFormation ferramenta

Você pode copiar o modelo de bootstrap do aws-cdk-cli GitHub repositório ou obtenha 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 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 opção --show-template para recuperar e salvar o modelo de bootstrap em sua máquina local:

$ cdk bootstrap --show-template > bootstrap-template.yaml

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:

aws cloudformation create-stack \
  --stack-name CDKToolkit \
  --template-body file://path/to/bootstrap-template.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --region us-west-1

Para obter informações sobre como usar CloudFormation StackSets para inicializar vários ambientes, consulte Bootstrapping multiple Contas da AWS for use AWS CDK no blog de operações e migrações de nuvem CloudFormation StackSets da AWS.

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. Você pode 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 bootstrap 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)

Atualizar a pilha de bootstrap

Periodicamente, a equipe do CDK atualizará o modelo de bootstrap 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, você pode atualizar sua pilha de bootstrap 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 do modelo de bootstrap.

Recursos padrão criados durante o bootstrapping

Perfis do IAM criados durante o bootstrapping

Por padrão, a inicialização provisiona as seguintes funções AWS Identity and Access Management (IAM) em seu ambiente:

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

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 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 fazer bootstrapping em um ambiente.

Personalizar o bootstrapping

Se o modelo de bootstrap padrão não atender às suas necessidades, você pode personalizar a o bootstrapping de recursos em seu ambiente das seguintes maneiras:

Para obter mais informações sobre como personalizar o bootstrapping, consulte Personalize o AWS CDK bootstrapping.

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 bootstrap 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 bootstrap do ambiente. Em vez disso, tente atualizar a pilha de bootstrap para uma nova versão executando o comando cdk bootstrap novamente.

Para se proteger contra a exclusão acidental de sua pilha de bootstrap, recomendamos que você forneça a opção --termination-protection com o comando cdk bootstrap para ativar a proteção contra encerramento. Você pode ativar a proteção contra encerramento em pilhas de bootstrap 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.

Histórico de versões do modelo de 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 atributos do CDK.

Esta seção contém uma lista das alterações feitas em cada versão.

Atualizar do modelo de bootstrap legado para o moderno

A 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.

* Adicionaremos recursos extras ao modelo de bootstrap 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 AWS CDK aplicativos no ambiente pelo menos uma vez antes de excluir o bucket legado.

Abordar 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] As entidades principais do IAM não devem ter políticas incorporadas 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 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 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 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 cláusula Condition 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 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.

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