Os padrões de saída controlada e entrada controlada usam uma combinação de saída controlada e entrada controlada para cenários que exigem o uso bidirecional de APIs selecionadas entre as cargas de trabalho. As cargas de trabalho podem ser executadas no Google Cloud, em ambientes privados ambientes de aplicativos ou em outros ambientes de nuvem. Nesse padrão, é possível gateways de API, endpoints do Private Service Connect ou balanceadores de carga para expor APIs específicas e, opcionalmente, fornecer autenticação, autorização e auditorias de chamadas de API.
A principal distinção entre esse padrão e o padrão em malha aplica-se a cenários que exigem apenas o uso de API bidirecional ou comunicação com origens e destinos específicos de endereços IP, por exemplo, um aplicativo publicado por um endpoint do Private Service Connect. Como a comunicação é restrita às APIs expostas ou a endereços IP específicos, as redes em ambientes não precisam se alinhar ao seu design. Cenários comuns aplicáveis incluem, sem limitação:
- Fusões e aquisições.
- Integrações de aplicativos com parceiros.
- Integrações entre aplicativos e serviços de uma organização com diferentes unidades organizacionais que gerenciam os próprios aplicativos e hospedam em ambientes diferentes.
A comunicação funciona da seguinte maneira:
- As cargas de trabalho implantadas no Google Cloud podem se comunicar com o gateway de API (ou endereços IP de destino específicos) usando endereços IP. Outros sistemas implantados no ambiente de computação particular não pode ser contatados.
- Por outro lado, as cargas de trabalho implantadas em outros ambientes de computação podem se comunicar com o gateway de API do Google Cloud (ou uma rede endereço IP de endpoint publicado) usando endereços IP internos. Outros sistemas implantados no Google Cloud não podem ser acessados.
Arquitetura
O diagrama a seguir mostra uma arquitetura de referência para o padrão de saída controlada e entrada controlada:
A abordagem do design no diagrama anterior tem os seguintes elementos:
- No lado do Google Cloud, você implanta cargas de trabalho em uma VPC (ou VPC compartilhada) sem expô-las diretamente à Internet.
- A rede do ambiente do Google Cloud é estendida para outros de computação em nuvem. Esse ambiente pode estar no local ou em outra nuvem. Para estender o ambiente, use um padrão de comunicação de conectividade híbrida e de várias nuvens para facilitar a comunicação entre os ambientes para que eles possam usar endereços IP internos.
- Outra opção é ativar o acesso a endereços IP de destino específicos.
Você pode usar uma VPC de trânsito para adicionar uma camada de segurança de perímetro fora do
VPC do aplicativo.
- Você pode usar o Cloud Next Generation Firewall ou dispositivos virtuais de rede (NVAs, na sigla em inglês) com firewalls de última geração (NGFWs) na VPC de trânsito para inspecionar o tráfego e permitir ou proibir o acesso a determinadas APIs por meio de origens específicas antes de chegar à VPC do seu aplicativo.
- É preciso acessar as APIs por um gateway de API ou balanceador de carga para fornecer uma camada de proxy e uma abstração ou fachada para as suas APIs de serviço.
- Para aplicativos consumidos como APIs, você também pode usar o Private Service Connect para fornecer um endereço IP interno do aplicativo publicado.
- Todos os ambientes usam o espaço de endereço IP RFC 1918 sem sobreposição.
Uma aplicação comum desse padrão envolve a implantação de back-ends de aplicativos (ou um subconjunto de back-ends de aplicativos) no Google Cloud enquanto hospeda outros componentes de back-end e front-end em ambientes locais ou em outras nuvens (padrão híbrido em camadas) ou padrão multicloud particionado). À medida que os aplicativos evoluem e migram para a nuvem, as dependências e preferências de serviços em nuvem específicos geralmente surgem.
Às vezes, essas dependências e preferências levam à distribuição de aplicativos e back-ends em diferentes provedores de nuvem. Além disso, alguns aplicativos podem ser criados com uma combinação de recursos e serviços distribuídos em ambientes no local e em várias nuvens.
Para aplicativos distribuídos, os recursos da conectividade externa híbrida e de multicloud do Cloud Load Balancing podem ser usados para encerrar solicitações de usuários e encaminhá-las para front-ends ou back-ends em outros ambientes. Esse roteamento ocorre em uma conexão de rede híbrida, conforme ilustrado no diagrama a seguir. Essa integração permite a a distribuição de componentes de aplicativos em diferentes ambientes. Solicitações do front-end para os serviços de back-end hospedados no Google Cloud se comunicam com segurança na conexão de rede híbrida estabelecida, facilitada por um balanceador de carga interno (ILB no diagrama).
Usar o design do Google Cloud no diagrama anterior ajuda no seguinte:
- Facilita a comunicação bidirecional entre o Google Cloud, ambientes no local eoutros ambientes de nuvem usando APIs predefinidas em ambos lados que se alinham com o modelo de comunicação desse padrão.
- Para fornecer front-ends globais para aplicativos voltados à Internet com componentes de aplicativo distribuídos (front-ends ou back-ends) e para atingir as metas a seguir, use os recursos de balanceamento e segurança avançados do Google Cloud distribuídos em pontos de presença (PoPs, na sigla em inglês):
- Reduzir as despesas de capital e simplificar as operações usando serviços gerenciados sem servidor.
- Otimizar conexões com back-ends de aplicativos globalmente para aumentar a velocidade
e latência.
- O Cross-Cloud Network do Google Cloud permite a comunicação em várias nuvens entre componentes de aplicativos em conexões privadas ideais.
- Armazenar em cache conteúdo estático de alta demanda e melhorar o desempenho dos aplicativos que usam o Cloud Load Balancing global fornecendo acesso ao Cloud CDN.
- Proteger os front-ends globais dos aplicativos voltados à Internet usando os recursos do Google Cloud Armor que oferecem serviços de firewall de aplicativos da Web (WAF) e mitigação de DDoS distribuídos globalmente.
- Outra opção é incorporar o Private Service Connect ao seu design. Isso permite que particular e refinado às APIs de serviço do Google Cloud ou à sua serviços publicados de outros ambientes sem passar pela Internet pública.
Variações
Os padrões de arquitetura de saída controlada e entrada controlada podem ser combinados com outras abordagens para atender a diferentes requisitos de design, sem deixar de considerar os requisitos de comunicação desse padrão. Os padrões oferecem os seguintes opções:
- Gateways de API distribuídos
- Comunicação bidirecional de API com o Private Service Connect
- Comunicação bidirecional usando endpoints e interfaces do Private Service Connect
Gateways de API distribuídos
Em cenários como o baseado no padrão de várias nuvens particionadas, aplicativos (ou componentes de aplicativos) podem ser criados em diferentes do Google Cloud, incluindo um ambiente particular no local. O requisito comum é encaminhar as solicitações de clientes para o front-end do aplicativo diretamente para o ambiente em que o aplicativo ou o componente de front-end está hospedado. Esta desse tipo de comunicação requer um balanceador de carga local ou um gateway de API. Esses aplicativos e os respectivos componentes também podem exigir uma plataforma de API específica recursos de integração.
O diagrama a seguir ilustra como a Apigee e Apigee híbrida foram projetados para atender a esses requisitos com um gateway de API localizado em cada ambiente de execução. O gerenciamento da plataforma de API é centralizado no Google Cloud. Esta ajuda a aplicar medidas de controle de acesso estritas quando apenas endereços IP (APIs de destino e endereços IP de endpoint do Private Service Connect) podem se comunicar entre o Google Cloud e os outros ambientes.
A lista a seguir descreve as duas instâncias caminhos de comunicação no diagrama anterior que usam Apigee Gateway de API:
- As solicitações do cliente chegam ao front-end do aplicativo diretamente na o ambiente que hospeda o aplicativo ou o componente do front-end.
- Os gateways e proxies de API em cada ambiente lidam com clientes e
solicitações de API do aplicativo em direções diferentes em vários
do Google Cloud.
- A funcionalidade de gateway de API no Google Cloud (Apigee) expõe o aplicativo (front-end ou back-end) e componentes hospedados no Google Cloud.
- A funcionalidade de gateway de API em outro ambiente (Híbrido) expõe o front-end do aplicativo (ou back-end) que estão hospedados nesse ambiente.
Outra opção é usar uma VPC de trânsito. Uma VPC de trânsito pode fornecer flexibilidade para separar preocupações e realizar inspeção de segurança e implantações em uma rede VPC separada. A partir de um endereço IP acessível uma VPC de trânsito, com conectividade híbrida facilita os seguintes requisitos para manter a acessibilidade de ponta a ponta:
- Os endereços IP das APIs de destino precisam ser anunciados para a outra ambientes onde os clientes/solicitantes estão hospedados.
- Os endereços IP dos hosts que precisam se comunicar com o destino. As APIs precisam ser anunciadas para o ambiente onde a API de destino reside, por exemplo, os endereços IP do solicitante da API (o cliente). O é quando a comunicação ocorre por um balanceador de carga, um proxy endpoint do Private Service Connect ou instância NAT.
Para ampliar a conectividade ao ambiente remoto, este projeto usa VPC direta peering com troca de rota do cliente capacidade de processamento. O design permite solicitações de API específicas que se originam de cargas de trabalho hospedados na VPC do aplicativo do Google Cloud para rotear pela VPC de trânsito. Como alternativa, é possível usar um endpoint do Private Service Connect em a VPC do aplicativo associada a uma carga com um back-end de grupo de endpoints de rede híbrido na VPC de trânsito. Aquele está descrito na próxima seção: Comunicação de API bidirecional usando Private Service Connect.
Comunicação bidirecional de API com o Private Service Connect
Às vezes, as empresas podem não precisar usar um gateway de API (como Apigee) imediatamente, ou pode querer adicioná-la mais tarde. No entanto, pode haver requisitos de negócios para permitem a comunicação e a integração entre certos aplicativos em diferentes do Google Cloud. Por exemplo, se sua empresa adquiriu outra empresa, você pode precisaria expor certos aplicativos a essa empresa. Eles podem precisar expor aplicativos para sua empresa. Ambas as empresas podem ter cargas de trabalho próprias hospedados em ambientes diferentes (Google Cloud, no local ou em outros nuvens) e evitar sobreposições de endereços IP. Nesses casos, você pode usar Private Service Connect para facilitar a comunicação eficaz.
Para aplicativos consumidos como APIs, você também pode usar Private Service Connect para fornecer um endereço particular para os aplicativos publicados, o que permite o acesso seguro no ambiente de rede entre regiões e em conectividade híbrida. Essa abstração facilita a integração de recursos locais e de nuvens diversas ambientes em um modelo de conectividade híbrido e de multicloud. Ele também permite a montagem de aplicativos em ambientes locais e multicloud. Isso pode satisfazer diferentes requisitos de comunicação, como a integração aplicativos em que um gateway de API não é usado ou não está planejado para ser usado.
Usando o Private Service Connect com o Cloud Load Balancing, conforme mostrado a seguir: é possível estabelecer dois caminhos de comunicação distintos. Cada caminho iniciado de uma direção diferente para uma finalidade de conectividade separada; idealmente por chamadas de API.
- Todas as considerações e recomendações de design do Private Service Connect discutidas neste neste guia se aplicam a este design.
- Se uma inspeção adicional da camada 7 for necessária, integre os NVAs com esse design (na VPC de trânsito).
- Esse design pode ser usado com ou sem gateways de API.
Os dois caminhos de conectividade descritos no diagrama anterior representam conexões independentes e não ilustram a comunicação bidirecional de um único uma conexão ou fluxo.
Comunicação bidirecional usando endpoints e interfaces do Private Service Connect
Conforme discutido nas padrão de entrada controlado, uma das opções para ativar a comunicação entre serviços e cliente é usar um Endpoint do Private Service Connect para expor um serviço em um produtor VPC para uma VPC do consumidor. Aquele a conectividade pode ser estendida a um ambiente no local ou até mesmo de nuvem do provedor em uma conectividade híbrida. No entanto, em alguns cenários, e o serviço hospedado podem exigir comunicação particular.
Para acessar um determinado serviço, como recuperar dados de fontes que podem ser hospedadas dentro ou fora da VPC do consumidor, essa comunicação privada pode ser entre a VPC do aplicativo (produtor) e um ambiente remoto, como local.
Nesse cenário, Interfaces do Private Service Connect permitem que uma instância de VM do produtor de serviços acesse a rede de um consumidor. Ele faz isso compartilhando uma interface de rede, mantendo a separação das funções de produtor e consumidor. Com essa interface de rede VPC do consumidor, a VM do aplicativo pode acessar os recursos do consumidor como se eles que residem localmente na VPC do produtor.
Uma interface do Private Service Connect é uma interface de rede anexadas à VPC do consumidor (transit). É possível alcançar pessoas que podem ser acessados pela VPC do consumidor (transporte), em que o A interface do Private Service Connect está anexada. Portanto, essa conexão pode ser estendida para um ambiente externo por meio de uma conectividade híbrida, como um ambiente local, conforme ilustrado nas diagrama a seguir:
Se a VPC do consumidor for uma organização ou entidade externa, como um organização, normalmente você não terá a capacidade de proteger a comunicação à interface do Private Service Connect na VPC do consumidor. Em neste cenário, é possível definir políticas de segurança no SO convidado da VM da interface do Private Service Connect. Para mais informações, ver Configure a segurança das interfaces do Private Service Connect. Ou você pode considerar uma abordagem alternativa se ela não estiver em conformidade com compliance ou padrões de segurança da sua organização.
Práticas recomendadas
Para situações em que as solicitações de clientes da Internet precisam ser recebidos localmente por um front-end hospedado em uma rede local de nuvem híbrida, considere usar o modelo híbrido de gateway de borda.
- Essa abordagem também facilita a migração da solução para um ambiente totalmente hospedado no Google Cloud, mantendo a consistência da plataforma de API (Apigee).
Para minimizar a latência e otimizar os custos de grandes volumes de dados de saída para seus outros ambientes quando eles estiverem em as configurações híbridas ou de várias nuvens permanentes ou de longo prazo:
- Usar o Cloud Interconnect ou o Cross-Cloud Interconnect.
- Para encerrar conexões de usuário no front-end de destino na ambiente apropriado, use Híbrido:
Quando aplicável aos seus requisitos e à arquitetura, use Adaptador da Apigee para Envoy com um Implantação híbrida com o Kubernetes.
Antes de projetar a conectividade e os caminhos de roteamento, você precisa identificar qual tráfego ou solicitações de API precisam ser direcionados a um local ou gateway de API remoto, além dos ambientes de origem e destino.
Use o VPC Service Controls para proteger os serviços do Google Cloud na sua projetos e para mitigar o risco de exfiltração de dados, especificando perímetros de serviço no nível do projeto ou da rede VPC.
- Você pode estender perímetros de serviço para um ambiente híbrido usando uma VPN autorizada ou o Cloud Interconnect. Para mais informações sobre os benefícios dos perímetros de serviço, consulte Visão geral do VPC Service Controls.
Usar Regras de firewall da nuvem privada virtual (VPC) ou políticas de firewall para controlar o acesso aos recursos no Private Service Connect no nível da rede usando o endpoint do Private Service Connect. Por exemplo: regras de firewall de saída na VPC do aplicativo (consumidor) pode restringir o acesso das instâncias de VM o endereço IP ou a sub-rede dos endpoints.
Ao usar uma interface do Private Service Connect, é preciso para proteger a comunicação do Terraform. Para isso, configure a segurança do Interface do Private Service Connect.
Se uma carga de trabalho em uma sub-rede privada exigir acesso à Internet, use Cloud NAT para evitar atribuir um endereço IP externo à carga de trabalho e expô-la a na Internet pública.
- Para o tráfego de saída da Web, use Proxy seguro da Web. O proxy oferece vários benefícios.
Consulte a práticas recomendadas gerais para padrões de rede híbridos e multicloud.