Componentes de Enterprise Blueprint Factory - AWS Guía prescriptiva

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.

Componentes de Enterprise Blueprint Factory

Enterprise Blueprint Factory consta de los siguientes componentes:

Por lo general, el equipo de infraestructura de nube administra toda la fábrica de planes empresariales, ya que debe aprobar cada plan. Sin embargo, el equipo DevOps de código suele ser responsable del proceso de configuración y del proceso de publicación. Para publicar nuevos planos, los desarrolladores interactúan únicamente con el repositorio de productos, el repositorio de configuración y el archivo de configuración.

Repositorio de productos

El repositorio de productos es una ubicación centralizada en la que se almacenan los planos que aprueba la organización.  Un equipo de administración y un equipo de seguridad del plan revisan las solicitudes de incorporación a este repositorio para asegurarse de que cada plan cumpla con los requisitos organizativos y de seguridad. En esta guía, lo utilizamos GitHub para el repositorio, pero podrías usar una alternativa.

Repositorio de configuración

El repositorio de configuración (repositorio de configuración) es la ubicación en la que su organización almacena el archivo de configuración de las carteras y productos de Service Catalog que se publican a través de Enterprise Blueprint Factory. En esta guía, lo utilizamos GitHub para el repositorio, pero puede utilizar una alternativa.

Archivo de configuración

El archivo de configuración de Enterprise Blueprint Factory (archivo de configuración) se almacena en el repositorio de configuración, que es propiedad del equipo administrativo del blueprint. El nombre de este archivo es bp_config.yml. Cuando un desarrollador actualiza este archivo, el equipo administrativo del blueprint revisa los cambios. Al combinar los cambios en la rama principal, se inicia el proceso de configuración. El archivo de configuración organiza la publicación, el uso compartido y la distribución de todos los blueprints que se administran a través de Enterprise Blueprint Factory.

El archivo de configuración es un archivo YAML que consta de dos objetos principales: y. portfolios products El siguiente es un ejemplo de un archivo de configuración de ejemplo:

portfolios: - portfolio_name: blueprint-portfolio owner: Blueprint-team provider_name: AWS description: "Blueprint portfolio" portfolio_access_role: - arn:aws:iam::123456789012:role/examplerole - arn:aws:iam::123456789012:user/exampleuser share_to_ou: - org_id: "o-exampleOrgID" stack_tags: DataClassification: Confidential Organization: AWS products: - name: BP-S3-Product description: "Blueprint for BP-S3 product" product_config_file: 'BP-S3/product_config.json' owner: Blueprint-team stack_tags: DataClassification: Confidential Organization: AWS portfolio_associations: - blueprint-portfolio launch_constraint_role: arn:aws:iam::123456789012:role/examplelaunchrole

En el portfolios objeto, se definen las carteras de Service Catalog de destino. Para cada cartera, debe proporcionar los siguientes atributos:

  • portfolio_namees el nombre de la cartera. Este atributo es obligatorio.

  • owneres el nombre del equipo propietario de la cartera. Este atributo es opcional.

  • provider_namees el nombre del equipo o la organización que administra la cartera. El valor predeterminado es AWS. Este atributo es obligatorio.

  • descriptiones una breve descripción de la cartera. Este atributo es opcional.

  • portfolio_access_rolesson las identidades AWS Identity and Access Management (de IAM) (usuarios, funciones o grupos) que pueden acceder a la cartera y a sus productos asociados. Este atributo es opcional.

  • share_to_oues la unidad organizativa (OU) con la AWS Organizations que se comparte la cartera. Los usuarios finales pueden implementar los productos de esta cartera en los Cuentas de AWS que formen parte de la OU de destino. Este atributo es opcional.

  • stack_tagsson las etiquetas aplicadas a la cartera. Este atributo es opcional.

