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. Um cliente não SNI usa a porta 443 e é necessário se você quiser integrar instâncias de ambiente de execução híbrida com o Cloud Load Balancing do Google ou para clientes que não aceitam SNI.

1. Crie uma definição de recurso personalizada (CRD, na sigla em inglês) do 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 da Apigee for exposta por um balanceador de carga do Google, ele será compatível com clientes que não são SNI, conforme explicado na documentação do balanceamento de carga. Caso contrário, se você tiver exposto uma instância da Apigee por um endpoint do PSC interno ou VPC, a instância da Apigee vai oferecer suporte a clientes não SNI por padrão.