Abilitare i client non SNI

Questo argomento spiega come attivare i client non SNI per l'utilizzo con Apigee Hybrid.

Come configurare un client non SNI

Questa sezione spiega come attivare il supporto per i client non SNI (Server Name Indication) in Apigee Hybrid.

SNI definisce il modo in cui un peer TLS (client) specifica il nome host a cui intende connettersi durante l'handshake TLS iniziale. SNI fa parte di TLS dal 2003. Prima di SNI, quando un peer TLS inviava un HELLO per iniziare l'handshake, il peer ricevente rispondeva sempre con le stesse credenziali. SNI è stato introdotto per consentire a un singolo bilanciatore del carico di supportare più nomi host e set di credenziali distinti per la gestione delle connessioni TLS. SNI viene ora utilizzato dalla stragrande maggioranza dei client TLS.

Esistono delle eccezioni. Ad esempio, il bilanciatore del carico Google Cloud utilizzerà un handshake non SNI per connettersi ai backend.

Se vuoi configurare Apigee Hybrid in modo che possa gestire handshake TLS che non utilizzano SNI, perché Apigee Hybrid è un backend di un bilanciatore del carico Google Cloud o perché Apigee Hybrid deve supportare un altro client non SNI, segui i passaggi descritti di seguito. La negoziazione non SNI fungerà da fallback. Apigee Hybrid la utilizzerà per qualsiasi client che non utilizza SNI.

  1. Crea una risorsa ApigeeRoute. Assicurati che enableNonSniClient sia impostato su 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

    Dove:

    • ROUTE_NAME è il nome che assegni alla risorsa personalizzata (CR).
    • CREDENTIAL_NAME è il nome di un secret Kubernetes di cui è stato eseguito il deployment nel cluster che contiene le credenziali TLS per il tuo virtual host. Puoi trovare il nome della credenziale con il seguente comando kubectl:
      kubectl -n APIGEE_NAMESPACE get ApigeeRoutes -o=yaml | grep credentialName
    • hostnames deve essere impostato sul carattere jolly "*".
  2. Apri il file di override e apporta la modifica descritta nel passaggio successivo.
  3. Per ogni gruppo di ambienti, aggiungi il nome ApigeeRoute alla proprietà additionalGateways. Ad esempio:
    virtualhosts:
      - name: default
        sslCertPath: ./certs/fullchain.pem
        sslKeyPath: ./certs/privkey.pem
        additionalGateways: ["ROUTE_NAME"]
  4. Salva il file CRD. Ad esempio: ApigeeRoute.yaml
  5. Applica la CRD al cluster:
    kubectl apply -f ApigeeRoute.yaml -n APIGEE_NAMESPACE
  6. Applica la modifica a virtualhosts. Se hai impostato la variabile di ambiente $ENV_GROUP nella shell, puoi utilizzarla nei comandi seguenti:
    helm upgrade $ENV_GROUP apigee-virtualhost/ \
      --namespace APIGEE_NAMESPACE \
      --atomic \
      --set envgroup=$ENV_GROUP \
      -f OVERRIDES_FILE.yaml
    

Note sull'utilizzo

  • Cosa succede se il cluster ha più di un'organizzazione?

    Poiché l'ingresso è a livello di cluster per una determinata porta (443) e può esserci una sola coppia chiave/certificato per la CRD ApigeeRoute, tutte le organizzazioni devono condividere la stessa coppia chiave/certificato.

  • Cosa succede se il cluster ha più di un gruppo di ambienti? Funzionerà se gli host virtuali condividono la stessa coppia chiave/certificato?

    Tutti i nomi host in tutti i gruppi di ambienti devono utilizzare la stessa coppia chiave/certificato.

  • Perché creiamo un ApigeeRoute anziché un gateway?

    ApigeeRoutes può essere convalidato da Apigee, ma Gateway (la CRD Istio) non può. Tecnicamente, può funzionare anche Gateway, ma possiamo prevenire potenziali errori di configurazione (tramite un webhook di convalida).

  • Come faccio a configurare i client non SNI per Apigee?

    Se la tua istanza Apigee è esposta tramite un bilanciatore del carico Google, quest'ultimo supporta i client non SNI come spiegato nella documentazione di bilanciamento del carico. In caso contrario, se hai esposto un'istanza Apigee tramite un endpoint PSC interno o un VPC, per impostazione predefinita l'istanza Apigee supporta i client non SNI.