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. Um cliente não SNI usa a porta 443 e é necessário se quiser integrar instâncias de tempo de execução híbridas com o Google Cloud Load Balancing ou para clientes que não suportam SNI.
  1. Crie uma definição de recurso personalizado (CRD) 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? Vai funcionar 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.