Server-Port zu einem Host-Header hinzufügen

Um der Client-Anfrage einen Server-Port hinzuzufügen, bevor die Anfrage an Ihre Back-End-Anwendung weitergeleitet wird, konfigurieren Sie einen Proxy für externe Dienste in einer Server-Snippet-Anmerkung oder als ibm-k8s-controller-config ConfigMap Feld.

Eingehende Anforderungen mit einer privaten ALB weiterleiten

Zum Weiterleiten eingehender Anforderungen an Ihre Apps mit einer privaten ALB geben Sie die Klassenannotation private-iks-k8s-nginx in der Ingress-Ressource an. Private ALBs sind für die Verwendung von Ressourcen mit dieser Klasse konfiguriert.

kubernetes.io/ingress.class: "private-iks-k8s-nginx"

Apps mit App ID authentifizieren

Konfigurieren Sie Ingress mit IBM Cloud App ID um die Authentifizierung für Ihre Anwendungen zu erzwingen, indem Sie bestimmte Kubernetes Ingress-Felder ändern. Weitere Informationen finden Sie unter Hinzufügen der Authentifizierung App ID zu Anwendungen.

Maximale Größe des Clientanforderungshauptteils festlegen

Um die maximale Größe des Body festzulegen, den der Client als Teil einer Anfrage senden kann, verwenden Sie die folgende Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/proxy-body-size: 8m

Pufferung von Clientantwortdaten aktivieren und inaktivieren

Sie können die Speicherung von Antwortdaten auf dem ALB deaktivieren oder aktivieren, während die Daten an den Client gesendet werden. Die Einstellung ist standardmäßig inaktiviert. Legen Sie zum Aktivieren die Annotationfür die Ingress-Ressource fest.

nginx.ingress.kubernetes.io/proxy-buffering: "on"

Anpassen der Zeitüberschreitungen für Verbindungsaufbau und Lesevorgänge

Verwenden Sie die folgenden Anmerkungen, um festzulegen, wie lange die ALB darauf wartet, eine Verbindung zur Back-End-App herzustellen und aus der Back-End-App zu lesen, bevor die Back-End-App als nicht verfügbar betrachtet wird.

nginx.ingress.kubernetes.io/proxy-connect-timeout: 62

nginx.ingress.kubernetes.io/proxy-read-timeout: 62

Fehleraktionen anpassen

Um benutzerdefinierte Aktionen anzugeben, die der ALB für bestimmte HTTP Fehler durchführen kann, setzen Sie das Feld custom-http-errors.

Ändern der Standard-Ports HTTP und HTTPS

Um die Standardports für HTTP (Port 80) und HTTPS (Port 443) Netzwerkverkehr zu ändern, ändern Sie jeden ALB-Dienst mit den folgenden Feldern Kubernetes Ingress ibm-ingress-deploy-config ConfigMap.

Beispielfeldeinstellung.

httpPort=8080
httpsPort=8443

Anforderungsheader anpassen

Um einer Client-Anfrage Header-Informationen hinzuzufügen, bevor die Anfrage an Ihre Backend-Anwendung weitergeleitet wird, verwenden Sie das folgende Feld „ Kubernetes “ in der ConfigMap „ ibm-k8s-controller-config “

proxy-set-headers: "ingress-nginx/custom-headers"

Informationen zu den Anforderungen an die ConfigMapcustom-headers finden Sie in diesem Beispiel.

Antwortheader anpassen

Um einer Clientantwort Headerinformationen hinzuzufügen, bevor sie an den Client gesendet wird, verwenden Sie die folgende Annotation.

nginx.ingress.kubernetes.io/configuration-snippet: |
    more_set_headers "Request-Id: $req_id";

Hinzufügen von Pfaddfinitionen zu externen Diensten

Um Pfaddefinitionen zu externen Diensten hinzuzufügen, z. B. zu Diensten, die auf IBM Cloud gehostet werden, konfigurieren Sie einen Proxy zu externen Diensten in einem Location Snippet. Oder ersetzen Sie den Proxy durch eine permanente Umleitung zu externen Services.

Unsichere Anforderungen umleiten

Standardmäßig werden unsichere HTTP Client-Anfragen auf HTTPS umgeleitet. Verwenden Sie das folgende Feld und die folgende Anmerkung, um diese Einstellung zu inaktivieren.

• ibm-k8s-controller-config Feld ConfigMap

  ssl-redirect: "false"
  

• Annotationfür Ingress-Ressource:

  nginx.ingress.kubernetes.io/ssl-redirect: "false"
  

HTTP aktivieren und deaktivieren Strict Transport Security

Browser so einrichten, dass Zugriffe auf die Domäne nur unter Verwendung von HTTPS erfolgen. Diese Option wird standardmäßig aktiviert.

