Habilita clientes que no sean SNI

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

Configura un cliente que no sea SNI

En esta sección, se explica cómo habilitar la asistencia para clientes que no sean SNI (Indicador del nombre del servidor) en Apigee Hybrid. Un cliente sin SNI usa el puerto 443 y es obligatorio si deseas integrar instancias de entorno de ejecución híbrido con Google Cloud Load Balancing o clientes sin SNI.

1. Crea una definición de recurso personalizado (CRD) de ApigeeRouter. 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

   Aquí:

   • ROUTE_NAME es el nombre que asignas al recurso personalizado (CR).
   • CREDENTIAL_NAME es el nombre de un Secret de Kubernetes implementado en el clúster que contiene credenciales TLS para 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 se debe establecer en el comodín "*".
2. Abre tu archivo de anulación y realiza el cambio que se describe en el siguiente paso.
3. Para cada grupo de entornos, agrega 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 configuraste 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é sucede si el clúster tiene más de una organización?

  Dado que la entrada está a nivel del clúster para un puerto determinado (443), y solo puede haber un par clave-valor para la CRD de ApigeeRouter, todas las organizaciones deben compartir el mismo par de clave/certificado.

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

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

• ¿Por qué crearemos una ApigeeRouter en lugar de Gateway?

  ApigeeRoutes puede validar las rutas; sin embargo, la puerta de enlace (el CRD de Istio) no lo puede hacer. Técnicamente, incluso la puerta de enlace puede funcionar, pero podemos evitar posibles errores de configuración (a través de 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 cargas de Google, este balanceador admite clientes que no son SNI, como se explica en la documentación del balanceador de cargas. De lo contrario, si expusiste una instancia de Apigee a través de un extremo o una VPC de PSC interna, de forma predeterminada, la instancia de Apigee admite clientes que no son SNI.