Habilita clientes que no sean SNI

En este tema, se explica cómo habilitar clientes sin SNI para usar 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.

La SNI define cómo un par de TLS (cliente) especificará el nombre de host al que pretende conectarse durante el protocolo de enlace TLS inicial. La SNI forma parte de TLS desde 2003. Antes de la SNI, cuando un par de TLS enviaba un mensaje de HELLO para iniciar el protocolo de enlace, el par receptor siempre respondía con las mismas credenciales. Se introdujo SNI para permitir que un solo balanceador de cargas admita varios nombres de host y conjuntos de credenciales distintos para la administració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 cargas de Google Cloud usará un handshake sin SNI para conectarse a los backends.

Si deseas configurar tu Apigee hybrid para que pueda controlar los handshake de TLS que no usan SNI, ya sea porque tu Apigee hybrid es un backend para un Cloud Load Balancer de Google o porque tu Apigee hybrid debe admitir algún 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

    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 admite clientes que no son SNI, como se explica en la documentación del balanceo de cargas. De lo contrario, si expusiste una instancia de Apigee a través de un extremo de PSC interno o una VPC, de forma predeterminada, la instancia de Apigee admite clientes que no son SNI.