El patrón salida controlada y entrada controlada usa una combinación de salida controlada y entrada controlada en situaciones que requieren el uso bidireccional de APIs seleccionadas entre cargas de trabajo. Las cargas de trabajo se pueden ejecutar en Google Cloud, en entornos privados on-premise o en otros entornos de nube. En este patrón, puedes usar pasarelas de APIs, puntos finales de Private Service Connect o balanceadores de carga para exponer APIs específicas y, opcionalmente, proporcionar autenticación, autorización y auditorías de llamadas a APIs.
La diferencia clave entre este patrón y el patrón de malla radica en su aplicación a situaciones que solo requieren el uso bidireccional de APIs o la comunicación con fuentes y destinos de direcciones IP específicos, como una aplicación publicada a través de un punto final de Private Service Connect. Como la comunicación se limita a las APIs expuestas o a direcciones IP específicas, no es necesario que las redes de los entornos se alineen en tu diseño. Estos son algunos ejemplos de situaciones en las que se aplica esta política:
- Fusiones y adquisiciones.
- Integraciones de aplicaciones con partners.
- Integraciones entre aplicaciones y servicios de una organización con diferentes unidades organizativas que gestionan sus propias aplicaciones y las alojan en entornos distintos.
La comunicación funciona de la siguiente manera:
- Las cargas de trabajo que implementes en Google Cloud pueden comunicarse con la pasarela de APIs (o con direcciones IP de destino específicas) mediante direcciones IP internas. No se puede acceder a otros sistemas implementados en el entorno de computación privado.
- Por el contrario, las cargas de trabajo que implementes en otros entornos de computación pueden comunicarse con la pasarela de API del lado de Google Cloud(o con una dirección IP de endpoint publicada específica) mediante direcciones IP internas. No se puede acceder a otros sistemas implementados en Google Cloud .
Arquitectura
En el siguiente diagrama se muestra una arquitectura de referencia para el patrón de salida controlada y entrada controlada:
El enfoque de diseño del diagrama anterior tiene los siguientes elementos:
- En el lado de Google Cloud , despliega cargas de trabajo en una VPC (o una VPC compartida) sin exponerlas directamente a Internet.
- La red de Google Cloud entorno se amplía a otros entornos informáticos. Este entorno puede ser local o estar en otra nube. Para ampliar el entorno, usa un patrón de comunicación de conectividad híbrida y multinube adecuado para facilitar la comunicación entre los entornos de forma que puedan usar direcciones IP internas.
- De forma opcional, si habilitas el acceso a direcciones IP de destino específicas, puedes usar una VPC de tránsito para añadir una capa de seguridad perimetral fuera de la VPC de tu aplicación.
- Puedes usar Cloud Next Generation Firewall o dispositivos virtuales de red (NVAs) con cortafuegos de nueva generación (NGFWs) en la VPC de tránsito para inspeccionar el tráfico y permitir o prohibir el acceso a determinadas APIs desde fuentes específicas antes de que lleguen a tu VPC de aplicación.
- Se debe acceder a las APIs a través de una pasarela de APIs o un balanceador de carga para proporcionar una capa de proxy, así como una abstracción o una fachada para las APIs de tu servicio.
- En el caso de las aplicaciones que se consumen como APIs, también puedes usar Private Service Connect para proporcionar una dirección IP interna a la aplicación publicada.
- Todos los entornos usan un espacio de direcciones IP RFC 1918 sin solapamientos.
Una aplicación habitual de este patrón consiste en desplegar back-ends de aplicaciones (o un subconjunto de back-ends de aplicaciones) en Google Cloud , mientras que otros componentes de back-end y de front-end se alojan en entornos on-premise o en otras nubes (patrón híbrido por niveles o patrón multinube particionado). A medida que las aplicaciones evolucionan y migran a la nube, suelen surgir dependencias y preferencias por servicios de nube específicos.
A veces, estas dependencias y preferencias llevan a la distribución de aplicaciones y back-ends entre diferentes proveedores de servicios en la nube. Además, algunas aplicaciones se pueden crear con una combinación de recursos y servicios distribuidos en entornos on-premise y en varios entornos de nube.
En el caso de las aplicaciones distribuidas, las funciones de conectividad híbrida y multinube de Cloud Load Balancing externo se pueden usar para finalizar las solicitudes de los usuarios y enrutarlas a frontends o backends de otros entornos. Este enrutamiento se produce a través de una conexión de red híbrida, como se muestra en el siguiente diagrama. Esta integración permite distribuir gradualmente los componentes de la aplicación en diferentes entornos. Las solicitudes del frontend a los servicios de backend alojados en Google Cloud se comunican de forma segura a través de la conexión de red híbrida establecida, facilitada por un balanceador de carga interno (ILB en el diagrama).
El diseño Google Cloud del diagrama anterior te ayuda a hacer lo siguiente:
- Facilita la comunicación bidireccional entre Google Cloud, entornos locales y otros entornos de nube mediante APIs predefinidas en ambos lados que se ajustan al modelo de comunicación de este patrón.
- Para proporcionar front-ends globales para aplicaciones accesibles desde Internet con componentes de aplicación distribuidos (front-ends o back-ends) y para lograr los siguientes objetivos, puedes usar las funciones avanzadas de balanceo de carga y seguridad Google Cloud distribuidas en puntos de presencia (PoPs):
- Reduce los gastos de capital y simplifica las operaciones usando servicios gestionados sin servidor.
- Optimiza las conexiones a los back-ends de las aplicaciones en todo el mundo para mejorar la velocidad y la latencia.
- Google Cloud Cross-Cloud Network permite la comunicación multinube entre componentes de aplicaciones a través de conexiones privadas óptimas.
- Almacena en caché el contenido estático de alta demanda y mejora el rendimiento de las aplicaciones que usan Cloud Load Balancing global proporcionando acceso a Cloud CDN.
- Protege los frontends globales de las aplicaciones orientadas a Internet mediante las funciones de Google Cloud Armor, que proporcionan servicios de cortafuegos de aplicaciones web (WAF) y de mitigación de ataques DDoS distribuidos a nivel mundial.
- Si quieres, puedes incorporar Private Service Connect a tu diseño. De esta forma, se habilita un acceso privado y detallado a las APIs de servicios o a los servicios publicados desde otros entornos sin tener que atravesar la red pública de Internet. Google Cloud
Variantes
Los patrones de arquitectura salida controlada y entrada controlada se pueden combinar con otros enfoques para cumplir diferentes requisitos de diseño, sin dejar de tener en cuenta los requisitos de comunicación de este patrón. Los patrones ofrecen las siguientes opciones:
- Pasarelas de API distribuidas
- Comunicación bidireccional de APIs mediante Private Service Connect
- Comunicación bidireccional mediante puntos finales e interfaces de Private Service Connect
Pasarelas de APIs distribuidas
En situaciones como la basada en el patrón de multinube particionada, las aplicaciones (o los componentes de las aplicaciones) se pueden crear en diferentes entornos de nube, incluido un entorno privado local. El requisito habitual es enrutar las solicitudes de los clientes al frontend de la aplicación directamente al entorno en el que se aloja la aplicación (o el componente de frontend). Este tipo de comunicación requiere un balanceador de carga local o una pasarela de API. Es posible que estas aplicaciones y sus componentes también requieran funciones específicas de la plataforma de APIs para la integración.
En el siguiente diagrama se muestra cómo se han diseñado Apigee y Apigee Hybrid para satisfacer estos requisitos con una pasarela de API localizada en cada entorno. La gestión de la plataforma de APIs se centraliza en Google Cloud. Este diseño ayuda a aplicar medidas de control de acceso estrictas, de forma que solo las direcciones IP aprobadas previamente (las APIs de destino y de origen, o las direcciones IP de los endpoints de Private Service Connect) puedan comunicarse entre sí Google Cloud y los demás entornos.
En la siguiente lista se describen las dos rutas de comunicación distintas del diagrama anterior que usan la pasarela de Apis de Apigee:
- Las solicitudes de los clientes llegan directamente al frontend de la aplicación en el entorno que aloja la aplicación (o el componente de frontend).
- Las pasarelas y los proxies de APIs de cada entorno gestionan las solicitudes de APIs de clientes y aplicaciones en diferentes direcciones en varios entornos.
- La función de pasarela de APIs de Google Cloud (Apigee) expone los componentes de la aplicación (frontend o backend) alojados en Google Cloud.
- La función de pasarela de APIs de otro entorno (híbrido) expone los componentes frontend (o backend) de la aplicación que están alojados en ese entorno.
También puedes usar una VPC de tránsito. Una VPC de tránsito puede proporcionar flexibilidad para separar las tareas y realizar inspecciones de seguridad y conectividad híbrida en una red de VPC independiente. Desde el punto de vista de la accesibilidad de las direcciones IP, una VPC de tránsito (donde se adjunta la conectividad híbrida) facilita los siguientes requisitos para mantener la accesibilidad de extremo a extremo:
- Las direcciones IP de las APIs de destino deben anunciarse en los demás entornos en los que se alojan los clientes o los solicitantes.
- Las direcciones IP de los hosts que necesiten comunicarse con las APIs de destino deben anunciarse en el entorno en el que residan las APIs de destino. Por ejemplo, las direcciones IP del solicitante de la API (el cliente). La excepción se produce cuando la comunicación se realiza a través de un balanceador de carga, un proxy, un endpoint de Private Service Connect o una instancia NAT.
Para ampliar la conectividad al entorno remoto, este diseño usa el emparejamiento directo de VPC con la función de intercambio de rutas de clientes. El diseño permite que las solicitudes de API específicas que proceden de cargas de trabajo alojadas en la VPC de la aplicación se enruten a través de la VPC de tránsito. Google Cloud También puedes usar un endpoint de Private Service Connect en la VPC de la aplicación que esté asociado a un balanceador de carga con un backend de grupo de endpoints de red híbrida en la VPC de tránsito. Esta configuración se describe en la siguiente sección: comunicación bidireccional de APIs mediante Private Service Connect.
Comunicación bidireccional de APIs mediante Private Service Connect
A veces, las empresas no necesitan usar una pasarela de APIs (como Apigee) inmediatamente o quieren añadirla más adelante. Sin embargo, puede que haya requisitos empresariales para habilitar la comunicación y la integración entre determinadas aplicaciones en diferentes entornos. Por ejemplo, si tu empresa ha adquirido otra empresa, es posible que tengas que exponer determinadas aplicaciones a esa empresa. Es posible que tengan que exponer aplicaciones a tu empresa. Ambas empresas pueden tener sus propias cargas de trabajo alojadas en entornos diferentes (Google Cloud, locales u otras nubes) y deben evitar que se solapen las direcciones IP. En estos casos, puedes usar Private Service Connect para facilitar la comunicación.
En el caso de las aplicaciones que se consumen como APIs, también puedes usar Private Service Connect para proporcionar una dirección privada a las aplicaciones publicadas, lo que permite acceder de forma segura a la red privada en diferentes regiones y a través de la conectividad híbrida. Esta abstracción facilita la integración de recursos de diferentes nubes y entornos locales a través de un modelo de conectividad híbrido y multinube. También permite ensamblar aplicaciones en entornos multinube y on-premise. De esta forma, se pueden satisfacer diferentes requisitos de comunicación, como la integración de aplicaciones seguras en las que no se usa o no se tiene previsto usar una pasarela de APIs.
Si usas Private Service Connect con Cloud Load Balancing, como se muestra en el siguiente diagrama, puedes conseguir dos rutas de comunicación distintas. Cada ruta se inicia desde una dirección diferente con un propósito de conectividad distinto, preferiblemente a través de llamadas a la API.
- Todas las consideraciones y recomendaciones de diseño de Private Service Connect que se describen en esta guía se aplican a este diseño.
- Si se requiere una inspección adicional de la capa 7, puedes integrar NVAs con este diseño (en la VPC de tránsito).
- Este diseño se puede usar con o sin pasarelas de APIs.
Las dos rutas de conectividad que se muestran en el diagrama anterior representan conexiones independientes y no ilustran la comunicación bidireccional de una sola conexión o flujo.
Comunicación bidireccional mediante endpoints e interfaces de Private Service Connect
Como se explica en el patrón de entrada controlada, una de las opciones para habilitar la comunicación entre el cliente y el servicio es usar un punto final de Private Service Connect para exponer un servicio en una VPC de productor a una VPC de consumidor. Esa conectividad se puede ampliar a un entorno local o incluso a otro entorno de proveedor de la nube mediante una conectividad híbrida. Sin embargo, en algunos casos, el servicio alojado también puede requerir una comunicación privada.
Para acceder a un servicio concreto, como recuperar datos de fuentes de datos que se pueden alojar dentro o fuera de la VPC del consumidor, esta comunicación privada puede producirse entre la VPC de la aplicación (productor) y un entorno remoto, como un entorno local.
En este caso, las interfaces de Private Service Connect permiten que una instancia de VM de un productor de servicios acceda a la red de un consumidor. Para ello, comparte una interfaz de red, pero mantiene la separación de los roles de productor y consumidor. Con esta interfaz de red en la VPC de consumidor, la VM de la aplicación puede acceder a los recursos de consumidor como si estuvieran ubicados de forma local en la VPC de productor.
Una interfaz de Private Service Connect es una interfaz de red conectada a la VPC de tránsito del consumidor. Es posible acceder a destinos externos a los que se puede acceder desde la VPC de consumidor (de tránsito) en la que está conectada la interfaz de Private Service Connect. Por lo tanto, esta conexión se puede ampliar a un entorno externo a través de una conectividad híbrida, como un entorno local, tal como se ilustra en el siguiente diagrama:
Si la VPC del consumidor pertenece a una organización o entidad externa, como una organización de terceros, normalmente no podrás proteger la comunicación con la interfaz de Private Service Connect en la VPC del consumidor. En este caso, puedes definir políticas de seguridad en el SO invitado de la VM de la interfaz de Private Service Connect. Para obtener más información, consulta el artículo Configurar la seguridad de las interfaces de Private Service Connect. También puedes plantearte otra opción si no cumple los estándares o los requisitos de seguridad de tu organización.
Prácticas recomendadas
En situaciones en las que las solicitudes de clientes de Internet deban recibirse localmente por un frontend alojado en un entorno privado on-premise u otro entorno de nube, te recomendamos que uses Hybrid como solución de pasarela de API.
- Este enfoque también facilita la migración de la solución a un entorno totalmente Google Cloudalojado, al tiempo que se mantiene la coherencia de la plataforma de APIs (Apigee).
Para minimizar la latencia y optimizar los costes de grandes volúmenes de transferencias de datos salientes a otros entornos cuando estos entornos se encuentren en configuraciones híbridas o multicloud a largo plazo o permanentes, ten en cuenta lo siguiente:
- Usa Cloud Interconnect o Cross-Cloud Interconnect.
- Para finalizar las conexiones de los usuarios en el frontend de destino del entorno adecuado, usa Híbrido.
Cuando sea aplicable a tus requisitos y a la arquitectura, usa Apigee Adapter for Envoy con un despliegue híbrido con Kubernetes.
Antes de diseñar las rutas de conectividad y enrutamiento, primero debe identificar qué tráfico o solicitudes de API deben dirigirse a una pasarela de API local o remota, junto con los entornos de origen y de destino.
Usa Controles de Servicio de VPC para proteger los Google Cloud servicios de tus proyectos y mitigar el riesgo de filtración externa de datos. Para ello, especifica perímetros de servicio a nivel de proyecto o de red de VPC.
- Puedes ampliar los perímetros de servicio a un entorno híbrido a través de una VPN o Cloud Interconnect autorizados. Para obtener más información sobre las ventajas de los perímetros de servicio, consulta Información general sobre Controles de Servicio de VPC.
Usa reglas de cortafuegos de nube privada virtual (VPC) u políticas de cortafuegos para controlar el acceso a nivel de red a los recursos de Private Service Connect a través del endpoint de Private Service Connect. Por ejemplo, las reglas de cortafuegos salientes de la VPC de la aplicación (consumidor) pueden restringir el acceso de las instancias de VM a la dirección IP o la subred de tus endpoints.
Cuando se usa una interfaz de Private Service Connect, debes proteger la comunicación con la interfaz configurando la seguridad de la interfaz de Private Service Connect.
Si una carga de trabajo de una subred privada requiere acceso a Internet, usa Cloud NAT para evitar asignar una dirección IP externa a la carga de trabajo y exponerla a Internet público.
- Para el tráfico web de salida, usa proxy web seguro. El proxy ofrece varias ventajas.
Consulta las prácticas recomendadas generales para los patrones de redes híbridas y multicloud.