Nicht-SNI-Clients aktivieren

In diesem Thema wird erläutert, wie Sie Nicht-SNI-Clients für die Verwendung mit Apigee Hybrid aktivieren.

So konfigurieren Sie einen Nicht-SNI-Client

In diesem Abschnitt wird erläutert, wie Sie die Unterstützung für Nicht-SNI-Clients (Server Name Indication) in Apigee Hybrid aktivieren. Ein Nicht-SNI-Client verwendet Port 443 und ist erforderlich, wenn Sie Hybridlaufzeitinstanzen in Google Cloud Load Balancing einbinden möchten oder für Clients, die SNI nicht unterstützen.

1. Benutzerdefinierte ApigeeRoute-Ressourcendefinition erstellen (CRD). Achten Sie darauf, dass enableNonSniClient auf true gesetzt ist:

   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

   Dabei gilt:

   • ROUTE_NAME ist der Name, den Sie der benutzerdefinierten Ressource zuweisen.
   • CREDENTIAL_NAME ist der Name eines Kubernetes-Secrets, das auf dem Cluster bereitgestellt wird und TLS-Anmeldedaten für Ihren virtuellen Host enthält. Sie finden den Namen der Anmeldedaten mit dem folgenden kubectl-Befehl:

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

   • hostnames muss auf den Platzhalter „*” gesetzt werden.
2. Öffnen Sie die Überschreibungsdatei und nehmen Sie die im nächsten Schritt beschriebene Änderung vor.
3. Fügen Sie für jede Umgebungsgruppe den Namen ApigeeRoute in das Attribut additionalGateways ein. Beispiel:

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

4. Speichern Sie die CRD-Datei. Beispiel: ApigeeRoute.yaml.
5. Wenden Sie die CRD auf den Cluster an:

   kubectl apply -f ApigeeRoute.yaml -n APIGEE_NAMESPACE

6. Wenden Sie die Änderung auf virtualhosts an. Wenn Sie die Umgebungsvariable $ENV_GROUP in Ihrer Shell festgelegt haben, können Sie sie in den folgenden Befehlen verwenden:

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

Verwendungshinweise

• Was passiert, wenn der Cluster mehr als eine Organisation hat?

  Da sich das Ingress auf der Clusterebene für einen bestimmten Port (443) befindet und es nur ein Schlüssel-/Zertifikat-Paar für die CRRoute-CRD von Apigee gibt, müssen alle Organisationen dasselbe Schlüsselpaar haben.

• Was geschieht, wenn der Cluster mehr als eine Umgebungsgruppe hat? Funktioniert die VM, wenn die virtuellen Hosts dasselbe Schlüssel-/Zertifikatpaar verwenden?

  Alle Hostnamen in allen Umgebungsgruppen müssen dasselbe Schlüssel-/Zertifikatpaar verwenden.

• Warum erstellen wir statt eines Gateways eine ApigeeRoute?

  ApigeeRoutes können von Apigee validiert werden; das Gateway (die Istio-CRD) jedoch nicht. Technisch funktioniert sogar ein Gateway, aber mögliche Konfigurationsfehler können (durch einen Validierungs-Webhook) vermieden werden.

• Wie kann ich Nicht-SNI-Clients für Apigee konfigurieren?

  Wenn Ihre Apigee-Instanz über einen Google Load Balancer bereitgestellt wird, unterstützt der Load Balancer Nicht-SNI-Clients, wie in der Load Balancing-Dokumentation beschrieben. Wenn Sie eine Apigee-Instanz über einen internen PSC-Endpunkt oder ein VPC freigegeben haben, unterstützt die Apigee-Instanz standardmäßig Nicht-SNI-Clients.