• Informationen zur Festlegung der maximalen Gültigkeitsdauer und zur Granularität von Subdomains finden Sie in diesem Blogbeitrag unter NGINX.
• Um die Funktion zu deaktivieren, legen Sie das Feld configmap ibm-k8s-controller-config fest.

  hsts: false
  

Maximale Anzahl von Keepalive-Anforderungen festlegen

Um die maximale Anzahl der Anfragen festzulegen, die über eine Keepalive-Verbindung bedient werden können, verwenden Sie das folgende Feld Kubernetes ibm-k8s-controller-config configmap.

keep-alive-requests: 100

Der Standardwert für keep-alive-requests im Kubernetes-Ingress ist 100, was deutlich unter dem Standardwert von 4096 im IBM Cloud Kubernetes Service-Ingress liegt. Wenn Sie Ihre Ingress-Konfiguration von IBM Cloud Kubernetes Service Ingress nach Kubernetes Ingress migriert haben, müssen Sie keep-alive-requests unter Umständen ändern, um vorhandene Leistungstests zu bestehen.

Maximales Zeitlimit für Keepalive-Anforderungen festlegen

Um die maximale Zeit festzulegen, die eine Keepalive-Verbindung zwischen dem Client und dem ALB-Proxy-Server offen bleibt, verwenden Sie das folgende Kubernetes ibm-k8s-controller-config configmap-Feld.

keep-alive: 60

Maximale Anzahl großer Client-Header-Puffer festlegen

Um die maximale Anzahl und Größe von Puffern festzulegen, die große Client-Request-Header lesen, verwenden Sie das folgende Kubernetes ibm-k8s-controller-config configmap-Feld.

large-client-header-buffers: 4 8k

Übereinstimmung der ALB mit dem Anforderungs-URI ändern

Um die Art und Weise zu ändern, wie die ALB den Anfrage-URI mit dem App-Pfad abgleicht, verwenden Sie die folgende Kubernetes Ingress Resource Annotation.

nginx.ingress.kubernetes.io/use-regex: "true"

Weitere Informationen finden Sie in diesem Blog.

Angepasste Positionsblockkonfigurationen hinzufügen

Um eine benutzerdefinierte Standortblockkonfiguration für einen Dienst hinzuzufügen, verwenden Sie die folgende Kubernetes Ingress-Ressourcenanmerkung.

nginx.ingress.kubernetes.io/configuration-snippet: |
    more_set_headers "Request-Id: $req_id";

Gegenseitige Authentifizierung konfigurieren

Um die gegenseitige Authentifizierung für den ALB zu konfigurieren, verwenden Sie die folgenden Kubernetes Ingress-Ressourcen-Anmerkungen. Beachten Sie, dass die gegenseitige Authentifizierung nicht auf angepasste Ports angewendet werden kann und auf den HTTPS-Port angewendet werden muss.

nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
nginx.ingress.kubernetes.io/auth-tls-error-page: "http://www.mysite.com/error-cert.html"
nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"

Größe des Proxy-Puffers konfigurieren

Um die Größe des Proxy-Puffers zu konfigurieren, der den ersten Teil der Antwort liest, verwenden Sie die folgende Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/proxy-buffer-size: "8k"

Proxy-Puffernummern konfigurieren

Um die Anzahl der Proxy-Puffer für den ALB zu konfigurieren, verwenden Sie die folgende Kubernetes Ingress Resource Annotation.

nginx.ingress.kubernetes.io/proxy-buffers-number: "4"

Größe des belegten Proxy-Puffers konfigurieren

Um die Größe der Proxy-Puffer zu konfigurieren, die belegt sein können, verwenden Sie ein Positionssnippet. Weitere Informationen finden Sie in der Dokumentation zu NGINX.

Konfigurieren, wann eine ALB eine Anforderung übergeben kann

Um festzulegen, wann der ALB eine Anfrage an den nächsten Upstream-Server weiterleiten kann, verwenden Sie die folgenden Felder Kubernetes Ingress.

• Globale Einstellung: ibm-k8s-controller-config ConfigMap Felder:

  retry-non-idempotent: true
  proxy-next-upstream: error timeout http_500
  

• Einstellung pro Ressource: Ingress-Ressource Annotationen:

  nginx.ingress.kubernetes.io/proxy-next-upstream: http_500
  nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: 50
  nginx.ingress.kubernetes.io/proxy-next-upstream-tries: 3
  

Durchsatzbegrenzung

Um die Anforderungsverarbeitungsrate und die Anzahl der Verbindungen pro definiertem Schlüssel für Services zu begrenzen, verwenden Sie die Ingress-Ressource Annotationen für Ratenbegrenzung.

Antwortheader entfernen

