El plano de la aplicación empresarial se implementa mediante una serie de sistemas y procesos automatizados. Cada flujo de procesamiento implementa un aspecto concreto del plano. Los flujos de procesamiento proporcionan un mecanismo controlable, auditable y repetible para crear el plan. En el siguiente diagrama se muestra la interacción de los distintos pipelines, repositorios y perfiles.
El plan usa las siguientes canalizaciones:
- El flujo de procesamiento de la infraestructura básica (que forma parte del plan de aspectos básicos de seguridad para empresas) implementa la fábrica de aplicaciones, el flujo de procesamiento de la infraestructura multiinquilino y el flujo de procesamiento de ámbito de flota.
- La pipeline de infraestructura multicliente implementa los clústeres de GKE y los demás servicios gestionados en los que se basa el plano técnico de la aplicación empresarial.
- La configuración de canalización de ámbito de flota configura los ámbitos de flota, los espacios de nombres y los roles y enlaces de RBAC.
- La fábrica de aplicaciones proporciona un mecanismo para implementar nuevas canalizaciones de aplicaciones mediante un proceso basado en plantillas.
- El flujo de procesamiento de CI/CD de la aplicación proporciona un flujo de procesamiento de CI/CD para desplegar servicios en clústeres de GKE.
- Config Sync implementa y mantiene configuraciones adicionales de Kubernetes, incluidas las restricciones de Policy Controller.
Repositorios, colaboradores de repositorios y responsables de aprobación de cambios de repositorios
Las canalizaciones de planos se activan mediante cambios en los repositorios de Git. En la siguiente tabla se describen los repositorios que se usan en todo el plano, quién contribuye al repositorio, quién aprueba los cambios en el repositorio, qué canalización usa el repositorio y la descripción del contenido del repositorio.
| Repositorio | Colaborador del repositorio | Aprobador de cambios de repositorio | Flujo de procesamiento | Descripción |
|---|---|---|---|---|
|
Desarrollador de plataformas para desarrolladores |
Administrador de la plataforma para desarrolladores |
Canalización de infraestructura de Foundation |
Repositorio que contiene el código para implementar el flujo de procesamiento de infraestructura multiempresa, la aplicación y el flujo de procesamiento de ámbito de flota |
|
Desarrollador de plataformas para desarrolladores |
Administrador de la plataforma para desarrolladores |
Infraestructura multicliente |
Los módulos de Terraform que usan los equipos de la plataforma para desarrolladores cuando crean la infraestructura |
|
Desarrollador de plataformas para desarrolladores |
Administrador de la plataforma para desarrolladores |
Ámbito de flota |
El repositorio que define los ámbitos y los espacios de nombres del equipo de la flota en la flota |
|
Desarrollador de plataformas para desarrolladores |
Administrador de la plataforma para desarrolladores |
Fábrica de aplicaciones |
El código que define el repositorio de la aplicación y hace referencia a los módulos del repositorio |
|
Desarrollador de aplicaciones |
Operador de la aplicación |
Fábrica de aplicaciones |
El código base que se coloca en el repositorio |
|
Desarrollador de plataformas para desarrolladores |
Administrador de la plataforma para desarrolladores |
Fábrica de aplicaciones Infraestructura multicliente |
Los módulos de Terraform que definen la aplicación y la infraestructura |
|
Desarrollador de aplicaciones |
Operador de la aplicación |
CI/CD de aplicaciones |
El código de la aplicación que se despliega en los clústeres de GKE |
|
Desarrollador de plataformas para desarrolladores |
Administrador de la plataforma para desarrolladores |
Config Sync |
Las políticas que usan los clústeres de GKE para mantener sus configuraciones |
Las pipelines automatizadas ayudan a integrar la seguridad, la auditabilidad, la trazabilidad, la repetibilidad, la controlabilidad y el cumplimiento en el proceso de implementación. Al usar sistemas diferentes con permisos distintos y asignar a diferentes personas a distintos grupos operativos, se separan las responsabilidades y se sigue el principio del privilegio mínimo.
Canalización de infraestructura de Foundation
La infraestructura básica se describe en el blueprint de aspectos básicos de seguridad para empresas y se usa como punto de entrada genérico para otras implementaciones de recursos. En la siguiente tabla se describen los componentes que crea la canalización.
| Componente | Descripción |
|---|---|
Crea la infraestructura compartida que utilizan todos los arrendatarios de la plataforma para desarrolladores. |
|
Crea espacios de nombres y vinculaciones de roles de control de acceso basado en roles (RBAC). |
|
Crea los flujos de procesamiento de CI/CD de la aplicación que se usan para desplegar los servicios. |
Pipeline de infraestructura multicliente
La infraestructura de la infraestructura multicliente implementa flotas, clústeres de GKE y recursos compartidos relacionados. En el siguiente diagrama se muestran los componentes de la canalización de infraestructura multiarrendatario.
En la siguiente tabla se describen los componentes que crea la canalización de infraestructura multiinquilino.
| Componente | Descripción |
|---|---|
Clústeres de GKE |
Proporciona alojamiento para los servicios de la aplicación contenedorizada. |
Policy Controller |
Proporciona políticas que ayudan a asegurar la configuración adecuada de los clústeres y servicios de GKE. |
Config Sync |
Aplica las políticas de Policy Controller a los clústeres y mantiene una aplicación coherente de las políticas. |
Crea la clave de cifrado basada en la clave de cifrado gestionada por el cliente (CMEK) para GKE, AlloyDB para PostgreSQL y Secret Manager. |
|
Secreto de Secret Manager |
Proporciona un almacén secreto para el par de claves RSA que se usa para la autenticación de usuarios con tokens web JSON (JWT). |
Política de seguridad de Cloud Armor |
Proporciona la política que usa el cortafuegos de aplicaciones web de Cloud Armor. |
Flujo de procesamiento de ámbito de flota
El flujo de procesamiento de ámbito de flota se encarga de configurar los espacios de nombres y los enlaces RBAC en los clústeres de GKE de la flota. En la siguiente tabla se describen los componentes que crea la canalización de ámbito de flota.
| Componente | Descripción |
|---|---|
Define los clústeres lógicos dentro del clúster físico. |
|
Define la autorización que tiene una cuenta de servicio de Kubernetes a nivel de clúster o de espacio de nombres. |
Fábrica de aplicaciones
La fábrica de aplicaciones se implementa mediante la canalización de infraestructura de la fundación y se usa para crear infraestructura para cada aplicación nueva. Esta infraestructura incluye un Google Cloud proyecto que contiene la canalización de CI/CD de la aplicación.
A medida que las organizaciones de ingeniería crecen, el equipo de aplicaciones puede incorporar nuevas aplicaciones mediante la fábrica de aplicaciones. El escalado permite el crecimiento añadiendo flujos de procesamiento de CI/CD de aplicaciones independientes y admitiendo la infraestructura para implementar nuevas aplicaciones en la arquitectura multicliente. En el siguiente diagrama se muestra la fábrica de aplicaciones.
La fábrica de aplicaciones tiene los siguientes componentes:
- Repositorio de fábrica de aplicaciones: repositorio de Git que almacena la definición declarativa de la aplicación.
- Pipelines para crear aplicaciones: pipelines que requieren que Cloud Build complete lo siguiente:
- Crea una definición de aplicación declarativa y almacénala en el catálogo de aplicaciones.
- Aplica la definición de aplicación declarativa para crear los recursos de la aplicación.
- Repositorio de plantillas de aplicaciones iniciales: plantillas para crear una aplicación sencilla (por ejemplo, un microservicio de Python, Go o Java).
- Módulos compartidos: módulos de Terraform que se crean con prácticas estándar y que se usan para varios fines, como la incorporación y la implementación de aplicaciones.
En la siguiente tabla se enumeran los componentes que crea la fábrica de aplicaciones para cada aplicación.
| Componente | Descripción |
|---|---|
Repositorio de código fuente de la aplicación |
Contiene el código fuente y la configuración relacionada que se usan para compilar e implementar una aplicación específica. |
Flujo de procesamiento de CI/CD de aplicaciones |
Un flujo de procesamiento basado en Cloud Build que se usa para conectarse al repositorio de código fuente y proporciona un flujo de procesamiento de CI/CD para desplegar servicios de aplicaciones. |
Flujo de procesamiento de CI/CD de aplicaciones
El flujo de procesamiento de CI/CD de la aplicación permite crear y desplegar automáticamente aplicaciones basadas en contenedores. El flujo de procesamiento consta de pasos de integración continua (CI) y despliegue continuo (CD). La arquitectura del flujo de procesamiento se basa en el blueprint de CI/CD seguro.
El flujo de procesamiento de CI/CD de la aplicación usa imágenes de contenedor inmutables en todos tus entornos. Las imágenes de contenedor inmutables ayudan a asegurar que la misma imagen se despliegue en todos los entornos y no se modifique mientras el contenedor está en ejecución. Si debes actualizar el código de la aplicación o aplicar un parche, compila una imagen nueva y vuelve a desplegarla. Para usar imágenes de contenedor inmutables, debes externalizar la configuración del contenedor para que la información de configuración se lea durante el tiempo de ejecución.
Para acceder a los clústeres de GKE a través de una ruta de red privada y gestionar la kubeconfigautenticación, la canalización de CI/CD de la aplicación interactúa con los clústeres de GKE a través de la pasarela Connect. La canalización también usa grupos privados
para el entorno de CI/CD.
Cada repositorio de código fuente de la aplicación incluye configuraciones de Kubernetes. Estas configuraciones permiten que las aplicaciones se ejecuten correctamente como servicios de Kubernetes en GKE. En la siguiente tabla se describen los tipos de configuraciones de Kubernetes que aplica la canalización de CI/CD de la aplicación.
| Componente | Descripción |
|---|---|
Define un conjunto de pods (contenedores) escalado. |
|
Hace que un despliegue sea accesible a través de la red del clúster. |
|
Hace que un servicio forme parte de la malla de servicios. |
|
Define cómo deben acceder los peers de la malla de servicios a un servicio virtual. Se usa en el blueprint para configurar el balanceo de carga local para el tráfico este-oeste. |
|
Define el control de acceso entre las cargas de trabajo de la malla de servicios. |
|
Define la identidad que utiliza un servicio de Kubernetes. Workload Identity Federation para GKE define la cuenta de servicio Google Cloud que se usa para acceder a los recursosGoogle Cloud . |
|
Permite que el tráfico de entrada externo llegue a un servicio. La pasarela solo es necesaria en las implementaciones que reciben tráfico externo. |
|
Configura SSL, Cloud Armor, la afinidad de sesión y la desviación de conexión para las implementaciones que reciben tráfico externo. GCPBackendPolicy solo se usa en las implementaciones que reciben tráfico externo. |
|
Configura la recogida de métricas de Prometheus exportadas por una aplicación. |
Integración continua
En el siguiente diagrama se muestra el proceso de integración continua.
El proceso es el siguiente:
- Un desarrollador confirma el código de la aplicación en el repositorio de origen de la aplicación. Esta operación activa Cloud Build para que inicie la canalización de integración.
- Cloud Build crea una imagen de contenedor, transfiere la imagen de contenedor a Artifact Registry y crea un resumen de imagen.
- Cloud Build realiza pruebas automatizadas de la aplicación. En función del idioma de la aplicación, se pueden llevar a cabo diferentes paquetes de pruebas.
- Cloud Build realiza los siguientes análisis en la imagen de contenedor:
- Cloud Build analiza el contenedor con el framework Container Structure Tests. Este framework realiza pruebas de comandos, pruebas de existencia de archivos, pruebas de contenido de archivos y pruebas de metadatos.
- Cloud Build usa el análisis de vulnerabilidades para identificar cualquier vulnerabilidad en la imagen de contenedor en comparación con una base de datos de vulnerabilidades que mantiene Google Cloud.
- Cloud Build aprueba la imagen para que continúe en la canalización después de obtener resultados de análisis correctos.
- Autorización binaria firma la imagen. Autorización binaria es un servicio de Google Cloud que proporciona seguridad en la cadena de suministro de software para aplicaciones basadas en contenedores mediante el uso de políticas, reglas, notas, atestaciones, atestadores y firmantes. En el momento del despliegue, el aplicador de la política de autorización binaria ayuda a asegurar la procedencia del contenedor antes de permitir que se despliegue.
- Cloud Build crea una versión en Cloud Deploy para iniciar el proceso de despliegue.
Para ver la información de seguridad de una compilación, ve al panel Estadísticas de seguridad. Estas estadísticas incluyen vulnerabilidades que se han detectado con Análisis de artefactos y el nivel de garantía de seguridad de la compilación, que se indica en las directrices de SLSA.
Despliegue continuo
En el siguiente diagrama se muestra el proceso de implementación continua.
El proceso es el siguiente:
- Al final del proceso de compilación, el flujo de procesamiento de CI/CD de la aplicación crea una nueva versión de Cloud Deploy para lanzar las imágenes de contenedor recién compiladas de forma progresiva en cada entorno.
- Cloud Deploy inicia un lanzamiento en el primer entorno de la canalización de despliegue, que suele ser el de desarrollo. Cada fase de la implementación se configura para que requiera aprobación manual.
- Las canalizaciones de Cloud Deploy usan el despliegue secuencial para desplegar imágenes en cada clúster de un entorno en orden.
- Al final de cada fase de implementación, Cloud Deploy verifica la funcionalidad de los contenedores implementados. Estos pasos se pueden configurar en la configuración de Skaffold de las aplicaciones.
Desplegar una aplicación nueva
En el siguiente diagrama se muestra cómo funcionan conjuntamente la fábrica de aplicaciones y la canalización de CI/CD de aplicaciones para crear e implementar una aplicación nueva.
El proceso para definir una nueva aplicación es el siguiente:
- Un operador de aplicaciones define una nueva aplicación en su arrendatario ejecutando un activador de Cloud Build para generar la definición de la aplicación.
- El activador añade una nueva entrada para la aplicación en Terraform y confirma el cambio en el repositorio de la fábrica de aplicaciones.
- El cambio confirmado activa la creación de repositorios y proyectos específicos de la aplicación.
- Cloud Build hace lo siguiente:
- Crea dos repositorios de Git para alojar el código fuente de la aplicación y la IaC.
- Envía los archivos de manifiesto de Kubernetes de las políticas de red y de Workload Identity Federation para GKE al repositorio de gestión de la configuración.
- Crea el proyecto de CI/CD de la aplicación y el activador de IaC de Cloud Build.
- El activador de IaC de Cloud Build de la aplicación crea el flujo de procesamiento de CI/CD de la aplicación y el repositorio de Artifact Registry en el proyecto de CI/CD de la aplicación.
- Config Sync implementa las políticas de red y las configuraciones de Workload Identity Federation for GKE en los clústeres de GKE multicliente.
- El flujo de creación de ámbitos de flota crea el ámbito de flota y el espacio de nombres de la aplicación en clústeres de GKE multicliente.
- El flujo de procesamiento de CI/CD de la aplicación realiza el despliegue inicial de la aplicación en los clústeres de GKE.
- De forma opcional, el equipo de aplicaciones usa el activador de IaC de Cloud Build para desplegar proyectos y recursos adicionales (por ejemplo, bases de datos y otros servicios gestionados) en proyectos de un solo inquilino específicos, uno para cada entorno.
Gestión de la configuración y las políticas de GKE Enterprise
En el plano, los administradores de la plataforma para desarrolladores usan Config Sync para crear configuraciones a nivel de clúster en cada entorno. Config Sync se conecta a un repositorio de Git que actúa como fuente de información principal para el estado elegido de la configuración del clúster. Config Sync monitoriza continuamente el estado real de la configuración de los clústeres y reconcilia cualquier discrepancia aplicando actualizaciones para asegurar que se cumpla el estado elegido, a pesar de los cambios manuales. Las configuraciones se aplican a los entornos (desarrollo, no producción y producción) mediante una estrategia de ramificación en el repositorio.
En este plano, Config Sync aplica restricciones de Policy Controller. Estas configuraciones definen los controles de seguridad y cumplimiento que establecen los administradores de la plataforma para desarrolladores de la organización. Este blueprint se basa en otras canalizaciones para aplicar otras configuraciones: las canalizaciones de CI/CD de aplicaciones aplican configuraciones específicas de la aplicación y la canalización de ámbito de flota crea espacios de nombres y enlaces de roles asociados.
Siguientes pasos
- Consulta información sobre la arquitectura de la aplicación Cymbal Bank (el siguiente documento de esta serie).