En el products objeto, defina cada blueprint que desee publicar como producto en Service Catalog. Para cada producto, debe proporcionar los siguientes atributos:

  • namees el nombre del producto en Service Catalog. Este atributo es obligatorio.

  • descriptiones una breve descripción del producto. Este atributo es obligatorio.

  • product_config_filees el nombre del archivo de configuración del producto modelo que se almacena en el repositorio de productos. Este atributo es obligatorio.

  • owneres el nombre del equipo propietario del producto. Este atributo es obligatorio.

  • stack_tagsson las etiquetas aplicadas al producto. Este atributo es opcional.

  • portfolio_associationsson las carteras objetivo que contienen el producto. Este atributo es opcional.

    nota

    Le recomendamos que añada productos únicamente a las carteras que se gestionen a través de Enterprise Blueprint Factory. Si desea añadir productos a carteras que no se gestionan a través de Enterprise Blueprint Factory, la política de IAM del usuario debe permitir esta acción. AssociateProductWithPortfolio Sin embargo, como práctica recomendada de seguridad, le recomendamos que permita esta acción solo para el proceso de configuración de Enterprise Blueprint Factory.

  • launch_constraint_rolees la función de lanzamiento que asume Service Catalog cuando un usuario final lanza el producto. Este atributo es obligatorio.

Canalización de configuración

El proceso de configuración (proceso de configuración) automatiza la configuración de la cartera de Service Catalog y de las acciones de cartera. También crea el proceso de lanzamiento de cada producto. Esta canalización es un AWS CodePipelinerecurso. Una actualización del archivo de configuración invoca la canalización de configuración.

La primera vez que invocas la canalización de configuración, se crean dos carteras adicionales que no están definidas en el archivo de configuración:

  • Blueprint-portfolio— Todos los productos que despliegues a través de Enterprise Blueprint Factory se añaden a esta cartera. Esta cartera está disponible para las unidades organizativas y principales de IAM que especifiques en el archivo de configuración.

  • Bootstrapping-Admin-Portfolio— El Bootstrapping-Admin-Product producto está asociado a esta cartera. Este producto es una CloudFormation plantilla para el proceso de lanzamiento. Permita que solo el equipo administrativo del plan acceda a esta cartera para que pueda gestionar los productos administrativos.

Etapas del proceso de configuración

La siguiente imagen muestra las etapas de la canalización de configuración y los recursos con los que interactúa la canalización. Cada etapa del proceso es un AWS CodeBuildproyecto.

Las etapas del proceso de configuración de Enterprise Blueprint Factory.

Las siguientes son las etapas del proceso de configuración:

  1. Implementar carteras: la canalización de configuración implementa todas las carteras que se hayan agregado al archivo de configuración o elimina las carteras que se han eliminado del archivo de configuración. Si no hay cambios en las carteras, la canalización omite esta etapa.

  2. Compartir carteras: el proceso de configuración comparte las carteras con las unidades organizativas objetivo (). OUs Si no hay cambios en las acciones de la cartera, la canalización se salta esta etapa.

  3. Implementar Blueprint-Admin-Bootstrapping-Product: la canalización de configuración obtiene el bp-pipeline blueprint del ServiceCatalog-CodeRepo repositorio y lo implementa en Service Catalog como. Bootstrapping-Admin-Product Este producto es la CloudFormation plantilla que se utiliza para crear una canalización de lanzamientos. La implementación de esta plantilla como un producto de Service Catalog ayuda a mantener el control de versiones. Si no hay cambios en el bp-pipeline esquema, la canalización omite esta etapa.

  4. Crear canalizaciones de lanzamiento: en función de los atributos del producto del archivo de configuración, la canalización de configuración prepara los parámetros de la pila y lanza una CloudFormation pila que crea una canalización de publicación para el producto. Para obtener más información, consulta la canalización de lanzamientos en esta guía.

  5. Implementación de productos: el proceso de lanzamiento implementa el plan como un producto de Service Catalog y lo asocia a la cartera de destino. Los usuarios finales ahora pueden implementar el producto en Cuentas de AWS las unidades organizativas de destino.

Proceso de lanzamiento

