Habilitar clientes que no son de la SNI

En este tema se explica cómo habilitar clientes que no sean SNI para usarlos con Apigee hybrid.

Cómo configurar un cliente que no es de la SNI

En esta sección se explica cómo habilitar la compatibilidad con clientes que no usan SNI (indicador del nombre del servidor) en Apigee hybrid. Un cliente que no usa SNI utiliza el puerto 443 y es necesario si quieres integrar instancias de tiempo de ejecución híbridas con Cloud Load Balancing de Google o para clientes que no admiten SNI.

1. Crea una definición de recurso personalizado (CRD) de ApigeeRoute. Asegúrate de que enableNonSniClient esté configurado 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

   Donde:

   • ROUTE_NAME es el nombre que le asignas al recurso personalizado (CR).
   • CREDENTIAL_NAME es el nombre de un secreto de Kubernetes implementado en el clúster que contiene las credenciales TLS de tu host virtual. Puedes encontrar el nombre de la credencial con el siguiente comando kubectl:

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

   • hostnames debe tener el comodín "*".
2. Abre el archivo de anulaciones y haz el cambio que se describe en el paso siguiente.
3. En cada grupo de entornos, añade el nombre de ApigeeRoute a la propiedad additionalGateways. Por ejemplo:

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

4. Guarda el archivo CRD. Por ejemplo: ApigeeRoute.yaml
5. Aplica el CRD al clúster:

   kubectl apply -f ApigeeRoute.yaml -n APIGEE_NAMESPACE

6. Aplica el cambio a virtualhosts. Si has definido la variable de entorno $ENV_GROUP en tu shell, puedes usarla en los siguientes comandos:

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

Notas de uso

• ¿Qué ocurre si el clúster tiene más de una organización?

  Como el acceso se encuentra a nivel de clúster para un puerto determinado (443) y solo puede haber un par de claves y certificados para el CRD de ApigeeRoute, todas las organizaciones deben compartir el mismo par de claves y certificados.

• ¿Qué ocurre si el clúster tiene más de un grupo de entornos? ¿Funcionará si los hosts virtuales comparten el mismo par de claves y certificados?

  Todos los nombres de host de todos los grupos de entornos deben usar el mismo par de clave y certificado.

• ¿Por qué creamos un ApigeeRoute en lugar de un Gateway?

  Apigee puede validar ApigeeRoutes. Sin embargo, Gateway (el CRD de Istio) no puede hacerlo. Técnicamente, incluso Gateway puede funcionar, pero podemos evitar posibles errores de configuración (mediante un webhook de validación).

• ¿Cómo puedo configurar clientes que no sean SNI para Apigee?

  Si tu instancia de Apigee está expuesta a través de un balanceador de carga de Google, este admite clientes que no usan SNI, tal como se explica en la documentación de Load Balancing. De lo contrario, si has expuesto una instancia de Apigee a través de un endpoint PSC interno o una VPC, la instancia de Apigee admitirá de forma predeterminada clientes que no sean SNI.