Inicie su entorno para usarlo con AWS CDK - AWS Cloud Development Kit (AWS CDK) v2

Esta es la guía para AWS CDK desarrolladores de la versión 2. La CDK versión anterior entró en mantenimiento el 1 de junio de 2022 y finalizó el soporte el 1 de junio de 2023.

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Inicie su entorno para usarlo con AWS CDK

Inicie su AWS entorno para prepararlo para AWS Cloud Development Kit (AWS CDK) las implementaciones de pilas.

Cómo arrancar su entorno

Puede utilizar la interfaz de línea de AWS CDK comandos (AWS CDK CLI) o su herramienta de AWS CloudFormation implementación preferida para arrancar su entorno.

Utilizar CDK CLI

Puede utilizar la CDK CLI cdk bootstrapcomando para arrancar su entorno. Este es el método que recomendamos si no necesita realizar modificaciones importantes en el arranque.

Arranque desde cualquier directorio de trabajo

Para arrancar desde cualquier directorio de trabajo, proporcione el entorno de arranque como un argumento de la línea de comandos. A continuación, se muestra un ejemplo:

$ cdk bootstrap aws://123456789012/us-east-1
sugerencia

Si no tiene su número de AWS cuenta, puede obtenerlo en. AWS Management Console También puedes usar el siguiente AWS CLI comando para mostrar la información de tu cuenta predeterminada, incluido tu número de cuenta:

$ aws sts get-caller-identity

Si ha nombrado perfiles en sus credentials archivos AWS config y, utilice la --profile opción para recuperar la información de la cuenta de un perfil específico. A continuación, se muestra un ejemplo:

$ aws sts get-caller-identity --profile prod

Para mostrar la región predeterminada, utilice el comando aws configure get:

$ aws configure get region $ aws configure get region --profile prod

Al proporcionar un argumento, el prefijo aws:// es opcional. Lo siguiente es válido:

$ cdk bootstrap 123456789012/us-east-1

Para arrancar varios entornos al mismo tiempo, proporcione varios argumentos:

$ cdk bootstrap aws://123456789012/us-east-1 aws://123456789012/us-east-2
Inicie el programa desde el directorio principal de un proyecto CDK

Puede ejecutarlo cdk bootstrap desde el directorio principal de un CDK proyecto que contenga un cdk.json archivo. Si no proporciona un entorno como argumento, el CDK CLI obtendrá la información del entorno de las fuentes predeterminadas, como sus credentials archivos config AND o cualquier información del entorno especificada para su CDK pila.

Al arrancar desde el directorio principal de un CDK proyecto, los entornos proporcionados a partir de los argumentos de la línea de comandos tienen prioridad sobre otras fuentes.

Para arrancar un entorno especificado en sus archivos config y credentials, utilice la opción --profile:

$ cdk bootstrap --profile prod

Para obtener más información sobre el comando cdk bootstrap y las opciones de admitidas, consulte cdk bootstrap.

Usa cualquier herramienta AWS CloudFormation

Puede copiar la plantilla de arranque del aws-cdk GitHub reposicione u obtenga la plantilla con el comando. cdk bootstrap --show-template A continuación, utilice cualquier AWS CloudFormation herramienta para implementar la plantilla en su entorno.

Con este método, puede usar AWS CloudFormation StackSets o AWS Control Tower. También puede utilizar la AWS CloudFormation consola o el AWS Command Line Interface (AWS CLI). Puede realizar modificaciones en la plantilla antes de implementarla. Este método puede ser más flexible y adecuado para implementaciones a gran escala.

El siguiente es un ejemplo del uso de la opción --show-template para recuperar y guardar la plantilla de arranque en su máquina local:

macOS/Linux
$ cdk bootstrap --show-template > bootstrap-template.yaml
Windows

En Windows, PowerShell debe usarse para conservar la codificación de la plantilla.

powershell "cdk bootstrap --show-template | Out-File -encoding utf8 bootstrap-template.yaml"

Para implementar esta plantilla mediante el CDK CLI, puede ejecutar lo siguiente:

$ cdk bootstrap --template bootstrap-template.yaml

A continuación, se muestra un ejemplo del uso de AWS CLI para implementar la plantilla:

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

