Ative clientes não SNI

Este tópico explica como ativar clientes não SNI para utilização com o Apigee hybrid.

Como configurar um cliente não SNI

Esta secção explica como ativar o suporte para clientes não SNI (Indicação do nome do servidor) no Apigee hybrid.

O SNI define como um par TLS (cliente) especifica o nome do anfitrião ao qual pretende estabelecer ligação durante o handshake TLS inicial. O SNI faz parte do TLS desde 2003. Antes do SNI, quando um par TLS enviava um HELLO para iniciar o handshake, o par de receção respondia sempre com as mesmas credenciais. O SNI foi introduzido para permitir que um único balanceador de carga suportasse vários nomes de anfitrião distintos e conjuntos de credenciais para a gestão de ligações TLS. O SNI é agora usado pela grande maioria dos clientes TLS.

Existem exceções. Por exemplo, o balanceador de carga do Google Cloud usa uma negociação não SNI para estabelecer ligação aos back-ends.

Se quiser configurar o Apigee hybrid para poder processar negociações de TLS que não usam SNI, quer porque o Apigee hybrid é um back-end para um Cloud Load Balancer da Google, quer porque o Apigee hybrid tem de suportar algum outro cliente não SNI, deve seguir os passos descritos abaixo. A negociação não SNI vai atuar como alternativa. O Apigee hybrid vai usá-la para qualquer cliente que não use SNI.

  1. Crie um recurso ApigeeRoute. Certifique-se de que enableNonSniClient está definido como true: 
    apiVersion: apigee.cloud.google.com/v1alpha1
kind: ApigeeRoute
metadata:
  name: ROUTE_NAME
  namespace: APIGEE_NAMESPACE
spec:
  hostnames:
  - "*"
  ports:
  - number: 443
    protocol: HTTPS
    tls:
      credentialName: CREDENTIAL_NAME
      mode: SIMPLE
      #optional
      minProtocolVersion: TLS_AUTO
  selector:
    app: apigee-ingressgateway
  enableNonSniClient: true

    Onde:

    • ROUTE_NAME é o nome que atribui ao recurso personalizado (CR).
    • CREDENTIAL_NAME é o nome de um segredo do Kubernetes implementado no cluster que contém credenciais TLS para o seu anfitrião virtual. Pode encontrar o nome da credencial com o seguinte comando kubectl: 
      kubectl -n APIGEE_NAMESPACE get ApigeeRoutes -o=yaml | grep credentialName
    • hostnames tem de ser definido como o caráter universal "*".
  2. Abra o ficheiro de substituições e faça a alteração descrita no passo seguinte.
  3. Para cada grupo de ambientes, adicione o nome ApigeeRoute à propriedade additionalGateways. Por exemplo: 
    virtualhosts:
  - name: default
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    additionalGateways: ["ROUTE_NAME"]
  4. Guarde o ficheiro CRD. Por exemplo: ApigeeRoute.yaml
  5. Aplique o CRD ao cluster: 
    kubectl apply -f ApigeeRoute.yaml -n APIGEE_NAMESPACE
  6. Aplique a alteração a virtualhosts. Se tiver definido a variável de ambiente $ENV_GROUP na sua shell, pode usá-la nos seguintes comandos: 
    helm upgrade $ENV_GROUP apigee-virtualhost/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=$ENV_GROUP \
  -f OVERRIDES_FILE.yaml

Notas de utilização

  • O que acontece se o cluster tiver mais do que uma organização?

    Uma vez que a entrada está ao nível do cluster para uma determinada porta (443) e só pode haver um par de chave/certificado para o CRD ApigeeRoute, todas as organizações têm de partilhar o mesmo par de chave/certificado.

  • O que acontece se o cluster tiver mais do que um grupo de ambientes? Funciona se os anfitriões virtuais partilharem o mesmo par de chave/certificado?

    Todos os nomes de anfitrião em todos os grupos de ambientes têm de usar o mesmo par de chave/certificado.

  • Por que motivo estamos a criar um ApigeeRoute em vez de um Gateway?

    As ApigeeRoutes podem ser validadas pelo Apigee. No entanto, não é possível validar o Gateway (o CRD do Istio). Tecnicamente, até o Gateway pode funcionar, mas podemos evitar potenciais erros de configuração (através de um webhook de validação).

  • Como posso configurar clientes não SNI para o Apigee?

    Se a sua instância do Apigee estiver exposta através de um Google Load Balancer, o Load Balancer suporta clientes não SNI, conforme explicado na documentação de balanceamento de carga. Caso contrário, se tiver exposto uma instância do Apigee através de um ponto final do PSC interno ou da VPC, por predefinição, a instância do Apigee suporta clientes não SNI.