Server-Port zu einem Host-Header hinzufügen

Um einen Server-Port zur Clientanforderung hinzuzufügen, bevor die Anforderung an Ihre Back-End-App weitergeleitet wird, konfigurieren Sie einen Proxy für externe Services in einer Serverausschnittsannotation oder als Feld ibm-k8s-controller-config ConfigMap .

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 Apps zu erzwingen, indem Sie bestimmte Ingress-Felder für Kubernetes ändern. Weitere Informationen finden Sie unter App ID-Authentifizierung zu Apps hinzufügen.

Maximale Größe des Clientanforderungshauptteils festlegen

Verwenden Sie die folgende Kubernetes Ingress resource , um die maximale Größe des Hauptteils festzulegen, die der Client als Teil einer Anforderung senden kann.

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 von Verbindungs- und Lesezeitüberschreitungen

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 ausführen kann, legen Sie die custom-http-errors Feld.

Ä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 dem folgenden Kubernetes Ingress ibm-ingress-deploy-config ConfigMap Felder.

Beispielfeldeinstellung.

httpPort=8080
httpsPort=8443

Anforderungsheader anpassen

Um einer Clientanforderung Headerinformationen hinzuzufügen, bevor die Anforderung an Ihre Back-End-App weitergeleitet wird, verwenden Sie das folgende Kubernetes ibm-k8s-controller-config configmap .

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

Die Anforderungen für custom-headers ConfigMap 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 Pfaddefinitionen zu externen Diensten

Wenn Sie Pfaddefinitionen zu externen Services hinzufügen möchten, z. B. zu in IBM Cloudgehosteten Services, konfigurieren Sie einen Proxy zu externen Services in einem Positionssnippet. Oder ersetzen Sie den Proxy durch eine permanente Umleitung zu externen Services.

Unsichere Anforderungen umleiten

Standardmäßig werden unsichere HTTP-Clientanfragen an 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.

• Um das maximale Alter und die Subdomain-Granularität hinzuzufügen, siehe diesen NGINX-Blog.
• Um sie zu deaktivieren, setzen Sie das Feld ibm-k8s-controller-config configmap.

  hsts: false
  

Maximale Anzahl von Keepalive-Anforderungen festlegen

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

keep-alive-requests: 100

Der Standardwert für keep-alive-requests in Kubernetes Ingress ist 100, was viel weniger ist als der Standardwert von 4096 in IBM Cloud Kubernetes Service Ingress. 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 geöffnet bleibt, verwenden Sie das folgende Feld Kubernetes ibm-k8s-controller-config configmap .

keep-alive: 60

Maximale Anzahl großer Client-Header-Puffer festlegen

Um die maximale Anzahl und Größe der Puffer festzulegen, die große Clientanforderungsheader lesen, verwenden Sie das folgende Kubernetes ibm-k8s-controller-config configmap .

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 Anforderungs-URI mit dem App-Pfad abgleicht, verwenden Sie die folgende Kubernetes Ingress resource .

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

Weitere Informationen finden Sie in diesem Blog.

Angepasste Positionsblockkonfigurationen hinzufügen

Verwenden Sie die folgende Kubernetes Ingress resource , um eine angepasste Positionsblockkonfiguration für einen Service hinzuzufügen.

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

Gegenseitige Authentifizierung konfigurieren

Um die gegenseitige Authentifizierung für die ALB zu konfigurieren, verwenden Sie die folgenden Kubernetes Ingress resource . 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

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

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

Proxy-Puffernummern konfigurieren

Verwenden Sie die folgende Kubernetes Ingress resource , um die Anzahl der Proxy-Puffer für die ALB zu konfigurieren.

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 den NGINX-Dokumenten.

Konfigurieren, wann eine ALB eine Anforderung übergeben kann

Um festzulegen, wann die ALB eine Anforderung an den nächsten Upstream-Server übergeben kann, verwenden Sie die folgenden Kubernetes-Ingress-Felder.

• 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 Back-End-Endanwendung entfernen, bevor die Antwort an den Client gesendet wird. Konfigurieren Sie das Entfernen des Antwortheaders in einem Positionssnippetoder verwenden Sie das Feld proxy_hide_header als Konfigurationssnippet in der ibm-k8s-controller-config ConfigMap.

Pfade neu schreiben

Verwenden Sie die folgende Kubernetes Ingress resource , um eingehenden Netzverkehr in einem ALB-Domänenpfad an einen anderen Pfad weiterzuleiten, den Ihre Back-End-App überwacht.

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

Serverblockkonfigurationen anpassen

Verwenden Sie die folgende Kubernetes Ingress resource , um eine angepasste Serverblockkonfiguration hinzuzufügen.

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

Eingehenden Netzverkehr weiterleiten

Um eingehenden Netzverkehr immer unter Verwendung eines permanenten Cookies an denselben Upstream-Server weiterzuleiten, verwenden Sie die folgenden Kubernetes Ingress-Ressourcen .

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.

SSL-Services-Unterstützung zum Verschlüsseln von Datenverkehr zulassen

Um SSL-Diensten die Verschlüsselung des Datenverkehrs zu Ihren Upstream-Apps zu ermöglichen, die HTTPS erfordern, verwenden Sie die Kubernetes Ingress-Ressourcen -Backend-Protokollannotation und die Backend-Zertifikatauthentifizierungsannotationen.

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

Mit vom Standard abweichenden TCP-Ports auf Apps zugreifen

Führen Sie die folgenden Schritte aus, um über einen vom Standard abweichenden TCP-Port auf eine App zuzugreifen:

1. Erstellen Sie eine tcp-services-ConfigMap, um Ihren TCP-Port anzugeben (z. B. folgende Beispielports). Zu den Anforderungen der Website tcp-services ConfigMap, siehe diesen 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

Zum Festlegen der maximalen Anzahl von Anforderungen, 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 App geöffnet bleibt, verwenden Sie das folgende Kubernetes ibm-k8s-controller-config configmap .

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.

     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

Erzwingen Sie die Authentifizierung für Ihre Anwendungen durch die Konfiguration von Ingress mit IBM Cloud App ID.

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 wird, wird der Benutzer nicht authentifiziert, sondern erhält ein Zugriffstoken für den anonymen Zugriff auf die Anwendung.
   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 ConfigMap für OAuth2-Proxy festlegen. 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 Serviceschlüssel für die Serviceinstanz, oder Sie können die Option --key angeben, um vorhandene Anmeldeinformationen für den Serviceschlü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.

      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.

      ...
      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 über ID- und Zugriffstoken finden Sie in der Dokumentation App ID.

      • Um nur die ID Token zu senden, fügen Sie die folgende Anmerkung hinzu:

        ...
        annotations:
            nginx.ingress.kubernetes.io/auth-response-headers: Authorization
        ...
        

      • Um nur die Access Token zu senden, fügen Sie die folgenden Informationen in die Anmerkung configuration-snippet ein. (Dadurch wird das Snippet aus Schritt 5.2erweitert).

        ...
        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 die Access Token und die ID Token zu senden, fügen Sie der Anmerkung configuration-snippet die folgenden Informationen hinzu. (Dadurch wird das Snippet aus Schritt 5.2erweitert).

        ...
         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 und/oder die API-Strategie 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 Serviceinstanz in Kleinbuchstaben geschrieben werden 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.

      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 des IBM Cloud ALB OAuth Proxy-Add-ons.

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 die Chiffren entsprechend dem Format der Chiffrierliste 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 die oben genannten Parameter in ibm-k8s-controller-config ConfigMap im Namensraum kube-system einstellen.

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.