Sie können Header-Informationen, die in der Client-Antwort enthalten sind, aus der Backend-App entfernen, bevor die Antwort an den Client gesendet wird. Konfigurieren Sie die Entfernung des Antwort-Headers in einem Standort-Snippet, oder verwenden Sie das Feld proxy_hide_header als Konfigurations-Snippet in der ibm-k8s-controller-config ConfigMap.

Pfade neu schreiben

Um eingehenden Netzwerkverkehr auf einem ALB-Domänenpfad an einen anderen Pfad weiterzuleiten, den Ihre Back-End-App abhört, verwenden Sie die folgende Kubernetes Ingress-Ressourcenanmerkung.

nginx.ingress.kubernetes.io/rewrite-target: /newpath

Serverblockkonfigurationen anpassen

Um eine benutzerdefinierte Serverblockkonfiguration hinzuzufügen, verwenden Sie die folgende Kubernetes Ingress-Ressourcenanmerkung.

nginx.ingress.kubernetes.io/server-snippet: |
    location = /health {
    return 200 'Healthy';
    add_header Content-Type text/plain;
    }

Eingehenden Netzverkehr weiterleiten

Um eingehenden Netzwerkverkehr mit Hilfe eines Sticky-Cookies immer an denselben Upstream-Server zu leiten, verwenden Sie die folgenden Kubernetes Ingress-Ressourcen-Anmerkungen.

nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "cookie_name1"
nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
nginx.ingress.kubernetes.io/configuration-snippet: |
  more_set_headers "Set-Cookie: HttpOnly";

Der Kubernetes Ingress-Controller fügt den permanenten Cookies standardmäßig die Attribute Secure und HttpOnly hinzu, die nicht geändert werden können.

Ermöglichung der Verschlüsselung des Datenverkehrs durch die Dienste von SSL

Um die Unterstützung von SSL Services für die Verschlüsselung des Datenverkehrs zu Ihren Upstream-Anwendungen zu ermöglichen, die HTTPS erfordern, verwenden Sie die Kubernetes Ingress Resource Backend Protocol Annotation und die Backend Certificate Authentication Annotations.

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
nginx.ingress.kubernetes.io/proxy-ssl-secret: app1-ssl-secret
nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: 5
nginx.ingress.kubernetes.io/proxy-ssl-name: proxy-ssl-name=mydomain.com
nginx.ingress.kubernetes.io/proxy-ssl-verify: true

Zugriff auf Anwendungen mit nicht standardmäßigen Anschlüssen TCP

Führen Sie die folgenden Schritte aus, um über einen nicht standardmäßigen Anschluss TCP auf eine Anwendung zuzugreifen.

1. Erstellen Sie eine tcp-services-ConfigMap, um Ihren TCP-Port anzugeben (z. B. folgende Beispielports). Informationen zu den Anforderungen des ConfigMap,tcp-services finden Sie in diesem Blog.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: tcp-services
     namespace: kube-system
   data:
     9000: "<namespace>/<service>:8080"
   

2. Erstellen Sie die Konfigurationszuordnung im Namensbereich kube-system.

   kubectl apply -f tcp-services.yaml -n kube-system
   

3. Geben Sie die tcp-services-Konfigurationszuordnung als Feld in der ibm-ingress-deploy-config-Konfigurationszuordnung an.

   "tcpServicesConfig":"kube-system/tcp-services"
   

4. Ändern Sie jeden ALB-Service, um die Ports hinzuzufügen.

Maximale Anzahl vorgeschalteter Keepalive-Anforderungen festlegen

Um die maximale Anzahl von Anfragen festzulegen, die über eine Keepalive-Verbindung bedient werden können, verwenden Sie das folgende Feld Kubernetes ibm-k8s-controller-config ConfigMap.

upstream-keepalive-requests: 32

Maximales Upstream-Keepalive-Zeitlimit festlegen

Um die maximale Zeit festzulegen, die eine Keepalive-Verbindung zwischen dem ALB-Proxy-Server und dem Upstream-Server Ihrer Anwendung offen bleibt, verwenden Sie das folgende Kubernetes ibm-k8s-controller-config configmap-Feld.

upstream-keepalive-timeout: 32

ALB-Bereitstellung anpassen

Passen Sie durch das Erstellen einer Konfigurationszuordnung des Typs ibm-ingress-deploy-config die Bereitstellung für ALBs an, die ein Kubernetes Ingress-Image ausführen.

