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 em execução na rede de 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 centralizadas de segurança de saída, como filtragem de URL, listas de permissões de domínio e inspeção de 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) (para implantações entre VPCs).

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

Um pod de carga de trabalho inicia o tráfego de saída para um endpoint externo ou destino da Internet.
O proxy de nó de ambiente local da camada 4 intercepta a solicitação de saída no nó.
O proxy do nó estabelece um túnel HTTP CONNECT para o gateway de saída.
Se o Secure Web Proxy estiver na mesma rede VPC, o tráfego vai se conectar diretamente ao gateway. Se o Secure Web Proxy estiver em uma rede VPC diferente, o tráfego vai passar por um anexo de serviço do 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, confira as seguintes limitações no pré-lançamento:

Políticas de namespace: as políticas de roteamento de saída se aplicam apenas ao nível do namespace. Não é possível selecionar pods de forma granular usando seletores de rótulos.
A filtragem de nome de host requer 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 de ambiente do GKE é compatível com a Identidade da carga de trabalho padrão. Os pools de identidade de agente gerenciado não são compatíveis com este pré-lançamento.
Autenticação: a conexão entre o proxy de nó de ambiente e o Secure Web Proxy ignora a verificação do certificado do servidor. A solicitação CONNECT inclui um token ilimitado com o certificado do cliente.
Recriação de recursos em atualizações de configuração: as alterações feitas em uma instância atual do Secure Web Proxy ou na 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 de TLS: o GKE não injeta automaticamente o certificado de CA particular 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 do contêiner.

Pré-requisitos

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

Um cluster do GKE com a rede de ambiente ativada. Para instruções, consulte Preparar a rede de ambiente do GKE.
Uma instância implantada do Secure Web Proxy com um serverTlsPolicy configurado com clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT no seu 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 de consumidor do PSC configurado na rede VPC do cluster do GKE.

Para concluir essas etapas, você precisa ter os seguintes papéis:

Secure Web Proxy / Network Services: networkservices.gateways.* (ou roles/networkservices.admin) para configurar os recursos de gateway do Secure Web Proxy.
Gerenciamento do PSC (somente implantações entre VPCs): 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 do Secure Web Proxy usar a inspeção de TLS para inspecionar o tráfego de saída criptografado, o proxy vai gerar certificados assinados pela autoridade certificadora (CA) particular para personificar 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 para configurar o roteamento de saída do ambiente é criar um endpoint de gateway, que define o endpoint do Secure Web Proxy no cluster do GKE e informa à Rede Ambiente a localização do proxy.

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

Mesma VPC

Salve o seguinte manifesto como swp-backend.yaml:
```
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 inscrito na rede de ambiente.
- PROJECT_ID: o ID do projeto Cloud de Confiance by S3NS .
- REGION: a região em que o Secure Web Proxy está implantado.
- SWP_NAME: o nome do Secure Web Proxy.
Aplique o recurso GCPBackend:
```
kubectl apply -f swp-backend.yaml
```

Entre VPCs

Salve o seguinte manifesto como swp-backend.yaml:
```
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 inscrito na rede de ambiente.
- PROJECT_ID: o ID do projeto Cloud de Confiance by S3NS .
- REGION: a região em que o anexo de serviço do PSC está implantado.
- ATTACHMENT_NAME: o nome do 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 rotear 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 do nó de ambiente estabeleça um túnel HTTP CONNECT para o Secure Web Proxy, 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 inscrito 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 as 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 chega ao Secure Web Proxy:
- Para implantações na mesma VPC, verifique se o recurso GCPBackend aponta para o URI correto do gateway do Secure Web Proxy.
- Para implantações entre VPCs:
- 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 de maneira acidental.
Falhas de 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 de 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.