Para obtener información sobre cómo iniciar varios entornos, consulte Cómo iniciar varios entornos Cuentas de AWS para AWS CDK utilizarlos en el blog sobre operaciones y CloudFormation StackSets migraciones en la AWS nube. CloudFormation StackSets

Cuando arrancar su entorno

Debe iniciar cada AWS entorno antes de implementarlo en el entorno. Recomendamos arrancar de forma proactiva cada entorno de que desee usar. Puede hacerlo antes de planificar la implementación efectiva de CDK las aplicaciones en el entorno. Al arrancar sus entornos de forma proactiva, evita posibles problemas futuros, como conflictos con los nombres de los buckets de Amazon S3 o la implementación de CDK aplicaciones en entornos que no se han iniciado.

Está bien arrancar un entorno más de una vez. Si un entorno ya se inició, la pila de arranque se actualizará si es necesario. De lo contrario, no pasará nada.

Si intenta implementar una CDK pila en un entorno que no se ha iniciado, aparecerá un error como el siguiente:

$ 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)

Actualización de la pila de arranque

Periódicamente, el CDK equipo actualizará la plantilla de arranque a una nueva versión. Cuando esto sucede, le recomendamos que actualice la pila de arranque. Si no personalizó el proceso de arranque, puede actualizar su pila de arranque con los mismos pasos que siguió para arrancar su entorno originalmente. Para obtener más información, consulte Historial de versiones de la plantilla de arranque.

Recursos predeterminados creados durante el arranque

IAMroles creados durante el arranque

De forma predeterminada, el arranque proporciona las siguientes AWS Identity and Access Management () IAM funciones en su entorno:

  • CloudFormationExecutionRole

  • DeploymentActionRole

  • FilePublishingRole

  • ImagePublishingRole

  • LookupRole

CloudFormationExecutionRole

Esta IAM función es una función de CloudFormation servicio que otorga CloudFormation permiso para realizar despliegues de pilas en su nombre. Esta función te da CloudFormation permiso para realizar AWS API llamadas en tu cuenta, incluida la implementación de pilas.

Al usar un rol de servicio, los permisos proporcionados para el rol de servicio determinan qué acciones se pueden realizar en tus CloudFormation recursos. Sin este rol de servicio, las credenciales de seguridad que proporciones con el CDK CLI determinaría lo que CloudFormation se puede hacer.

DeploymentActionRole

Esta IAM función otorga permiso para realizar despliegues en su entorno. Lo asume el CDK CLI durante los despliegues.

Al usar un rol para las implementaciones, puede realizar implementaciones entre cuentas, ya que el rol se puede asumir por identidades de AWS en una cuenta distinta.

FilePublishingRole

Esta IAM función otorga permiso para realizar acciones contra el depósito de Amazon Simple Storage Service (Amazon S3) iniciado, incluidas la carga y la eliminación de activos. Lo asume el CDK CLI durante los despliegues.

ImagePublishingRole

Esta IAM función otorga permiso para realizar acciones en el repositorio de Amazon Elastic Container Registry ECR (Amazon) iniciado. Lo asume el CDK CLI durante los despliegues.

LookupRole

Esta IAM función otorga readOnly permiso para buscar valores de contexto en el AWS entorno. Lo asume el CDK CLI al realizar tareas como la síntesis de plantillas y los despliegues.

Recurso IDs creado durante el arranque

Al implementar la plantilla de arranque predeterminada, los recursos físicos IDs para el arranque se crean utilizando la siguiente estructura:. cdk-qualifier-description-account-ID-Region

  • Calificador: un valor de cadena único de nueve caracteres de hnb659fds. El valor real no tiene importancia.

  • Descripción: una descripción corta del recurso. Por ejemplo, container-assets.

  • ID de cuenta: el Cuenta de AWS ID del entorno.

  • Región: la Región de AWS del entorno.

El siguiente es un ejemplo de ID físico del bucket transitorio de Amazon S3 creado durante el arranque: cdk-hnb659fds-assets-012345678910-us-west-1.

Permisos que se deben utilizar al arrancar el entorno

Al iniciar un AWS entorno, la IAM identidad que realiza el arranque debe tener al menos los siguientes permisos:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*", "ecr:*", "ssm:*", "s3:*", "iam:*" ], "Resource": "*" } ] }

