Como configurar um gateway NAT de saída

Com clusters do Anthos no VMware (GKE On-Prem), é possível configurar a conversão de endereços de rede de origem (SNAT) para que determinado tráfego de saída do cluster de usuário receba um endereço IP de origem previsível.

Neste documento, mostramos como configurar um gateway NAT de saída para um cluster de usuário.

Introdução

Às vezes, você tem pods em execução em um cluster de usuário que precisa enviar pacotes para componentes em execução na organização, mas fora do cluster. Projete esses componentes externos para que eles filtrem o tráfego de rede de entrada de acordo com um conjunto de endereços IP de origem conhecidos.

Veja alguns cenários:

  • Você tem um firewall em frente a um banco de dados que permite acesso apenas por endereço IP. E a equipe que gerencia o firewall do banco de dados é diferente da equipe que gerencia o cluster de usuário.

  • As cargas de trabalho no seu cluster de usuário precisam acessar uma API de terceiros pela Internet. Por motivos de segurança, o provedor da API autentica e autoriza o tráfego usando o endereço IP como a identidade.

Com um gateway NAT de saída, é possível ter um controle refinado sobre os endereços IP de origem usados para o tráfego de rede que sai de um cluster.

Preços

Não há cobrança pelo uso desse recurso durante a visualização.

Como funciona um gateway NAT de saída

Normalmente, quando um pod envia um pacote para fora do cluster, o pacote é convertido em SNAT com o endereço IP do nó em que o pod está sendo executado.

Quando um gateway NAT de saída está em vigor, é possível especificar que determinados pacotes de saída sejam enviados primeiro a um nó de gateway dedicado. A interface de rede no nó de gateway é configurada com dois endereços IP: o IP principal e um de origem de saída.

Quando um pacote selecionado para usar o gateway NAT de saída, ele sai do cluster do nó de gateway e é convertido SNAT com o endereço IP de origem de saída configurado na interface de rede.

O diagrama a seguir ilustra o fluxo de pacotes:

No diagrama anterior, é possível ver o fluxo de um pacote que é enviado do pod.

  1. Em um nó com o endereço IP 192.168.1.1, um pod com endereço IP 10.10.10.1 gera um pacote de saída.

  2. O pacote corresponde a uma regra de saída. Por isso, ele é encaminhado ao nó de gateway.

  3. O nó de gateway altera o endereço IP de origem para 192.168.1.100 e envia o pacote do cluster.

  4. O tráfego de retorno retorna ao nó de gateway com o destino 192.168.1.100.

  5. O nó de gateway usa o conntrack para modificar o endereço IP de destino para 10.10.10.1.

  6. O pacote é tratado como tráfego no cluster e encaminhado ao nó original e entregue de volta ao pod original.

Perfis

Este tópico se refere a dois perfis:

  • Administrador do cluster. Essa pessoa cria um cluster de usuário e especifica endereços IP flutuantes a serem usados pelo gateway de rede do Anthos.

  • Desenvolvedor. Essa pessoa executa cargas de trabalho no cluster de usuário e cria políticas de saída.

Ativar o gateway de rede do Anthos

Esta seção é destinada aos administradores de cluster.

Criar um novo cluster de usuário com o Anthos Network Gateway ativado.

No arquivo de configuração do cluster de usuário, defina enableDataplaneV2 e enableAnthosNetworkGateway como true.

enableDataplaneV2: true
...
enableAnthosNetworkGateway: true

Criar o cluster de usuário.

Especificar endereços IP flutuantes

Esta seção é destinada aos administradores de cluster.

Escolha um conjunto de endereços IP que você quer usar como endereços de origem de saída. Eles são chamados de endereços IP flutuantes, porque o Anthos Network Gateway os atribui, conforme necessário, às interfaces de rede dos nós escolhendo gateways de saída.

Os endereços IP flutuantes precisam estar na mesma sub-rede que os endereços IP do nó.

Seu conjunto de endereços IP flutuantes não pode se sobrepor ao conjunto de endereços IP especificados para seus nós.

Por exemplo, suponha que uma sub-rede tenha o intervalo de endereços 192.168.1.0/24. E suponha que você tenha escolhido usar 192.168.1.1 a 192.168.1.99 para nós. Em seguida, use 192.168.1.100 a 192.168.1.104 como endereços IP flutuantes.

Criar um objeto AnthosNetworkGateway

Esta seção é destinada aos administradores de cluster.

Veja um exemplo de um manifesto para um objeto AnthosNetworkGateway:

kind: AnthosNetworkGateway
apiVersion: networking.gke.io/v1alpha1
metadata:
  namespace: kube-system
  name: default
spec
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102
  - 192.168.1.103
  - 192.168.1.104

Substitua a matriz floatingIPs pelos endereços IP flutuantes e salve o manifesto em um arquivo chamado my-ang.yaml.

Crie o objeto AnthosNetworkGateway:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-ang.yaml

Exemplo de uma política de saída de NAT

Esta seção é destinada a desenvolvedores.

Aqui está um exemplo de um recurso personalizado EgressNatPolicy:

kind: EgressNATPolicy
metadata:
  name: alice-paul
spec:
  egress:
  - namespaceSelector:
      matchLabels:
        user: alice
    podSelector:
      matchLabels:
        role: frontend
  - namespaceSelector:
      matchLabels:
        user: paul
    podSelector:
      matchLabels:
        role: frontend
  destinationCIDRs:
  - 8.8.8.0/24
  egressSourceIP: 192.168.1.100

No manifesto anterior, vemos:

Um pod é um candidato para a saída NAT se atender a um dos seguintes itens:

  • O pod tem o rótulo role: frontend e o pod está em um namespace que tem o rótulo user: alice.

  • O pod tem o rótulo role: frontend e está em um namespace que tem o rótulo user: paul.

O tráfego de um pod candidato para um endereço no intervalo 8.8.8.0/24 é enviado para o gateway NAT de saída.

Criar um objeto EgressNATPolicy

Crie seu próprio manifesto EgressNATPolicy. Defina metadata.name como "my-policy". Salve o manifesto em um arquivo chamado my-policy.yaml.

Crie o objeto EgressNatPolicy:

kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f my-policy.yaml

Ver informações sobre sua política de saída de NAT

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get egressnatpolicy my-policy --output yaml

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get anthosnetworkgateway --namespace kube-system --output yaml

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe egressnatpolicy my-policy

Ordem de operações

A política de saída NAT é compatível com as APIs da política de rede. A política de rede é avaliada antes da política NAT de saída. Se uma política de rede diz para descartar um pacote, o pacote é descartado, independentemente da política de saída NAT.

Problemas conhecidos

Endereços egressSourceIP duplicados

Ao criar um objeto EgressNATGateway, você pode especificar um endereço egressSourceIP que já está em uso para outro objeto EgressNATPolicy. Isso causará conflitos de roteamento do tráfego de saída. Coordene com sua equipe de desenvolvimento para determinar quais endereços IP flutuantes estão disponíveis antes de especificar o endereço egressSourceIP.

Alterações nos recursos personalizados

As alterações nos recursos personalizados da EgresNATPolicy não são preenchidas para os recursos personalizados do Cilium.