Ativar clientes não SNI

Neste tópico, explicamos como ativar clientes não SNI para uso com a Apigee híbrida.

Como configurar um cliente não SNI

Nesta seção, explicamos como ativar o suporte para clientes que não são SNI (Indicação do nome do servidor) na Apigee híbrida.

A SNI define como um peer TLS (cliente) especifica o nome do host a que pretende se conectar durante o handshake inicial de TLS. A SNI faz parte do TLS desde 2003. Antes da SNI, quando um peer TLS enviava um HELLO para iniciar o handshake, o peer receptor sempre respondia com as mesmas credenciais. A SNI foi introduzida para permitir que um único balanceador de carga ofereça suporte a vários nomes de host e conjuntos de credenciais distintos para o gerenciamento de conexões TLS. A SNI agora é usada pela grande maioria dos clientes TLS.

Há exceções. Por exemplo, o balanceador de carga do Google Cloud usará um handshake não SNI para se conectar aos back-ends.

Se você quiser configurar o Apigee híbrido para processar handshakes TLS que não usam SNI, seja porque o Apigee híbrido é um back-end para um Cloud Load Balancer do Google ou porque o Apigee híbrido precisa oferecer suporte a algum outro cliente não SNI, siga as etapas descritas abaixo. A negociação não SNI vai funcionar como um substituto. A Apigee híbrida vai usá-la para qualquer cliente que não use SNI.

1. Crie um recurso ApigeeRoute. Verifique se 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

   Em que:

   • ROUTE_NAME é o nome que você atribui ao recurso personalizado (CR).
   • CREDENTIAL_NAME é o nome de um secret do Kubernetes implantado no cluster que contém as credenciais TLS do seu host virtual. Para encontrar o nome da credencial, use o seguinte comando kubectl:

     kubectl -n APIGEE_NAMESPACE get ApigeeRoutes -o=yaml | grep credentialName

   • hostnames precisa ser definido como o caractere curinga "*".
2. Abra o arquivo de substituição e faça a alteração descrita na próxima etapa.
3. Para cada grupo de ambiente, adicione o nome do ApigeeRoute à propriedade additionalGateways. Exemplo:

   virtualhosts:
     - name: default
       sslCertPath: ./certs/fullchain.pem
       sslKeyPath: ./certs/privkey.pem
       additionalGateways: ["ROUTE_NAME"]

4. Salve o arquivo CRD. 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 você tiver definido a variável de ambiente $ENV_GROUP no shell, poderá usá-la nos seguintes comandos:

   helm upgrade $ENV_GROUP apigee-virtualhost/ \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     --set envgroup=$ENV_GROUP \
     -f OVERRIDES_FILE.yaml
   

Observações sobre uso

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

  Como a entrada está no nível do cluster para uma determinada porta (443) e só pode haver um par de chaves/certificados para o CRD do ApigeeRoute, todas as organizações precisam compartilhar o mesmo par de chaves/certificados.

• O que acontece quando o cluster tem mais de um grupo de ambientes? Ele funcionará se os hosts virtuais compartilharem o mesmo par de chave/certificado?

  Todos os nomes de host em todos os grupos de ambiente precisam usar o mesmo par de chave/certificado.

• Por que estamos criando um ApigeeRoute em vez do Gateway?

  O ApigeeRoutes pode ser validado pela Apigee. No entanto, o Gateway (CRD do Istio) não pode. Tecnicamente, até mesmo o Gateway pode funcionar, mas podemos evitar possíveis erros de configuração (por meio de um webhook de validação).

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

  Se a instância do Apigee estiver exposta por um balanceador de carga do Google, ele vai oferecer suporte a clientes não SNI conforme explicado na documentação do Load Balancing. Caso contrário, se você tiver exposto uma instância da Apigee por um endpoint interno do PSC ou uma VPC, por padrão, a instância da Apigee vai ser compatível com clientes não SNI.