1. Rufen Sie die Namen der Services ab, die die einzelnen ALBs zugänglich machen.

   • Klassische Cluster:

       kubectl get svc -n kube-system | grep alb
       ```
   * VPC-Cluster: Suchen Sie in der Ausgabe nach einem Servicenamen, der zum Beispiel wie folgt formatiert ist: `public-crc204dl7w0qf6n6sp7tug`.
   
   ```sh {: pre}
       kubectl get svc -n kube-system | grep LoadBalancer
       ```
   

Ingress-Klasse anpassen

Eine Ingress-Klasse ordnet einen Klassennamen einem Ingress-Controller-Typ zu. Mit der Ressource IngressClass können Sie Ingress-Klassen anpassen.

App ID-Authentifizierung zu Apps hinzufügen

Richten Sie die Authentifizierung für Ihre Apps ein, indem Sie Ingress mit IBM Cloud App ID konfigurieren.

1. Wählen Sie eine vorhandene Instanz aus oder erstellen Sie eine neue App ID-Instanz.

   Eine App ID-Instanz kann nur in einem Namensbereich in Ihrem Cluster verwendet werden. Wenn Sie App ID für Ingress-Ressourcen in mehreren Namensbereichen konfigurieren möchten, wiederholen Sie die Schritte in diesem Abschnitt, um eine eindeutige App ID-Instanz für die Ingress-Ressourcen in jedem Namensbereich anzugeben.

   • Wenn Sie eine vorhandene Instanz verwenden möchten, stellen Sie sicher, dass der Serviceinstanzname nur Kleinbuchstaben alphanumerische Zeichen enthält und die Länge 25 Zeichen nicht überschreitet. Wenn Sie den Namen ändern möchten, wählen Sie Service umbenennen im Menü "Weitere Optionen" auf der Detailseite der Serviceinstanz aus.
   • Gehen Sie wie folgt vor, um eine neue App ID-Instanz bereitzustellen:
     1. Ersetzen Sie Servicename durch Ihren eindeutigen Namen für die Serviceinstanz. Der Name der Service-Instanz darf nur aus alphanumerischen Kleinbuchstaben bestehen und darf nicht länger als 25 Zeichen sein.
     2. Wählen Sie die Region aus, in der Ihr Cluster implementiert ist.
     3. Klicken Sie auf Erstellen.

2. Fügen Sie Umleitungs-URLs für Ihre App hinzu. Eine Umleitungs-URL ist der Callback-Endpunkt Ihrer App. Um Phishing-Attacken zu verhindern, validiert die IBM Cloud App ID die Anforderungs-URL anhand der Zulassungsliste mit Umleitungs-URLs.

   1. Navigieren Sie in der App ID-Managementkonsole zu Authentifizierung verwalten.
   2. Stellen Sie sicher, dass Sie auf der Registerkarte Identitätsprovider einen Identitätsprovider ausgewählt haben. Wenn kein Identitätsanbieter ausgewählt ist, wird der Benutzer nicht authentifiziert, erhält jedoch ein Zugriffstoken für den anonymen Zugriff auf die App.
   3. Fügen Sie auf der Registerkarte Authentifizierungseinstellungen Umleitungs-URLs für Ihre App im Format https://<hostname>/oauth2-<App_ID_service_instance_name>/callback hinzu. Beachten Sie, dass alle Buchstaben im Serviceinstanznamen als Kleinbuchstaben angegeben werden müssen.

   Wenn Sie die Abmeldefunktion von IBM Cloud App ID verwenden, müssen Sie /sign_out im Format https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out an Ihre Domäne anhängen und diese URL in die Liste der Umleitungs-URLs eintragen. Wenn Sie eine benutzerdefinierte Abmeldeseite verwenden möchten, müssen Sie whitelist_domains in der ConfigMap für OAuth2-Proxy einstellen. Rufen Sie den Endpunkt https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out mit dem Abfrageparameter rd auf oder legen Sie den Header X-Auth-Request-Redirect mit Ihrer angepassten Abmeldeseite fest. Weitere Informationen finden Sie unter Abmelden.

3. Binden Sie die App ID-Serviceinstanz an den Cluster. Der Befehl erstellt einen Dienstschlüssel für die Dienstinstanz. Alternativ können Sie die Option --key angeben, um vorhandene Anmeldedaten für den Dienstschlüssel zu verwenden. Stellen Sie sicher, dass Sie die Serviceinstanz an den Namensbereich binden, in dem sich auch Ihre Ingress-Ressourcen befinden. Beachten Sie, dass alle Buchstaben im Serviceinstanznamen als Kleinbuchstaben angegeben werden müssen.

   ibmcloud ks cluster service bind --cluster CLUSTER_NAME_OR_ID --namespace NAMESPACE --service APP_ID_SERVICE_INSTANCE_NAME [--key SERVICE_INSTANCE_KEY]
   

   Wenn der Service erfolgreich an Ihren Cluster gebunden wurde, wird ein geheimer Schlüssel für den Cluster erstellt, der die Berechtigungsnachweise Ihrer Serviceinstanz enthält. CLI-Beispielausgabe:

   ibmcloud ks cluster service bind --cluster mycluster --namespace mynamespace --service appid1
   Binding service instance to namespace...
   OK
   Namespace:    mynamespace
   Secret name:  binding-<service_instance_name>
   

4. Aktivieren Sie das Add-on für den ALB-OAuth-Proxy in Ihrem Cluster. Dieses Add-on erstellt und verwaltet die folgenden Kubernetes-Ressourcen: eine OAuth2-Proxy-Bereitstellung für Ihre App ID-Serviceinstanz, einen geheimen Schlüssel, der die Konfiguration der OAuth2-Proxy-Bereitstellung enthält, und eine Ingress-Ressource, die ALBs konfiguriert, um eingehende Anforderungen an die OAuth2-Proxy-Bereitstellung für Ihre App ID-Instanz weiterzuleiten. Der Name jeder dieser Ressourcen beginnt mit oauth2-.

   1. Aktivieren Sie das alb-oauth-proxy-Add-on.

       ibmcloud ks cluster addon enable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID
       ```
   2. Stellen Sie sicher, dass das Add-on für den ALB-OAuth-Proxy den Status `Addon Ready` (Add-on bereit) aufweist.
   ```sh {: pre}
       ibmcloud ks cluster addon ls --cluster CLUSTER_NAME_OR_ID
       ```
   

