Algumas ou todas as informações nesta página podem não se aplicar ao Cloud de Confiance da S3NS. Consulte Diferenças do Google Cloud para saber mais.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Encaminhar o tráfego de saída ambiente pelo Secure Web Proxy

Autopilot Standard

Nesta página, mostramos como configurar o roteamento de saída para cargas de trabalho executadas na rede ambiente do Google Kubernetes Engine (GKE) para um gateway do Secure Web Proxy (SWP).

Ao rotear o tráfego de saída por um gateway do Secure Web Proxy, é possível aplicar políticas de segurança de saída centralizadas, como filtragem de URL, listas de permissão de domínio e inspeção TLS, sem modificar o código do aplicativo. O proxy de nó da camada 4 intercepta o tráfego de saída fora do pod do aplicativo, fornecendo isolamento de segurança fora do pod, mesmo que um contêiner de carga de trabalho seja comprometido.

Arquitetura e fluxo de tráfego

Nesse modelo de implantação, você mantém a propriedade da infraestrutura, incluindo o cluster do GKE, a instância do Secure Web Proxy e todos os endpoints do Private Service Connect (PSC).

O fluxo de tráfego de saída funciona da seguinte maneira:

Um pod de carga de trabalho ou agente de IA inicia o tráfego de saída para um endpoint externo ou destino da Internet.
O proxy de nó ambiente local da camada 4 intercepta a solicitação de saída no nó.
O proxy de nó estabelece um túnel HTTP CONNECT para o gateway de saída.
Se o Secure Web Proxy estiver em uma rede VPC diferente, o tráfego vai passar por um anexo de serviço PSC.
O Secure Web Proxy encerra o túnel, aplica as políticas de segurança de saída configuradas e encaminha as solicitações autorizadas para o destino.

Limitações

Antes de configurar o roteamento de saída do Secure Web Proxy, revise as seguintes limitações na prévia:

Políticas de namespace:as políticas de roteamento de saída são aplicadas somente no nível do namespace. Não é possível fazer uma seleção granular de pods usando seletores de rótulos.
A filtragem de nomes de host exige inspeção TLS:as políticas do Secure Web Proxy só podem filtrar o tráfego de saída por endereço IP, a menos que a inspeção TLS esteja ativada.
Identidade da carga de trabalho:a rede ambiente do GKE é compatível com a Identidade da carga de trabalho padrão. Os pools de identidades de agente gerenciadas não são compatíveis com esta prévia.
Autenticação:a conexão entre o proxy de nó ambiente e o Secure Web Proxy ignora a verificação do certificado do servidor. A solicitação CONNECT inclui um token sem limites junto com o certificado do cliente.
Recriação de recursos em atualizações de configuração:as mudanças feitas em uma instância do Secure Web Proxy ou em uma configuração do PSC não são propagadas automaticamente. Se você atualizar a configuração do Secure Web Proxy ou do PSC, exclua e recrie o recurso GCPEgressPolicy e a instância do Secure Web Proxy para aplicar as mudanças.
Âncora de confiança da inspeção TLS:o GKE não injeta automaticamente o certificado de CA privada do Secure Web Proxy em contêineres de carga de trabalho. Se você usar a inspeção de TLS, instale manualmente o certificado de confiança nas imagens de contêiner.

Pré-requisitos

Antes de configurar o roteamento de saída, verifique se você tem o seguinte:

Um cluster do GKE com a rede ambiente ativada. Para instruções, consulte Preparar a rede ambiente do GKE.
Uma instância do Secure Web Proxy implantada com um serverTlsPolicy configurado com clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT no projetoCloud de Confiance by S3NS ou na VPC compartilhada.
Se o Secure Web Proxy estiver em uma rede VPC diferente do cluster do GKE:
- Um anexo de serviço do PSC criado para o Secure Web Proxy.
- Um endpoint do consumidor do PSC configurado na rede VPC do cluster do GKE.

Para concluir essas etapas, você precisa ter as seguintes funções:

Gateway de agente / Serviços de rede: networkservices.agentGateways.* (ou roles/networkservices.admin) para configurar recursos de gateway de agente.
Gerenciamento do PSC: compute.networkAttachments.list (ou roles/compute.networkAdmin) para gerenciar conexões do Private Service Connect.
Gerenciamento do GKE: roles/container.clusterAdmin para implantar recursos personalizados (GCPBackend, GCPEgressPolicy).

Configurar a confiança para a inspeção de TLS

Se a política de Secure Web Proxy usar a inspeção TLS para inspecionar o tráfego criptografado de saída, o proxy vai gerar certificados assinados pela autoridade certificadora (CA) privada para se passar por destinos externos.

