Habilitar clientes que no son de la SNI

En este tema se explica cómo habilitar clientes que no usan 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.

SNI define cómo especificará un peer TLS (cliente) el nombre de host al que quiere conectarse durante el handshake TLS inicial. SNI forma parte de TLS desde el 2003. Antes de SNI, cuando un peer de TLS enviaba un HELLO para iniciar el handshake, el peer receptor siempre respondía con las mismas credenciales. SNI se introdujo para permitir que un único balanceador de carga admita varios nombres de host y conjuntos de credenciales distintos para la gestión de conexiones TLS. La SNI ahora la usa la gran mayoría de los clientes de TLS.

Hay excepciones. Por ejemplo, el balanceador de carga de Google Cloud usará un handshake sin SNI para conectarse a los backends.

Si quieres configurar tu Apigee hybrid para que pueda gestionar las negociaciones de TLS que no usen SNI, ya sea porque tu Apigee hybrid es un backend de un balanceador de carga de Google Cloud o porque tu Apigee hybrid debe admitir otro cliente que no sea SNI, debes seguir los pasos que se describen a continuación. La negociación sin SNI actuará como alternativa. Apigee Hybrid la usará para cualquier cliente que no use SNI.

  1. Crea un recurso 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 siguiente paso.
  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.