Con el tiempo, la pila de arranque, incluidos los recursos que se crean y los permisos que requieren, puede cambiar. Con cambios futuros, es posible que tenga que modificar los permisos necesarios para arrancar un entorno.

Personalice el arranque

Si la plantilla de arranque predeterminada no se ajusta a sus necesidades, puede personalizar el arranque de recursos a su entorno de las siguientes maneras:

  • Utilizar las opciones de línea de comandos con el comando cdk bootstrap: este método es el mejor para realizar cambios pequeños y específicos que se admiten mediante las opciones de la línea de comandos.

  • Modificar la plantilla de arranque predeterminada e implementarla: este método es el mejor para realizar cambios complejos o si desea tener un control total sobre la configuración de los recursos aprovisionados durante el arranque.

Para obtener más información sobre la personalización del proceso de arranque, consulte Personalización del arranque del AWS CDK.

CDKArrancar con canalizaciones

Si utilizas CDK Pipelines para realizar la implementación en el entorno de otra cuenta y recibes un mensaje como el siguiente:

Policy contains a statement with one or more invalid principals

Este mensaje de error significa que las IAM funciones adecuadas no existen en el otro entorno. La causa más probable es que el entorno no arrancó. Arranque el entorno e inténtelo de nuevo.

Proteja su pila de arranque para que no se elimine

Si se elimina una pila de arranque, también se eliminarán los AWS recursos que se aprovisionaron originalmente en el entorno para respaldar CDK las implementaciones. Esto hará que la canalización deje de funcionar. Si esto sucede, no existe una solución general para la recuperación.

Una vez que se arranque el entorno, no elimine ni vuelva a crear la pila de arranque del entorno. En su lugar, intente actualizar la pila de arranque a una nueva versión ejecutando el comando cdk bootstrap de nuevo.

Para evitar que se elimine accidentalmente la pila de arranque, le recomendamos que proporcione la opción --termination-protection junto con el comando cdk bootstrap para habilitar la protección contra la terminación. Puede habilitar la protección contra la terminación en pilas de arranque nuevas o existentes. Para obtener instrucciones sobre cómo habilitar la protección de terminación, consulte Enable termination protection for the bootstrap stack.

Historial de versiones de la plantilla de arranque

La plantilla de bootstrap está versionada y evoluciona a lo largo del tiempo con ella misma. AWS CDK Si proporciona su propia plantilla de arranque, manténgala actualizada mediante la plantilla canónica predeterminada. Quieres asegurarte de que tu plantilla sigue funcionando con todas las funciones. CDK

nota

Las versiones anteriores de la plantilla de arranque creaban un entorno AWS KMS key en cada entorno de arranque de forma predeterminada. Para evitar que se le cobre por la KMS clave, reinicie estos entornos utilizando. --no-bootstrap-customer-key El valor predeterminado actual es sin KMS clave, lo que ayuda a evitar estos cargos.

Esta sección contiene una lista de los cambios realizados en cada versión.