O aplicativo de carga de trabalho precisa confiar no certificado de CA particular apresentado pelo Secure Web Proxy. Como o GKE não injeta esse certificado automaticamente, é necessário instalar o certificado de CA do SWP (âncora de confiança) no repositório de confiança do contêiner.

Para adicionar o certificado de CA à imagem do contêiner, inclua as seguintes linhas no Dockerfile:

COPY swp-ca-cert.pem /usr/local/share/ca-certificates/swp-ca-cert.crt
RUN update-ca-certificates

Definir o endpoint do gateway

A primeira etapa na configuração do roteamento de saída ambiente é criar um endpoint de gateway, que define o endpoint do Secure Web Proxy no cluster do GKE e informa a rede ambiente sobre a localização do proxy.

Para especificar o URI do seu anexo de serviço do Secure Web Proxy ou do Private Service Connect (PSC), crie um recurso personalizado GCPBackend no cluster do GKE:

Salve o seguinte manifesto como swp-backend.yaml:

Mesma VPC
```
apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
  name: swp-backend
  namespace: ambient-test
spec:
  serviceUris:
  - //networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/gateways/SWP_NAME
```
Substitua:
- ambient-test: o namespace registrado na rede ambiente.
- PROJECT_ID: o ID do projeto Cloud de Confiance by S3NS .
- REGION: a região em que o Secure Web Proxy ou o anexo de serviço do PSC está implantado.
- SWP_NAME: o nome do seu Secure Web Proxy.
Entre VPCs
```
apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
  name: swp-backend
  namespace: ambient-test
spec:
  serviceUris:
  - //compute.googleapis.com/projects/PROJECT_ID/regions/REGION/serviceAttachments/ATTACHMENT_NAME
```
Substitua:
- ambient-test: o namespace registrado na rede ambiente.
- PROJECT_ID: o ID do projeto Cloud de Confiance by S3NS .
- REGION: a região em que o Secure Web Proxy ou o anexo de serviço do PSC está implantado.
- ATTACHMENT_NAME: o nome do seu anexo de serviço do PSC, se o Secure Web Proxy estiver em uma rede VPC diferente.
Aplique o recurso GCPBackend:
```
kubectl apply -f swp-backend.yaml
```

Configurar o redirecionamento de tráfego de saída

Crie um recurso personalizado GCPEgressPolicy para encaminhar o tráfego de saída do namespace para o gateway do Secure Web Proxy. Isso fornece a sinalização necessária para que o proxy de nó ambiente estabeleça um túnel HTTP CONNECT com o Secure Web Proxy, o que é necessário para o roteamento de saída.

Salve o seguinte manifesto como swp-egress-policy.yaml:

apiVersion: networking.gke.io/v1
kind: GCPEgressPolicy
metadata:
  name: swp-egress-policy
  namespace: ambient-test
spec:
  to:
    excludeCIDRRanges:
    - "CLUSTER_CONTROL_PLANE_CIDR"
  proxyRef:
    group: networking.gke.io
    kind: GCPBackend
    name: swp-backend

Substitua:

ambient-test: o namespace registrado na rede ambiente.
CLUSTER_CONTROL_PLANE_CIDR: o intervalo CIDR para comunicações internas que precisam ignorar o Secure Web Proxy, como o intervalo de endereços do plano de controle do GKE ou sub-redes VPC internas.

Aplique o recurso GCPEgressPolicy:
```
kubectl apply -f swp-egress-policy.yaml
```
Depois que a política é aplicada, o tráfego de saída das cargas de trabalho no namespace é redirecionado para o Secure Web Proxy.

Solução de problemas

Use as orientações a seguir para diagnosticar e resolver problemas com o roteamento de saída ambiente:

O tráfego não está chegando ao Secure Web Proxy:
- Verifique se o recurso GCPBackend aponta para o URI correto do anexo de serviço do PSC.
- Verifique se o endpoint do PSC foi estabelecido e aceito na VPC do produtor.
- Verifique se excludeCIDRRanges em GCPEgressPolicy não está correspondendo ao tráfego de destino por engano.
Falhas na conexão mTLS:
- Verifique se o Secure Web Proxy está configurado para aceitar conexões do proxy de nó.
Erros de certificado de inspeção TLS:
- Se as solicitações do cliente falharem com erros de validação de certificado (como x509: certificate signed by unknown authority), verifique se o certificado de CA do Secure Web Proxy está instalado corretamente no repositório de certificados do sistema do contêiner de carga de trabalho.