5. Stellen Sie in den Ingress-Ressourcen für Apps, denen Sie die Authentifizierung App ID hinzufügen möchten, sicher, dass der Ressourcenname nicht länger als 25 Zeichen ist. Fügen Sie anschließend die folgenden Annotationen zum Abschnitt metadata.annotations hinzu:

   1. Fügen Sie die folgende Annotation auth-url hinzu. Diese Annotation gibt die URL des OAuth2-Proxys für Ihre App ID-Instanz an, die als OIDC-Relying Party (RP) für App ID fungiert. Beachten Sie, dass alle Buchstaben im Serviceinstanznamen als Kleinbuchstaben angegeben werden müssen.

       ...
       annotations:
          nginx.ingress.kubernetes.io/auth-url: https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth
       ...
       ```
   2. Manchmal überschreitet das von `OAuth2-Proxy` verwendete Authentifizierungscookie 4 KB. Daher wird sie in zwei Teile aufgeteilt. Das folgende Snippet muss hinzugefügt werden, um sicherzustellen, dass beide Cookies von `OAuth2-Proxy` ordnungsgemäß aktualisiert werden können.
   ```yaml {: codeblock}
       ...
       annotations:
           nginx.ingress.kubernetes.io/configuration-snippet: |
           auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
           access_by_lua_block {
               if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
               ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
               end
           }
       ...
       ```
   
   3. Wählen Sie aus, welche Tokens im Header `Authorization` an Ihre App gesendet werden sollen. Weitere Informationen zu ID- und Zugriffstoken finden Sie in der [Dokumentation zu App ID.](/docs/appid?topic=appid-tokens){: external}
       * Um nur die zu versenden `ID Token`, fügen Sie folgende Anmerkung hinzu:
   
           ```yaml {: codeblock}
           ...
           annotations:
               nginx.ingress.kubernetes.io/auth-response-headers: Authorization
           ...
           ```
       * Um nur die zu senden `Access Token`, fügen Sie die folgenden Informationen zur Anmerkung `configuration-snippet` hinzu. (Dadurch wird das Snippet aus Schritt 5.2erweitert).
   
           ```yaml {: codeblock}
           ...
           annotations:
               nginx.ingress.kubernetes.io/configuration-snippet: |
               auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
               auth_request_set $access_token $upstream_http_x_auth_request_access_token;
               access_by_lua_block {
                   if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
                   ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
                   end
                   if ngx.var.access_token ~= "" then
                   ngx.req.set_header("Authorization", "Bearer " .. ngx.var.access_token)
                   end
               }
           ...
           ```
       * Um das und `Access Token` das zu senden `ID Token`, fügen Sie die folgenden Informationen zur Anmerkung `configuration-snippet` hinzu. (Dadurch wird das Snippet aus Schritt 5.2erweitert).
           ```yaml {: codeblock}
           ...
            annotations:
               nginx.ingress.kubernetes.io/configuration-snippet: |
               auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
               auth_request_set $access_token $upstream_http_x_auth_request_access_token;
               auth_request_set $id_token $upstream_http_authorization;
               access_by_lua_block {
                   if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
                   ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
                   end
                   if ngx.var.id_token ~= "" and ngx.var.access_token ~= "" then
                   ngx.req.set_header("Authorization", "Bearer " .. ngx.var.access_token .. " " .. ngx.var.id_token:match("%s*Bearer%s*(.*)"))
                   end
               }
           ...
           ```
   4. Optional: Wenn Ihre App die [Web-App-Strategie](/docs/appid?topic=appid-key-concepts#term-web-strategy) und/oder die [API-Strategie](/docs/appid?topic=appid-key-concepts#term-api-strategy) unterstützt, fügen Sie die Annotation `nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2-<App_ID_service_instance_name>/start?rd=$escaped_request_uri` hinzu. Beachten Sie, dass alle Buchstaben im Namen der Service-Instanz in Kleinbuchstaben geschrieben sein müssen.
       * Wenn Sie diese Annotation angeben und die Authentifizierung für einen Client fehlschlägt, wird der Client an die URL des OAuth2-Proxys für Ihre App ID-Instanz umgeleitet. Dieser OAuth2-Proxy, der als OIDC-Relying Party (RP) für App ID dient, leitet den Client zur Authentifizierung an Ihre App ID-Anmeldeseite weiter.
       * Wenn Sie diese Annotation nicht angeben, muss sich der Client mit einem gültigen Trägertoken authentifizieren. Wenn die Authentifizierung für einen Client fehlschlägt, wird die Anforderung des Clients mit der Fehlernachricht `401 Unauthorized` zurückgewiesen.
   
   

6. Wenden Sie Ihre Ingress-Ressourcen erneut an, um die App ID-Authentifizierung zu erzwingen. Nachdem eine Ingress-Ressource mit den entsprechenden Annotationen erneut angewendet wird, stellt das ALB-OAuth-Proxy-Add-on eine OAuth2-Proxy-Bereitstellung bereit, erstellt einen Service für die Bereitstellung und erstellt eine separate Ingress-Ressource, um das Routing für die OAuth2-Proxy-Bereitstellungsnachrichten zu konfigurieren. Diese Add-on-Ressourcen dürfen Sie nicht löschen.

   kubectl apply -f <app_ingress_resource>.yaml -n namespace
   

7. Stellen Sie sicher, dass die App ID-Authentifizierung für Ihre Apps erzwungen wird.

   • Wenn Ihre Apps die Web-App-Strategie unterstützen: Greifen Sie auf die URL Ihrer App in einem Web-Browser zu. Wenn App ID korrekt angewendet wird, werden Sie auf eine entsprechende Anmeldeseite für die App ID-Authentifizierung weitergeleitet.
   • Wenn Ihre Apps die API-Strategie unterstützen: Geben Sie Ihr Bearer-Zugriffstoken im Autorisierungsheader von Anforderungen an die Apps an. Informationen zum Abrufen Ihres Zugriffstokens finden Sie in der Dokumentation zu App ID. Wenn App ID korrekt angewendet wird, wird die Anforderung erfolgreich authentifiziert und an Ihre App weitergeleitet. Wenn Sie Anforderungen an Ihre Apps ohne ein Zugriffstoken im Autorisierungsheader senden oder wenn das Zugriffstoken nicht von App ID akzeptiert wird, wird die Anforderung zurückgewiesen.

8. Optional: Wenn Sie Netzwerkrichtlinien oder eine andere Firewall-Lösung auf Ihrem Cluster verwenden, um den ausgehenden Datenverkehr zu begrenzen, müssen Sie sicherstellen, dass der Zugriff auf den öffentlichen Dienst AppID's von Ihrem Cluster aus möglich ist. Um den IP-Adressbereich für diesen Dienst zu erhalten, stellen Sie bitte eine Anfrage an den Kundensupport.

9. Optional: Sie können das Standardverhalten des OAuth2-Proxys anpassen, indem Sie eine Kubernetes-Konfigurationszuordnung erstellen.

   1. Erstellen Sie eine YAML-Datei für die Konfigurationszuordnung, die Werte für die OAuth2-Proxy-Einstellungen angibt, die Sie ändern möchten.

       apiVersion: v1
       kind: ConfigMap
       metadata:
         name: oauth2-<App_ID_service_instance_name>
         namespace: <ingress_resource_namespace>
       data:
         auth_logging: <true|false>
         # Log all authentication attempts.
         auth_logging_format:
         # Format for authentication logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#logging-configuration
         cookie_csrf_expire: "15m"
         # Expiration time for CSRF cookie. Default is "15m".
         cookie_csrf_per_request: <true|false>
         # Enable multiple CSRF cookies per request, making it possible to have parallel requests. Default is "false".
         cookie_domains:
         # A list of optional domains to force cookies to. The longest domain that matches the request’s host is used. If there is no match for the request’s host, the shortest domain is used. Example: sub.domain.com,example.com
         cookie_expire: "168h0m0s"
         # Expiration time for cookies. Default: "168h0m0s".
         cookie_samesite: ""
         # SameSite attribute for cookies. Supported values: "lax", "strict", "none", or "".
         email_domains: ""
         # Authenticate IDs that use the specified email domain. To authenticate IDs that use any email domain, use "*". Default: "". Example: example.com,example2.com
         pass_access_token: <true|false>
         # Pass the OAuth access token to the backend app via the X-Forwarded-Access-Token header.
         request_logging: <true|false>
         # Log all requests to the backend app.
         request_logging_format:
         # Format for request logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#request-log-format
         scope:
         # Scope of the OAuth authentication. For more info, see https://oauth.net/2/scope/
         set_authorization_header: <true|false>
         # Set the Authorization Bearer response header when the app responds to the Ingress ALB, such when using the NGINX auth_request mode.
         set_xauthrequest: <true|false>
         # Set X-Auth-Request-User, X-Auth-Request-Email, and X-Auth-Request-Preferred-Username response headers when the app responds to the Ingress ALB, such as when using the NGINX auth_request mode.
         standard_logging: <true|false>
         # Log standard runtime information.
         standard_logging_format:
         # Format for standard logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#standard-log-format
         tls_secret_name:
         # The name of a secret that contains the server-side TLS certificate and key to enable TLS between the OAuth2-Proxy and the Ingress ALB. By default, the TLS secret defined in your Ingress resources is used.
         whitelist_domains:
         # Allowed domains for redirection after authentication. Default: "". Example: example.com,*.example2.com For more info, see: https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#command-line-options
         oidc_extra_audiences:
         # Additional audiences which are allowed to pass verification.
         cookie_refresh:
         # Refresh the cookie after this duration. Example: "15m". To use this feature, you must enable "Refresh token" for the AppID instance. For more info, see: /docs/appid?topic=appid-managing-idp&interface=ui#idp-token-lifetime
       ```
   2. Wenden Sie die Konfigurationszuordnungsressource auf das Add-on an. Ihre Änderungen werden automatisch angewendet.
   ```sh {: pre}
       kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
       ```
   