Versión de plantilla AWS CDK versión Cambios
1 1.40.0 Versión inicial de la plantilla con el bucket, la clave, el repositorio y los roles.
2 1.45.0 Se dividió el rol del publicador de activos en roles independientes del publicador de archivos e imágenes.
3 1.46.0 Se agregó la opción de exportación de FileAssetKeyArn para poder agregar permisos de descifrado a los consumidores de activos.
4 1.61.0 AWS KMS los permisos ahora están implícitos a través de Amazon S3 y ya no son necesariosFileAsetKeyArn. Agregue un CdkBootstrapVersion SSM parámetro para que la versión de la pila de arranque se pueda verificar sin conocer el nombre de la pila.
5 1.87.0 El rol de despliegue puede leer SSM el parámetro.
6 1.108.0 Se agregó un rol de búsqueda independiente del rol de implementación.
6 1.109,0 Se adjuntó una etiqueta aws-cdk:bootstrap-role a los roles de implementación, publicación de archivos y publicación de imágenes.
7 1.110,0 El rol de implementación ya no puede leer directamente los buckets de la cuenta de destino. (Sin embargo, este rol es, en efecto, el de administrador y, de todos modos, siempre puede usar sus AWS CloudFormation permisos para hacer que el bucket sea legible).
8 1.114.0 El rol de búsqueda tiene permisos completos de solo lectura para el entorno de destino y también tiene una etiqueta de aws-cdk:bootstrap-role.
9 2.1.0 Corrige el rechazo de las cargas de activos de Amazon S3 mediante el cifrado SCP de referencia común.
10 2.4.0 Amazon ahora ECR ScanOnPush está activado de forma predeterminada.
11 2.18.0 Añade una política que permite a Lambda extraer datos de los ECR repositorios de Amazon para que sobreviva al reinicio.
12 2.20.0 Agrega soporte para experimentos de cdk import.
13 2.25.0 Hace que las imágenes de los contenedores de los repositorios de Amazon ECR creados por bootstrap sean inmutables.
14 2.34.0 Desactiva el escaneo de ECR imágenes de Amazon en el nivel de repositorio de forma predeterminada para permitir el arranque de regiones que no admiten el escaneo de imágenes.
15. 2.60,0 KMSlas claves no se pueden etiquetar.
16 2.69,0 Aborda el hallazgo KMS4.2 de Security Hub.
17 2.72.0 Aborda el hallazgo ECR.3 de Security Hub.
18 2.80,0 Se revirtieron los cambios realizados en la versión 16, ya que no funcionan en todas las particiones y no se recomiendan.
19 2.106.1 Se han revertido los cambios realizados en la versión 18, en los que se eliminaba la AccessControl propiedad de la plantilla. (#27964)
20 2.119.0 Añada ssm:GetParameters una acción a la función de AWS CloudFormation despliegueIAM. Para obtener más información, consulte #28336.
21 2.149.0 Se agregó una condición al rol de publicación de archivos.
22 2.160,0 Añada sts:TagSession permisos a la política de confianza de los roles de bootstrapIAM.
23 2.161,0 Agregue cloudformation:ContinueUpdateRollback permisos cloudformation:RollbackStack a la política de confianza de la función de despliegueIAM. Esto proporciona permisos para el comando cdk rollback.
24 2.165.0 Cambie el tiempo de conservación de los objetos no actuales del depósito de arranque, de 365 a 30 días. Dado que el nuevo cdk gc comando introduce la posibilidad de eliminar objetos del depósito de arranque, este nuevo comportamiento garantiza que los objetos eliminados permanezcan en el depósito de arranque durante 30 días en lugar de 365 días. Para obtener más información sobre este cambio, consulte aws-cdk PR #31949.
25 2.165,0 Añade soporte al depósito de bootstrap para eliminar las cargas multiparte incompletas. Las cargas multiparte incompletas se eliminarán después de 1 día. Para obtener más información sobre este cambio, consulta aws-cdk PR #31956.

Actualización de una plantilla de arranque de heredada a una moderna

La AWS CDK versión 1 admitía dos plantillas de arranque, la antigua y la moderna. CDKLa versión 2 solo admite la plantilla moderna. Como referencia, estas son las diferencias de alto nivel entre estas dos plantillas.

Característica Heredada (solo en la v1) Moderna (v1 y v2)
Implementaciones entre cuentas No permitido Permitido
AWS CloudFormation Permisos Se implementa con los permisos del usuario actual (determinados por el AWS perfil, las variables de entorno, etc.) Se implementa con los permisos especificados cuando se aprovisionó la pila de arranque (por ejemplo, mediante el uso de --trust)
Control de versiones Solo hay disponible una versión de la pila de arranque La pila de Bootstrap está versionada; se pueden agregar nuevos recursos en futuras versiones y las AWS CDK aplicaciones pueden requerir una versión mínima
Recursos* Bucket de Amazon S3 Bucket de Amazon S3
AWS KMS key
Roles de IAM
ECRRepositorio de Amazon
SSMparámetro para el control de versiones
Nombramiento de los recursos Se generan de forma automática Determinista
Cifrado de buckets Clave predeterminada AWS clave gestionada de forma predeterminada. Se puede personalizar para utilizar una clave administrada por el cliente.

Agregaremos recursos adicionales a la plantilla de arranque según sea necesario.

Un entorno que se inició con la plantilla anterior debe actualizarse para utilizar la plantilla moderna de la versión CDK 2 mediante el reinicio. Vuelva a implementar todas las AWS CDK aplicaciones en el entorno al menos una vez antes de eliminar el bucket heredado.

Abordar los resultados de Security Hub

Si lo está utilizando AWS Security Hub, es posible que vea información sobre algunos de los recursos creados por el proceso de AWS CDK arranque. Los resultados de Security Hub le ayudan a encontrar configuraciones de recursos que debe comprobar para garantizar su precisión y seguridad. Hemos revisado estas configuraciones de recursos específicas con AWS Security y estamos seguros de que no constituyen un problema de seguridad.

[KMS.2] IAM los directores no deberían tener políticas IAM integradas que permitan realizar acciones de descifrado en todas las claves KMS

La función de despliegue (DeploymentActionRole) otorga permiso para leer datos cifrados, lo cual es necesario para las implementaciones entre cuentas con Pipelines. CDK Las políticas de este rol no otorgan permisos a todos los datos. Solo concede permiso para leer datos cifrados de Amazon S3 y AWS KMS solo cuando esos recursos lo permiten a través de su política de bucket o clave.

A continuación, se incluye un fragmento de estas dos instrucciones sobre el rol de implementación de la plantilla de arranque:

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 qué Security Hub marca esto?

Las políticas contienen un Resource: * combinado con una cláusula Condition. Security Hub marca el comodín *. Este comodín se utiliza porque, en el momento en que se inicia la cuenta, la AWS KMS clave creada por CDK Pipelines para el depósito de CodePipeline artefactos aún no existe y, por lo tanto, no se puede hacer referencia a ella en la plantilla de arranque. ARN Además, Security Hub no tiene en cuenta la cláusula Condition al hacer esta marca. Esto se Condition limita Resource: * a las solicitudes realizadas a partir de la misma clave. Cuenta de AWS AWS KMS Estas solicitudes deben provenir de Amazon S3 junto con Región de AWS la AWS KMS clave.

¿Tengo que corregir este resultado?

Siempre y cuando no haya modificado la AWS KMS clave de la plantilla de arranque para que sea demasiado permisiva, la función de implementación no permitirá más acceso del que necesita. Por lo tanto, no es necesario corregir este resultado.

¿Qué sucede si quiero corregir este resultado?

La forma de solucionar este problema dependerá de si vas a utilizar o no CDK Pipelines para las implementaciones entre cuentas.

Para corregir el Security Hub: buscar y usar CDK Pipelines para despliegues entre cuentas
  1. Si aún no lo ha hecho, implemente la pila de CDK bootstrap mediante el comando. cdk bootstrap

  2. Si aún no lo ha hecho, cree e implemente su CDK PipelinePara ver instrucciones, consulte Integración y entrega continuas (CI/CD) con CDK Pipelines.

  3. Obtén la AWS KMS clave ARN del depósito de CodePipeline artefactos. Este recurso se crea durante la creación de la canalización.

  4. Obtenga una copia de la plantilla de CDK arranque para modificarla. A continuación se muestra un ejemplo en el que se utiliza la AWS CDK CLI:

    $ cdk bootstrap --show-template > bootstrap-template.yaml
  5. Modifique la plantilla sustituyendo Resource: * la PipelineCrossAccountArtifactsKey declaración por su ARN valor.

  6. Implemente la plantilla para actualizar su pila de arranque. A continuación se muestra un ejemplo en el que se utiliza el CDK CLI:

    $ cdk bootstrap aws://account-id/region --template bootstrap-template.yaml
Para solucionar el problema de Security Hub si no utilizas CDK Pipelines para despliegues entre cuentas
  1. Obtenga una copia de la plantilla de CDK bootstrap para modificarla. A continuación se muestra un ejemplo en el que se utiliza la CDK CLI:

    $ cdk bootstrap --show-template > bootstrap-template.yaml
  2. Elimine las instrucciones PipelineCrossAccountArtifactsBucket y PipelineCrossAccountArtifactsKey de la plantilla.

  3. Implemente la plantilla para actualizar su pila de arranque. A continuación se muestra un ejemplo en el que se utiliza el CDK CLI:

    $ cdk bootstrap aws://account-id/region --template bootstrap-template.yaml

Consideraciones

Dado que el arranque aprovisiona los recursos de su entorno, puede incurrir en AWS cargos si esos recursos se utilizan con el. AWS CDK