El proceso de publicación automatiza la publicación de los blueprints como productos de Service Catalog. Esta canalización es un AWS CodePipelinerecurso. Cuando su organización quiere publicar un nuevo plan, un desarrollador carga la plantilla de iAC y el archivo de configuración del producto en el repositorio de productos. Al añadir los detalles del producto al archivo de configuración, se activa el proceso de configuración. La canalización de configuración crea una canalización de publicación para este blueprint. Cualquier actualización posterior del blueprint activa esta canalización de versiones para actualizar el producto en Service Catalog con una nueva versión.

El proceso de lanzamiento incluye controles proactivos que automatizan las comprobaciones de seguridad y conformidad de sus planes. Los controles proactivos están diseñados para evitar la creación de recursos que no cumplan con las normas. Estos controles pueden reducir la cantidad de eventos de seguridad gestionados por otros tipos de controles de seguridad, como los controles de respuesta y de detección. Dado que los controles proactivos garantizan que los recursos desplegados cumplan con las normas antes de su despliegue, no hay ningún evento de detección que requiera una respuesta o una corrección.

La primera vez que se invoca la canalización de configuración, se crea un producto de Service Catalog que recibe el nombreBootstrapping-Admin-Product. Este producto es la CloudFormation plantilla para la canalización de lanzamientos. Como se muestra en la siguiente figura, la canalización de configuración utiliza el Bootstrapping-Admin-Product producto para crear una canalización de versiones dedicada a cada nuevo blueprint. Existe una one-to-one relación entre los planos y las canalizaciones de lanzamiento.

La canalización de configuración usa un producto para crear una canalización de lanzamiento para cada blueprint.

Etapas del proceso de lanzamiento

La siguiente imagen muestra las etapas predeterminadas de la canalización de lanzamiento y los recursos con los que interactúa la canalización. Cada etapa del proceso es un CodeBuild proyecto.

Las etapas del proceso de lanzamiento de Enterprise Blueprint Factory.

Las siguientes son las etapas del proceso de lanzamiento:

  1. Alineación de archivos: esta etapa verifica que el plano sea una CloudFormation plantilla o una AWS Cloud Development Kit (AWS CDK) construcción. Si el plano es una AWS CDK construcción, esta etapa sintetiza la AWS CDK construcción en una plantilla. CloudFormation Este proceso automatiza y estandariza todas las implementaciones. CloudFormation Si se encuentra algún error, la canalización falla.

  2. Comprobación de sintaxis: los errores de sintaxis son una causa común de errores de CloudFormation implementación. En esta etapa, AWS CloudFormation Linter (cfn-lint) comprueba los errores de sintaxis comparando la plantilla con la especificación del recurso.AWS CloudFormation También realiza otras comprobaciones, como comprobar los valores válidos de las propiedades de los recursos y el cumplimiento de las mejores prácticas. Si se encuentra algún error, la canalización falla y cfn-lint devuelve sugerencias.

  3. Comprobación de control: en esta etapa, cfn_nag busca patrones para detectar posibles problemas de seguridad. Por ejemplo, comprueba si hay grupos de seguridad y políticas AWS Identity and Access Management (IAM) excesivamente permisivos, si faltan datos de cifrado y si las contraseñas contienen literales. Si se encuentra algún error, la canalización falla y cfn_nag devuelve sugerencias.

  4. Comprobación de versiones: el proceso de publicación realiza el control de versiones en función de la estrategia de versiones definida en el archivo de configuración del producto. Si la versión del producto se define como inmutable, Service Catalog desactiva la versión anterior del producto.

  5. Publicar producto: el proceso de lanzamiento lanza el producto en Service Catalog.

nota

El proceso de lanzamiento es personalizable. Por ejemplo, puedes eliminar cualquier fase que no sea aplicable a tu caso de uso. También puede añadir más etapas si desea añadir otras comprobaciones de control, validaciones adicionales o un paso de aprobación manual. Esta guía no incluye instrucciones para modificar el proceso de publicación. Para obtener más información, consulte la CodeBuilddocumentación CodePipeliney.