Eine Liste der Änderungen für jede Version des ALB- OAuth-Proxy-Add-ons finden Sie im Änderungsprotokoll für das ALB- OAuth-Proxy-Add-on unter IBM Cloud.

Quellen-IP-Adresse beibehalten

Standardmäßig werden die Quellen-IP-Adressen der Clientanforderungen von der Ingress-ALB nicht beibehalten. Um Quellen-IP-Adressen beizubehalten, können Sie das PROXY-Protokoll in VPC-Clustern aktivieren oder externalTrafficPolicy in klassischen Clustern ändern.

SSL-Protokolle und SSL-Verschlüsselungen auf HTTP-Ebene konfigurieren

Aktivieren Sie SSL-Protokolle und Verschlüsselungen auf der globalen HTTP-Ebene, indem Sie die Konfigurationszuordnung ibm-k8s-controller-config entsprechend bearbeiten.

Wenn Sie beispielsweise noch ältere Clients haben, die Unterstützung für TLS 1.0 oder 1.1 benötigen, müssen Sie diese TLS-Versionen manuell aktivieren, um nur die Standardeinstellung von TLS 1.2 und TLS 1.3 zu überschreiben.

Wenn Sie die aktivierten Protokolle für alle Hosts angeben, funktionieren die Parameter TLSv1.1 und TLSv1.2 (1.1.13, 1.0.12) nur, wenn OpenSSL 1.0.1 oder eine höhere Version verwendet wird. Der Parameter TLSv1.3 (1.13.0) funktioniert nur, wenn OpenSSL 1.1.1 mit der Unterstützung von TLSv1.3 erstellt und dann verwendet wird.

