Neste documento, mostramos aos engenheiros de rede, plataforma e segurança que administram os clusters do Kubernetes como lidar com a comunicação externa de cluster para cluster usando gateways de entrada e saída do Anthos Service Mesh. Também descrevemos como usar o Anthos Service Mesh para criptografar e proteger o tráfego de saída das cargas de trabalho implantadas em um cluster do Kubernetes para as executadas em outro cluster do Kubernetes. As técnicas descritas mostram como usar certificados separados para comunicação mútua, criptografada e de cluster para cluster.
As orientações deste documento têm origem nos requisitos do cliente do uso da Autoridade de certificação (CA) (em inglês) específica de raiz para comunicação entre clusters. Esses requisitos podem ser encontrados em mercados altamente regulamentados, como serviços financeiros ou de saúde. A orientação apresentada aqui também permite o uso de endpoints diferentes dos clusters do Kubernetes, como provedores de liberação financeira ou uma interface de API para dados confidenciais. Este guia é especialmente relevante para as organizações que precisam aderir a políticas rigorosas de segurança e auditoria.
É possível operar e lidar com a comunicação criptografada sem tocar nas cargas de trabalho em execução nos clusters. Para orientações sobre como configurar seus próprios clusters, siga o tutorial complementar.
Introdução
Quando as empresas começam a adotar o Kubernetes, elas geralmente começam com um único cluster, no qual a maioria das comunicações permanece. Depois, a interação entre namespaces torna-se cada vez mais importante. Então, um provedor de políticas de rede, como o Calico ou o Cillium (links em inglês) pode ajudar. No entanto, à medida que os ambientes de contêiner aumentam, torna-se mais relevante garantir que a comunicação ocorra com segurança entre os serviços externos e os contêineres em execução nos clusters do Kubernetes.
A política de rede é uma ótima maneira de lidar com conceitos de segurança tradicionais, como a criação de regras de firewall internas do cluster, mas ela tem apenas uso limitado fora do cluster. É possível permitir que apenas um endereço IP específico seja alcançado, mas não há controle sobre o conteúdo ou a identidade disponível. Portanto, um conceito mais versátil é necessário, o que também ajuda a criptografar o tráfego para outros serviços externos. O diagrama a seguir mostra uma abordagem.
No mundo dos aplicativos, a criptografia geralmente é feita usando o TLS (Transport Layer Security; link em inglês). Isso significa que é possível criptografar o tráfego usando um certificado particular (secret) com uma contraparte pública, como mostrado no diagrama anterior. A parte receptora detém o certificado público, que é usado para verificar se as informações estão vindo de uma fonte confiável. O tráfego HTTPS da Web usa TLS para garantir comunicações seguras e criptografadas entre um cliente e um servidor da Web. Nesse caso, o certificado público é proveniente de um emissor confiável, como o Google Trust Services, também chamado de AC, que faz parte da Infraestrutura de chave pública (PKI). O TLS verifica a identidade do servidor, mas não verifica a identidade do cliente.
Nos casos em que o próprio cliente também precisa ser verificado, a autenticação mútua ou mTLS, é necessária. O mTLS é usado quando o remetente e o receptor precisam se identificar para a outra parte, como mostrado no diagrama a seguir.
Esse método geralmente é usado para aplicativos que precisam de uma camada extra de segurança. No setor financeiro e para informações de identificação pessoal (PII, na sigla em inglês), os reguladores geralmente exigem mTLS.
Anthos Service Mesh
O Anthos Service Mesh é uma solução de malha de serviço gerenciada pelo Google baseada no OSS Istio (em inglês). Isso significa que ele é totalmente compatível com a API Istio. O Anthos Service Mesh oferece funcionalidade mTLS no nível da plataforma em vez de dentro do código do aplicativo. Isso significa que ele pode ser aplicado a serviços sem exigir que você recodifique todos os serviços. Operações como a rotação de certificados também fazem parte do Anthos Service Mesh. Neste documento, o foco está no mTLS e nos recursos de comunicação externa do Anthos Service Mesh. Há muitos outros recursos, como injeção de falhas, balanceamento de carga avançado e gerenciamento de erros.
Ao rotear todo o tráfego por proxies secundários (Envoy) (em inglês), malhas de serviço como o Anthos Service Mesh liberam o desenvolvedor de tarefas repetitivas (mas importantes), como a criptografia e gerenciamento de certificados. Usando um proxy transparente, as malhas de serviço permitem funções L7 avançadas, como roteamento de chamadas HTTP e HTTPS com base em informações de cabeçalho. No entanto, o Anthos Service Mesh também permite o encapsulamento de tráfego e a criptografia, o que melhora a segurança.
Exemplo de configuração: comunicação MySQL entre clusters
Use esse cenário quando quiser ter uma comunicação segura e confiável entre serviços em clusters diferentes. Neste exemplo, o aplicativo cliente do MySQL está se comunicando com uma carga de trabalho do banco de dados do servidor MySQL em execução em um cluster diferente do Kubernetes, conforme mostrado no diagrama a seguir.
Embora as malhas de serviço geralmente funcionem no OSI L7, (em inglês) também é possível usar algumas das funcionalidades delas para controlar as comunicações L4 (em inglês).
Veja o que é necessário para fazer o conceito funcionar:
- A comunicação entre aplicativos e clusters precisa ser criptografada.
- A comunicação entre cliente e servidor precisa ser mutuamente confirmada (mTLS).
- As cargas de trabalho do cliente e do servidor não precisam ser alteradas.
É possível configurar o banco de dados MySQL (em inglês) para aceitar apenas conexões criptografadas, mas essa configuração exige que você altere o cliente do banco de dados, que talvez não seja totalmente controlado por você.
Há várias maneiras de atender a esses requisitos usando o Anthos Service Mesh. Uma maneira é criar um plano de controle compartilhado do Istio entre clusters e fazer com que os serviços se comuniquem entre si porque pertencem a uma única malha de serviço lógica. Para fazer isso em clusters do GKE ativados para Anthos, é possível usar o Anthos Service Mesh em uma configuração de projeto único ou de vários projetos.
No entanto, como há um requisito de ter uma cadeia de confiança separada para a comunicação entre clusters, é possível usar a abordagem gateway de saída <–> gateway de entrada (links em inglês) usando o mTLS.
Os gateways de saída e entrada são proxies Envoy que residem nos limites da malha.
É possível configurá-los para controlar o fluxo de tráfego para dentro e para fora da malha de serviço. Isso também funciona em endpoints que não são do Kubernetes e permite que você use certificados diferentes para a comunicação criptografada.
Configurar a saída e a entrada do Anthos Service Mesh
No cenário anterior, você viu como gerenciar a comunicação segura entre clusters usando gateways de saída e entrada entre os respectivos clusters.
O que é um gateway de saída?
Saída se refere ao tráfego que sai da malha de serviço. Um gateway de saída fornece um ponto de saída controlado para esse tráfego.
Sem outras configurações para um pod em que o proxy sidecar foi injetado, o tráfego destinado a um serviço que reside fora da malha (por exemplo, um serviço de API pública) é roteado do pod para o proxy sidecar. Em um cluster do GKE e na maioria dos outros clusters do Kubernetes, o endereço IP do nó usa um NAT para traduzir o tráfego do proxy sidecar, que sai diretamente para o endereço externo do serviço. O diagrama a seguir mostra essa configuração.
Nesse diagrama, o cliente está chamando o servidor, que representa o serviço externo. Para a malha, esse tráfego é de saída. Portanto, é necessário configurar o gateway de saída no lado do cliente (por exemplo, o cliente MySQL).
Configure o gateway de saída para encaminhar a chamada para o serviço externo. Depois que o serviço externo processa a solicitação e retorna a resposta, ele passa novamente pelo gateway de saída para o proxy do cliente e, finalmente, para o pod que está emitindo a chamada (por exemplo, o cliente do MySQL).
O que é um gateway de entrada?
Entrada se refere ao tráfego que está indo para a malha de serviço. Um gateway de entrada expõe serviços ao mundo externo (ou seja, fora da malha de serviço) e processa como esses serviços são acessados. É semelhante a um objeto Ingress do Kubernetes.
Com um gateway de entrada, é possível definir um único ponto de entrada controlado em que o tráfego entra na malha. Inicialmente, o tráfego entra pelo balanceador de carga, que é criado ao definir um serviço de gateway de entrada. Depois disso, a solicitação é encaminhada para o proxy sidecar e, do proxy, é encaminhada para o pod. O pod pode processar a solicitação e retornar a resposta usando a mesma rota ao contrário. O diagrama a seguir mostra essa configuração.
Esse é o tráfego de entrada para a malha do outro cluster (VPC 2). Portanto, é necessário configurar o gateway de entrada no servidor para processar essas chamadas.
A configuração do gateway de entrada do lado do servidor encaminha a chamada para o serviço interno. Depois que o serviço interno processa a solicitação, a resposta retorna pelo gateway de entrada ao cliente.
Como combinar a funcionalidade de saída e entrada para TLS mútuo
Como mencionado anteriormente, para o lado do cliente, é necessário definir um gateway de saída que atua como um ponto de saída controlado para a malha de serviço. Para garantir que o tráfego que sai da malha pelo gateway seja criptografado por mTLS, use uma técnica chamada origem de TLS (em inglês). Configure um gateway de saída para realizar a origem de TLS do tráfego aos serviços externos.
Quando o tráfego que sai da malha de serviço do lado do cliente é criptografado, é necessário garantir que o lado do servidor possa se identificar para o cliente e decodificar o tráfego criptografado.
Para isso, use o gateway de entrada como um único ponto de entrada na malha. Configure o gateway de entrada (em inglês) para que ele espere tráfego mutuamente criptografado.
Visão geral da arquitetura de malha
No diagrama a seguir, descrevemos o que é necessário para implementar esse conceito no cenário do MySQL, sem alterar nada no aplicativo ou no servidor.
Na VPC 1, você vê que o cluster de cliente que executa o cliente MySQL está acessando o servidor. O servidor está localizado na VPC 2.
O lado do cliente tem mais configurações do que o do servidor, porque é necessário fazer um pouco mais de correspondência e roteamento de tráfego a fim de garantir que o aplicativo use o gateway de saída. No entanto, essa configuração só precisa ser feita uma vez. Depois de implementada, a manutenção é muito fácil.
Uma vantagem de implementar esse conceito usando o Kubernetes é que todos os itens de configuração são armazenados em arquivos YAML. Isso significa que toda a construção pode ser usada em um repositório com controle de versões, o que permite acompanhar alterações e revertê-las facilmente, se necessário.
O lado do cliente
Esta subseção analisa a configuração do lado do cliente. Cada elemento que você vê no diagrama tem uma função distinta na malha para controlar como o tráfego é roteado pelo gateway de saída para chegar ao destino, o servidor MySQL.
O roteamento de tráfego é apenas uma parte da funcionalidade necessária. Outros elementos controlam a criptografia do tráfego e são totalmente transparentes para garantir que a comunicação seja sempre segura. As seções a seguir analisam os elementos para explicar melhor o papel deles e a função nesse cenário.
Entrada de serviço
Uma malha de serviço cria o próprio registro de serviço em um cluster do Kubernetes. O plano de controle usa esse registro para configurar os proxies de arquivo secundário como uma tabela de roteamento. Os serviços em execução no Kubernetes são descobertos e adicionados automaticamente ao registro da malha de serviço. Os serviços que não estão em execução no cluster do Kubernetes não podem ser descobertos automaticamente, mas podem ser definidos usando ServiceEntries. Dessa forma, o cliente pode usar uma entrada como nome do host para se conectar a serviços externos.
No Anthos Service Mesh, nomes de domínio totalmente qualificados (FQDNs, na sigla em inglês) são usados para identificar todos os serviços. O FQDN é a parte mais importante nesta construção porque os certificados são baseados no nome do host. É possível alterar o FQDN, mas isso significa que também é necessário gerar novamente todos os certificados necessários.
Para ativar a comunicação, é necessário configurar a malha de serviço para detectar chamadas ao serviço externo a fim de rotear adequadamente o tráfego. A malha permite que você defina uma entrada de serviço (em inglês) que aponte para esse serviço externo.
Essa construção é chamada de MESH_EXTERNAL e é ideal para esses casos de uso. Também
é possível especificar o que você está procurando. Como este é um caso de uso
L4 e só é possível controlar o endereço IP e a porta, é necessário informar à malha
o protocolo e as portas específicas. Neste caso, TCP e porta 3306 (a
porta de protocolo MySQL padrão). Além disso, a contraparte do servidor (como mostrado no
diagrama anterior) está detectando na porta 13306 (o gateway de saída do
cluster do servidor). Por fim, é necessário configurar a entrada do serviço para capturar o tráfego
com essa tag de porta.
A entrada de serviço YAML de exemplo a seguir ilustra essa configuração:
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: mysql-external
spec:
hosts:
- mysql.fqdn.example
location: MESH_EXTERNAL
ports:
- number: 3306
name: tcp
protocol: TCP
- number: 13306
name: tls
protocol: TLS
resolution: DNS
endpoints:
- address: mysql.fqdn.example
ports:
tls: 13306
Com o campo hosts, é possível definir o FQDN do serviço externo ou
especificar o campo location como MESH_EXTERNAL. Especifique também
os valores ports usados pelo serviço externo. Nesse caso, 13306 e
3306.
13306 será a porta exposta do gateway de entrada do lado do servidor. É
importante especificar ambos nessa entrada de serviço. Para o protocolo,
especifique TLS, porque essa conexão fornece comunicação TLS baseada em L4.
Depois de definir a entrada de serviço, a malha conseguirá detectar chamadas e alterar o roteamento com base nessas regras.
As entradas de serviço precisam ser baseadas em entradas de endereço IP ou DNS existentes, o que significa
que o nome DNS já precisa estar resolvido por um servidor DNS. Por exemplo,
é possível usar um serviço principal de DNS dentro do Kubernetes e adicionar entradas que ainda não
estão presentes em kube-dns. Não é possível usar o serviço para criar uma entrada
DNS.
Serviço virtual
O serviço virtual (em inglês) é uma definição usada para afetar os padrões de roteamento do tráfego. Use o serviço virtual para garantir que as chamadas do cliente MySQL à entrada de serviço sejam roteadas para o gateway de saída. Assim, é possível configurar um serviço virtual para rotear o tráfego com base em fatores completamente diferentes. Em um caso de uso L7, esses fatores vão além do roteamento de tráfego. Por exemplo, é possível informar ao serviço virtual como reagir se um destino estiver inacessível. Este exemplo usa um subconjunto dessa funcionalidade para rotear o tráfego correspondente apenas ao gateway de saída para processamento adicional.
O diagrama anterior mostra como usar o serviço virtual para rotear o tráfego do pod pelo proxy ao gateway de saída e do gateway de saída ao serviço externo.
Especifique também a porta do gateway de saída (voltada para o lado externo),
que é 15443 por padrão. Essa porta é definida no gateway de saída depois de
criada. É possível escolher qualquer outra porta livre, mas seria necessário corrigir o gateway
para abrir a porta escolhida.
O snippet de código a seguir mostra como pode ser uma definição de serviço virtual:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: direct-mysql-through-egress-gateway
spec:
hosts:
- mysql.fqdn.example
gateways:
- istio-egressgateway-mysql
- mesh
tcp:
- match:
- gateways:
- mesh
port: 3306
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: mysql
port:
number: 15443
weight: 100
- match:
- gateways:
- istio-egressgateway-mysql
port: 15443
route:
- destination:
host: mysql.fqdn.example
port:
number: 13306
weight: 100
O campo hosts que contém o URL do FQDN é usado para aplicar as regras de correspondência
especificamente no URL fornecido. A primeira cláusula match é definida na malha,
que é uma palavra-chave reservada e se aplica a todos os gateways dentro da malha. O
primeiro bloco route é definido para informar à malha o que fazer se a correspondência for verdadeira.
Nesse caso, você envia o tráfego correspondente ao gateway de saída. É aqui que a
porta de saída é definida, além da ponderação para a rota. O bloco
também menciona um valor subset, que é definido depois.
A segunda cláusula match é aplicada ao gateway de saída. O
segundo bloco route anexado à segunda cláusula match configura a malha
para enviar o tráfego à entrada do cluster de servidor usando o campo host
com o FQDN de entrada e especificando a porta 13306.
Na próxima etapa, você programará a injeção de certificado no gateway para que a comunicação de mTLS funcione.
Regras de destino
Agora que você identificou o tráfego corretamente (entrada de serviço) e encaminhou do pod pelo proxy ao gateway (serviço virtual), a próxima etapa é criptografar o tráfego. Use regras de destino (em inglês) para criptografar o tráfego. Essas regras em uma malha de serviço são aplicadas ao tráfego após o roteamento e são usadas para introduzir o balanceamento de carga e outras funcionalidades de gerenciamento de tráfego.
Nesse caso, use regras de destino para definir um padrão de balanceamento de carga e também adicionar certificados para ativar endpoints com comunicação mTLS. Essa etapa é realizada ao corresponder o FQDN do servidor MySQL, exposto pelo gateway de entrada do cluster do servidor e ao definir uma regra mTLS.
A definição a seguir é um exemplo dessa regra de destino:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: egressgateway-for-mysql
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: mysql
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 15443
tls:
mode: ISTIO_MUTUAL
sni: mysql.fqdn.example
O campo host está definido como o FQDN de cluster do gateway de saída. A primeira
regra de destino executa a criptografia de malha interna do tráfego usando
o modo
ISTIO_MUTUAL
(usando o FQDN do gateway de saída; link em inglês). No snippet de código, defina um
subset
(em inglês), que é usado para criar o balanceamento de carga round-robin e definir (substituir) a
porta para 15443: O gateway de saída usa essa porta para enviar o tráfego.
É importante definir o campo tls corretamente, porque ele define a
política de malha interna (ISTIO_MUTUAL). No campo sni (indicação de nome do serviço),
adicione o FQDN do gateway de entrada do cluster do servidor.
A segunda regra de destino criptografa o tráfego com os certificados de CA raiz personalizados fornecidos antes de enviá-los pelo gateway de saída:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: originate-mtls-for-mysql
spec:
host: mysql.fqdn.example
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 13306
tls:
mode: MUTUAL
credentialName: client-credential
sni: mysql.fqdn.example
O campo host está definido novamente como o FQDN externo. O campo trafficPolicy
define o modo do balanceador de carga como ROUND_ROBIN. Ele também define a porta como 13306
e o modo tls como
MUTUAL
(em inglês), porque agora você está usando os certificados da CA raiz personalizados. Já a
parte equivalente, o gateway de entrada que também usa tls MUTUAL, precisa se identificar
usando os mesmos certificados da CA raiz assinados. Usando essa porta, o tráfego
flui pelo cluster do servidor até o gateway de entrada para alcançar o banco de dados
MySQL.
A criptografia que usa os certificados da CA raiz personalizados geralmente é
feita pelo serviço de descoberta de secrets (SDS, na sigla em inglês) do Envoy
(em inglês), com um secret no Kubernetes que contém os certificados. Adicione o nome do
secret à regra de destino usando o campo credentialName.
Em resumo, o tráfego faz o seguinte:
- Ele é emitido pelo MySQL de forma transparente para um FQDN externo. Este FQDN existe no registro da malha.
- Ele é criptografado usando uma regra de destino com certificados de malha internos.
- Ele é roteado para o gateway por um serviço virtual.
- Ele é criptografado usando uma CA raiz personalizada por uma regra de destino (diferente da CA da malha usada para certificados da malha).
- Ele é encaminhado pelo gateway de saída no modo mTLS.
O lado do servidor
Nesse cenário, o servidor é mais fácil de configurar do que o cliente. Basta fornecer um gateway de entrada e uma entrada de serviço virtual para rotear o tráfego para o servidor do banco de dados MySQL, conforme mostrado no diagrama a seguir.
Gateway de entrada do cluster do servidor
O gateway de entrada está expondo a porta 13306. Pode ser qualquer porta, mas neste
caso está adicionando um "1" na frente da porta MySQL padrão para facilitar a
identificação. Por motivos de segurança, não recomendamos expor a porta
MySQL padrão (3306) diretamente à Internet.
Como o gateway de entrada padrão do Istio não está detectando na porta 13306,
é necessário adicionar essa funcionalidade. O snippet de código de exemplo a seguir aplica um patch na porta
13306 para o gateway:
[{
"op": "add",
"path": "/spec/ports/0",
"value": {
"name": "tls-mysql",
"protocol": "TCP",
"targetPort": 13306,
"port": 13306
}
}]
É possível armazenar esse código em um arquivo JSON e usá-lo com o comando de patch kubectl,
que o aplica ao serviço de gateway de entrada.
Para processar o tráfego corretamente, o gateway de entrada precisa ser configurado no modo
MUTUAL
(em inglês).
Nesse ponto, o gateway de entrada descriptografa o tráfego de entrada usando o certificado do respectivo armazenamento de credenciais e envia o tráfego para a malha, onde os certificados internos da malha são usados para recriptografar o tráfego. O snippet de código de exemplo a seguir mostra como isso pode ser configurado:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: gateway-mysql
spec:
selector:
istio: ingressgateway # Istio default gateway implementation
servers:
- port:
number: 13306
name: tls-mysql
protocol: TLS
tls:
mode: MUTUAL
credentialName: mysql-credential
hosts:
- "mysql.fqdn.example"
Neste exemplo, o gateway de entrada padrão do Istio é usado no
campo selector. Usando o campo servers, defina os valores
number (13306) e protocol (TLS) da porta que a entrada espera.
É importante dar um nome exclusivo à porta.
Defina tls e forneça um secret que contenha o certificado assinado pela
mesma CA raiz que foi usado no gateway de saída usando o campo credentialName.
O certificado precisa ser armazenado em um secret do Kubernetes.
Por fim, faça a correspondência do tráfego direcionando para o FQDN do banco de dados do MySQL. A resolução de
nomes para esse FQDN definido em hosts precisa ser definida como o endereço
IP público do gateway de entrada.
O serviço virtual do cluster do servidor
Depois que o tráfego entra na malha pela porta 13306, proveniente do
gateway de saída do cluster do cliente (originador), é necessário identificar esse
tráfego e garantir que ele chegue ao servidor de banco de dados do MySQL. Para fazer isso, defina um
serviço virtual:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: mysql-virtual-service
spec:
hosts:
- "mysql.fqdn.example"
gateways:
- gateway-mysql
tcp:
- route:
- destination:
port:
number: 3306
host: mysql.default.svc.cluster.local
Para enviar o tráfego ao serviço de banco de dados do MySQL, é necessário verificar o host
FQDN novamente usando o campo hosts. Além disso, é necessário usar o campo gateways
para configurar onde aplicar essa definição de serviço virtual. Esse é o
objeto de gateway definido no arquivo YAML anterior. Defina o
campo tcp, porque este é o tráfego L4, e defina o campo route para apontar ao
serviço Kubernetes de banco de dados do MySQL. Especifique o nome do serviço no campo host
usando o FQDN interno do cluster do Kubernetes.
O banco de dados do MySQL pode receber solicitações do cliente na porta 3306. O tráfego
atravessa o proxy secundário do servidor do banco de dados MySQL. No servidor do banco de dados do
MySQL, ele se parece com uma solicitação local e não criptografada de acesso ao banco de dados.
Depois que o servidor responde à chamada, o tráfego volta para o cliente usando a mesma rota. Para o cliente, isso é semelhante a um banco de dados local atender a chamada.
O tráfego é criptografado três vezes usando certificados diferentes que vão do cliente para o servidor, o que ajuda a proteger a comunicação entre cliente e servidor.
Na primeira vez que o tráfego é criptografado ou descriptografado, ele fica dentro da malha no lado do cliente, com os certificados que usam a CA da malha.
Na segunda vez, o tráfego é criptografado ao sair da malha no gateway de saída usando um certificado de uma CA raiz personalizada. Em seguida, o tráfego é autenticado e descriptografado no gateway de entrada usando um certificado assinado pela mesma CA raiz personalizada.
Na última (terceira) vez, o tráfego é criptografado ou descriptografado dentro da malha no lado do servidor durante a transferência do gateway de entrada para o servidor MySQL. Nesta etapa, por ser uma malha interna, os certificados da CA da malha são usados novamente.
Nesse cenário, a comunicação entre os dois clusters precisava ser criptografada usando a CA raiz mencionada. Ao aplicar essa configuração, é possível processar essa parte separadamente dos certificados internos da malha e do próprio aplicativo.
Com essa etapa extra, essa configuração também permite fazer a rotação desses certificados fácil e regularmente sem alterar a CA da malha dos respectivos clusters do Kubernetes.
A seguir
- Teste o tutorial complementar.
- Consulte o guia de aumento da proteção do GKE.
- Saiba como gerenciar a configuração e a política em toda a infraestrutura com o Config Management.
- Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.