Gehen Sie wie folgt vor, um die Konfigurationszuordnung zu bearbeiten und SSL-Protokolle und Verschlüsselungen zu aktivieren.

1. Bearbeiten Sie die Konfigurationsdatei für die Konfigurationszuordnungsressource ibm-k8s-controller-config.

   kubectl edit cm ibm-k8s-controller-config -n kube-system
   

2. Fügen Sie SSL-Protokolle und Verschlüsselungen hinzu. Formatieren Sie Verschlüsselungsalgorithmen gemäß dem Format der Verschlüsselungsalgorithmenliste der Bibliothek OpenSSL.

   apiVersion: v1
   data:
     ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2 TLSv1.3"
     ssl-ciphers: "HIGH:!aNULL:!MD5:!CAMELLIA:!AESCCM:!ECDH+CHACHA20"
   kind: ConfigMap
   metadata:
     name: ibm-k8s-controller-config
     namespace: kube-system
   

3. Speichern Sie die Konfigurationsdatei.

4. Stellen Sie sicher, dass die Änderungen an der Konfigurationszuordnung angewendet wurden. Die Änderungen werden automatisch auf Ihre ALBs angewendet.

   kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml
   

Angepasstes Zertifikat an ältere Clients senden

Wenn Sie über traditionelle Einheiten ohne Unterstützung für SNI (Server Name Indication) verfügen und ein angepasstes TLS-Zertifikat in Ihren Ingress-Ressourcen verwenden, müssen Sie die Servereinstellungen der ALB bearbeiten, damit Ihr angepasstes TLS-Zertifikat und der angepasste geheime TLS-Schlüssel verwendet werden.

Wenn Sie einen klassischen Cluster erstellen, wird das LetsEncrypt-Zertifikat standardmäßig für den geheimen Ingress-Schlüssel generiert, der von IBM bereitgestellt wird. Wenn Sie einen angepassten geheimen Schlüssel in Ihrem Cluster erstellen und diesen angepassten geheimen Schlüssel für die TLS-Terminierung in Ihren Ingress-Ressourcen angeben, sendet die Ingress-ALB das Zertifikat für Ihren angepassten geheimen Schlüssel an den Client anstelle des LetsEncrypt-Standardzertifikats. Wenn ein Client SNI jedoch nicht unterstützt, verwendet die Ingress-ALB standardmäßig das LetsEncrypt-Zertifikat an, da der standardmäßig verwendete geheime Schlüssel in den Standardservereinstellungen der ALB aufgelistet ist. Damit Ihr angepasstes Zertifikat an die Einheiten ohne SNI-Unterstützung gesendet wird, führen Sie die folgenden Schritte aus, um in den Standardservereinstellungen der ALB Ihren angepassten geheimen Schlüssel anzugeben.

Die standardmäßig generierten Let' s Encrypt-Zertifikate sind nicht für den Einsatz in Produktionsumgebungen bestimmt. Verwenden Sie für Produktionsworkloads ein eigenes angepasstes Zertifikat.

1. Bearbeiten Sie die Ingress-Ressource alb-default-server.

   kubectl edit ingress alb-default-server -n kube-system
   

2. Ändern Sie im Abschnitt spec.tls den Wert der Einstellung hosts.secretName in den Namen Ihres angepassten geheimen Schlüssels, der Ihr angepasstes Zertifikat enthält. Beispiel:

   spec:
       rules:
       ...
       tls:
       - hosts:
       - invalid.mycluster-<hash>-0000.us-south.containers.appdomain.cloud
       secretName: <custom_secret_name>
   

3. Speichern Sie die Ressourcendatei.

4. Stellen Sie sicher, dass die Ressource jetzt auf den Namen Ihres geheimen Schlüssels verweist. Die Änderungen werden automatisch auf Ihre ALBs angewendet.

   kubectl get ingress alb-default-server -n kube-system -o yaml
   

Feinabstimmung der Verbindungsbehandlung

Die Einstellungen client-header-timeout, client-body-timeout und keep-alive sind wichtige Konfigurationen, die bestimmen, wie lange Verbindungen zwischen Clients, dem Ingress-Controller und den Backend-Servern aktiv bleiben. Diese Timeouts spielen eine wichtige Rolle bei der Optimierung der Anfragebearbeitung, insbesondere wenn es um lang andauernde Client-Verbindungen und verzögerte Antworten von Backend-Servern geht, und verhindern, dass wertvolle Ressourcen unnötig belegt werden.

Die client-header-timeout definiert die maximale Zeit, die der Server auf einen vollständigen Client-Header wartet. In ähnlicher Weise gibt client-body-timeout die Dauer an, die der Server darauf wartet, dass der Client den Hauptteil der Anfrage sendet. Diese beiden Timeouts müssen mit dem Parameter keep-alive übereinstimmen, der festlegt, wie lange der Server eine Verbindung offen hält, während er auf weitere Anfragen wartet. Wenn diese Timeouts nicht mit der Keep-alive-Einstellung übereinstimmen, beendet NGINX die Verbindung, was zu unerwartetem Client-Verhalten oder Anfragefehlern führen kann.

Sie können diese Parameter in der Datei ConfigMapibm-k8s-controller-config im Namespace kube-system festlegen.

apiVersion: v1
kind: ConfigMap
metadata:
  name: ibm-k8s-controller-config
  namespace: kube-system
data:
  ...
  client-body-timeout: "100"
  client-header-timeout: "100"
  keep-alive: "100"

Weitere Informationen finden Sie in der client-header-timeout, client-body-timeout und keep-alive in der Dokumentation zu Ingress Nginx.

ALB-Leistung optimieren

Um die Leistung Ihrer Ingress-ALBs zu optimieren, können Sie die Standardeinstellungen entsprechend Ihren Anforderungen ändern.