Aggiunta di una porta del server a un'intestazione host

Per aggiungere una porta server alla richiesta client prima che la richiesta venga inoltrata alla tua applicazione di back-end, configura un proxy ai servizi esterni in un'annotazione del frammento del server o come un campo ibm-k8s-controller-config ConfigMap .

Instradamento di richieste in entrata con un ALB privato

Per instradare richieste in entrata alle tue applicazioni con un ALB privato, specifica l'annotazione della classe private-iks-k8s-nginx nella risorsa Ingress. Gli ALB privati sono configurati per utilizzare le risorse con questa classe.

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

Autenticazione delle applicazioni con App ID

Configura Ingress con IBM Cloud App ID per applicare l'autenticazione per le tue applicazioni modificando specifici campi Ingress Kubernetes. Per ulteriori informazioni, vedi Aggiunta dell'autenticazione App ID alle applicazioni.

Impostazione della dimensione massima del corpo della richiesta client

Per impostare la dimensione massima del corpo che il client può inviare come parte di una richiesta, utilizza la seguente risorsa Kubernetes Ingress annotazione.

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

Abilitazione e disabilitazione del buffer dei dati di risposta client

È possibile disabilitare o abilitare l'archiviazione dei dati di risposta sull'ALB mentre i dati vengono inviati al client. Tale impostazione viene disabilitata come impostazione predefinita. Per abilitare, imposta la seguente risorsa Ingress annotazione.

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

Personalizzazione dei timeout di connessione e lettura

Per impostare la quantità di tempo che l'ALB attende per connettersi e leggere dall'applicazione di back - end prima di considerarla non disponibile, utilizza le seguenti annotazioni.

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

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

Personalizzazione delle azioni di errore

Per indicare le azioni personalizzate che l'ALB può intraprendere per specifici errori di comunicazione ( HTTP ), impostare il campo " custom-http-errors ".

Modifica delle porte predefinite HTTP e HTTPS

Per modificare le porte predefinite per il traffico di rete HTTP (porta 80) e HTTPS (porta 443), modificare ogni servizio ALB con il seguente Kubernetes Ingresso ibm-ingress-deploy-config ConfigMap campi.

Impostazione campo di esempio.

httpPort=8080
httpsPort=8443

Personalizzazione dell'intestazione della richiesta

Per aggiungere le informazioni di intestazione a una richiesta client prima di inoltrare la richiesta alla tua applicazione di back-end, utilizza il seguente campo ibm-k8s-controller-config configmap Kubernetes

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

Per i requisiti custom-headers ConfigMap, consultare questo esempio.

Personalizzazione dell'intestazione della risposta

Per aggiungere informazioni di intestazione a una risposta client prima di inviarle al client, utilizza la seguente annotazione.

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

Aggiunta di definizioni di percorsi a servizi esterni

Per aggiungere definizioni di percorsi a servizi esterni, come i servizi ospitati in IBM Cloud, configurare un proxy per i servizi esterni in un frammento di ubicazione. In alternativa, sostituire il proxy con un reindirizzamento permanente ai servizi esterni.

Reindirizzamento delle richieste non sicure

Per impostazione predefinita, le richieste client non sicure dell' HTTP e vengono reindirizzate a HTTPS. Per disabilitare questa impostazione, utilizzare il seguente campo e annotazione.

• ibm-k8s-controller-config ConfigMap campo

  ssl-redirect: "false"
  

• annotazionedella risorsa Ingress:

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

Abilitazione e disabilitazione dell' HTTP Sicurezza rigorosa dei trasporti

Imposta il browser per accedere al dominio solo tramite HTTPS. Questa opzione è attivata per impostazione predefinita.

• Per aggiungere la durata massima e la granularità del dominio secondario, vedi questo blog NGINX.
• Per disabilitare, impostare il campo ibm-k8s-controller-config configmap .

  hsts: false
  

Impostazione di un numero massimo di richieste keepalive

Per impostare il numero massimo di richieste che è possibile soddisfare tramite una connessione keepalive, utilizza il seguente campo Kubernetes ibm-k8s-controller-config configmap .

keep-alive-requests: 100

Il valore predefinito per keep-alive-requests in Kubernetes Ingress è 100, che è molto inferiore al valore predefinito di 4096 in IBM Cloud Kubernetes Service Ingress. Se hai migrato la tua configurazione Ingress da IBM Cloud Kubernetes Service Ingress a Kubernetes Ingress, potresti dover modificare keep-alive-requests per superare i test delle prestazioni esistenti.

Impostazione di un timeout massimo di richiesta keepalive

Per impostare il tempo massimo durante il quale una connessione keepalive rimane aperta tra il client e il server proxy ALB, utilizza il seguente campo Kubernetes ibm-k8s-controller-config configmap .

keep-alive: 60

Impostazione di un numero massimo di buffer di intestazione client di grandi dimensioni

Per impostare il numero massimo e la dimensione dei buffer che leggono intestazioni di richiesta client di grandi dimensioni, utilizza il seguente campo Kubernetes ibm-k8s-controller-config configmap .

large-client-header-buffers: 4 8k

Modifica del modo in cui l'ALB corrisponde all'URI della richiesta

Per modificare il modo in cui l'ALB corrisponde all'URI della richiesta rispetto al percorso dell'applicazione, utilizza la seguente annotazione Kubernetes Ingress resource .

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

Per ulteriori informazioni, consultare questo blog.

Aggiunta di configurazioni del blocco di ubicazioni personalizzate

Per aggiungere una configurazione del blocco di ubicazioni personalizzata per un servizio, utilizza la seguente Kubernetes risorsa Ingress annotazione.

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

Configurazione dell'autenticazione reciproca

Per configurare l'autenticazione reciproca per l'ALB, utilizza la seguente Kubernetes risorsa Ingress annotazioni. Si noti che l'autenticazione reciproca non può essere applicata alle porte personalizzate e deve essere applicata alla porta " HTTPS ".

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"

Configurazione della dimensione del buffer proxy

Per configurare la dimensione del buffer proxy che legge la prima parte della risposta, utilizza la annotazionedella risorsa Ingress Kubernetes.

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

Configurazione dei numeri di buffer proxy

Per configurare il numero di buffer proxy per l'ALB, utilizza la seguente annotazione Kubernetes Ingress resource .

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

Configurazione della dimensione del buffer del proxy occupato

Per configurare la dimensione dei buffer proxy che possono essere occupati, utilizzare un frammento di posizione. Per ulteriori informazioni, vedi la documentazione di NGINX.

Configurazione quando un ALB può passare una richiesta

Per impostare quando l'ALB può passare una richiesta al successivo server upstream, utilizza i seguenti campi Ingress Kubernetes.

• Impostazione globale: campi ibm-k8s-controller-config ConfigMap :

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

• Impostazione per risorsa: annotazionidella risorsa Ingress:

  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
  

Limitazione della frequenza

Per limitare la frequenza di elaborazione delle richieste e il numero di connessioni per una chiave definita per i servizi, utilizza le annotazioni per la limitazione della frequenzadella risorsa Ingress.

Rimozione dell'intestazione della risposta

È possibile rimuovere le informazioni di intestazione incluse nella risposta del client dall'applicazione finale di back-end prima che la risposta venga inviata al client. Configurare la rimozione dell'intestazione della risposta in un frammento di ubicazioneoppure utilizzare il campo proxy_hide_header come frammento di configurazione in ibm-k8s-controller-config ConfigMap.

Riscrittura dei percorsi

Per instradare il traffico di rete in entrata su un percorso di dominio ALB a un percorso differente su cui è in attesa la tua applicazione di back - end, utilizza la seguente annotazione Kubernetes Ingress resource .

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

Personalizzare le configurazioni dei blocchi del server

Per aggiungere una configurazione del blocco del server personalizzato, utilizza la seguente annotazione Kubernetes Ingress resource .

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

Instradamento del traffico di rete in entrata

Per instradare sempre il traffico di rete in ingresso allo stesso server upstream utilizzando un cookie permanente, utilizza le seguenti Kubernetes Kubernetes .

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";

Il controller Ingress Kubernetes aggiunge gli attributi Secure e HttpOnly ai cookie permanenti per impostazione predefinita, che non possono essere modificati.

Abilitazione del supporto dei servizi SSL per crittografare il traffico

Per consentire il supporto dei servizi SSL per crittografare il traffico verso le applicazioni upstream che richiedono l' HTTPS, utilizzare l'annotazione del protocollo backend delle risorse di ingresso ( Kubernetes ) e le annotazioni di autenticazione del certificato backend.

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

Accesso alle app con porte TCP non standard

Per accedere a un'app tramite una porta TCP non standard, segui questi passaggi.

1. Creare una tcp-services ConfigMap per specificare la porta TCP, come le seguenti porte di esempio. Per i requisiti della tcp-services ConfigMap, vedere questo blog.

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

2. Creare il file ConfigMap nello spazio dei nomi kube-system.

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

3. Specificare tcp-services ConfigMap come campo in ibm-ingress-deploy-config ConfigMap.

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

4. Modifica ogni Servizio ALB per aggiungere le porte.

Impostazione di un numero massimo di richieste keepalive upstream

Per impostare il numero massimo di richieste che possono essere soddisfatte tramite una connessione keepalive, utilizza il seguente campo Kubernetes ibm-k8s-controller-config ConfigMap .

upstream-keepalive-requests: 32

Impostazione del timeout massimo di keepalive upstream

Per impostare il tempo massimo per cui una connessione keepalive rimane aperta tra il server proxy ALB e il server upstream della tua applicazione, utilizza il seguente campo Kubernetes ibm-k8s-controller-config configmap .

upstream-keepalive-timeout: 32

Personalizzazione della distribuzione ALB

Personalizza la distribuzione per gli ALB che eseguono l'immagine Ingress Kubernetes creando una ibm-ingress-deploy-config ConfigMap.

1. Ottieni i nomi dei servizi che espongono ogni ALB.

   • Cluster classici:

     kubectl get svc -n kube-system | grep alb
     

   • Cluster VPC: nell'output, cerca un nome servizio formattato come public-crc204dl7w0qf6n6sp7tug.

     kubectl get svc -n kube-system | grep LoadBalancer
     

Personalizzazione della classe Ingress

Una classe Ingress associa un nome classe a un tipo di controller Ingress. Utilizza la risorsa IngressClass per personalizzare classi Ingress.

Aggiunta dell'autenticazione App ID alle applicazioni

Applica l'autenticazione per le tue applicazioni configurando Ingress con IBM Cloud App ID.

1. Scegli un'istanza esistente oppure crea una nuova istanza App ID.

   Un'istanza App ID può essere utilizzata in un solo spazio dei nomi nel cluster. Se vuoi configurare App ID per risorse Ingress in più spazi dei nomi, ripeti i passi in questa sezione per specificare un'istanza App ID univoca per le risorse Ingress in ciascun spazio dei nomi.

   • Per utilizzare un'istanza esistente, assicurarsi che il nome dell'istanza del servizio contenga solo caratteri alfanumerici minuscoli e che la sua lunghezza non superi i 25 caratteri. Per modificare il nome, seleziona Rinomina servizio dal menu delle ulteriori opzioni nella tua pagina dei dettagli dell'istanza del servizio.
   • Per eseguire il provisioning di una nuova istanza App ID:
     1. Sostituisci il Nome del servizio con il tuo nome univoco per l'istanza del servizio. Il nome dell'istanza di servizio deve contenere solo caratteri alfanumerici minuscoli e non può essere più lungo di 25 caratteri.
     2. Scegli la stessa regione in cui è distribuito il tuo cluster.
     3. Fai clic su Crea.

2. Aggiungi gli URL di reindirizzamento per la tua applicazione. Un URL di reindirizzamento è l'endpoint di callback della tua applicazione. Per impedire attacchi di phishing, IBM Cloud App ID convalida l'URL della richiesta rispetto all'elenco di elementi consentiti (allowlist) degli URL di reindirizzamento.

   1. Nella console di gestione App ID, passa a Gestisci autenticazione.
   2. Nella scheda Provider di identità, assicurati di avere un Provider di identità selezionato. Se non viene selezionato alcun Identity Provider, l'utente non viene autenticato ma gli viene rilasciato un token di accesso per l'accesso anonimo all'applicazione.
   3. Nella scheda Impostazioni di autenticazione, aggiungere gli URL di reindirizzamento per la propria applicazione nel formato https://<hostname>/oauth2-<App_ID_service_instance_name>/callback. Notare che tutte le lettere nel nome dell'istanza del servizio devono essere specificate in minuscolo.

   Se si utilizza la funzione di logout di IBM Cloud App ID, è necessario aggiungere /sign_out al proprio dominio nel formato https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out e includere questo URL nell'elenco degli URL di reindirizzamento. Se si desidera utilizzare una pagina di logout personalizzata, è necessario impostare whitelist_domains nel file ConfigMap per OAuth2-Proxy. Richiama l'endpoint https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out con il parametro di query rd o imposta l'intestazione X-Auth-Request-Redirect con la tua pagina di logout personalizzata. Per ulteriori dettagli, consultare Scollegamento.

3. Esegui il bind dell'istanza del servizio App ID al tuo cluster. Il comando crea una chiave di servizio per l'istanza del servizio, oppure si può includere l'opzione --key per utilizzare le credenziali della chiave di servizio esistente. Assicurati di eseguire il bind dell'istanza del servizio allo stesso spazio dei nomi in cui sono presenti le tue risorse Ingress. Notare che tutte le lettere nel nome dell'istanza del servizio devono essere specificate in minuscolo.

   ibmcloud ks cluster service bind --cluster <cluster_name_or_ID> --namespace <namespace> --service <App_ID_service_instance_name> [--key <service_instance_key>]
   

   Quando il servizio viene collegato al cluster, viene creato un segreto del cluster che contiene le credenziali dell'istanza del servizio. Output della CLI di esempio:

   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. Abilitare il componente aggiuntivo ALB OAuth Proxy nel cluster. Questo componente aggiuntivo crea e gestisce le seguenti risorse Kubernetes: una distribuzione OAuth2-Proxy per l'istanza del servizio App ID, un segreto che contiene la configurazione della distribuzione OAuth2-Proxy e una risorsa Ingress che configura gli ALB per instradare le richieste in entrata alla distribuzione OAuth2-Proxy per la tua istanza App ID. Il nome di ciascuna di queste risorse inizia con oauth2-.

   1. Abilitare il componente aggiuntivo alb-oauth-proxy.

      ibmcloud ks cluster addon enable alb-oauth-proxy --cluster <cluster_name_or_ID>
      

   2. Verificare che il componente aggiuntivo ALB OAuth Proxy abbia uno stato di Addon Ready.

      ibmcloud ks cluster addon ls --cluster <cluster_name_or_ID>
      

5. Nelle risorse Ingress per le applicazioni dove vuoi aggiungere l'autenticazione App ID, assicurati che il nome della risorsa non superi i 25 caratteri di lunghezza. Quindi, aggiungere le seguenti annotazioni alla sezione metadata.annotations.

   1. Aggiungi la seguente annotazione auth-url. Questa annotazione specifica l' URL e dell' OAuth2-Proxy e per la tua istanza di App ID, che funge da OIDC Relying Party (RP) per App ID. Notare che tutte le lettere nel nome dell'istanza del servizio devono essere specificate in minuscolo.

      ...
      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. A volte il cookie di autenticazione utilizzato da OAuth2-Proxy supera i 4 KB. Quindi è diviso in due parti. Il seguente frammento deve essere aggiunto per garantire che entrambi i cookie possano essere aggiornati correttamente da OAuth2-Proxy.

      ...
      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. Scegli quali token inviare nell'intestazione Authorization alla tua applicazione. Per ulteriori informazioni su ID e token di accesso, consulta la documentazione diApp ID.

      • Per inviare solo ID Token, aggiungere la seguente annotazione:

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

      • Per inviare solo Access Token, aggiungere le seguenti informazioni all'annotazione configuration-snippet. (Questo estende il frammento dal passo 5.2.)

        ...
        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
            }
        ...
        

      • Per inviare Access Token e ID Token, aggiungere le seguenti informazioni all'annotazione configuration-snippet. (Questo estende il frammento dal passo 5.2.)

        ...
         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. Facoltativo: se la tua applicazione supporta la strategia dell'applicazione Web in aggiunta o al posto della strategia API, aggiungi l'annotazione nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2-<App_ID_service_instance_name>/start?rd=$escaped_request_uri. Nota che tutte le lettere nel nome dell'istanza del servizio devono essere in minuscolo.

      • Se si specifica questa annotazione e l'autenticazione per un client fallisce, il client viene reindirizzato all' URL dell' OAuth2-Proxy per l'istanza App ID. Questo OAuth2-Proxy, che funge da OIDC Relying Party (RP) per App ID, reindirizza il client alla pagina di accesso di App ID per l'autenticazione.
      • Se non specifichi questa annotazione, un client deve autenticarsi con un token di connessione valido. Se l'autenticazione per un client non riesce, la richiesta del client viene rifiutata con un messaggio di errore 401 Unauthorized.

6. Riapplica le tue risorse Ingress per applicare l'autenticazione App ID. Una volta riapplicata una risorsa Ingress con le annotazioni appropriate, il componente aggiuntivo ALB OAuth Proxy distribuisce una distribuzione OAuth2-Proxy, crea un servizio per la distribuzione e crea una risorsa Ingress separata per configurare l'instradamento per i messaggi di distribuzione OAuth2-Proxy. Non eliminare queste risorse aggiuntive.

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

7. Verifica che l'autenticazione App ID sia applicata per le tue applicazioni.

   • Se le tue app supportano la strategia delle app web: accedi all' URL e della tua app in un browser web. Se l' App ID viene applicato correttamente, si viene reindirizzati a una pagina di accesso per l'autenticazione App ID.
   • Se le tue applicazioni supportano la Strategia API: specifica il tuo token di accesso Bearer nell'intestazione di autorizzazione delle richieste alle applicazioni. Per ottenere il token di accesso, consulta la documentazione diApp ID. Se App ID è applicato correttamente, la richiesta viene autenticata correttamente e viene instradata alla tua applicazione. Se invii richieste alle tue applicazioni senza un token di accesso nell'intestazione Authorization o se il token di accesso non è accettato da App ID, la richiesta viene rifiutata.

8. Opzionale: se si utilizzano i criteri di rete o un'altra soluzione firewall sul cluster per limitare il traffico in uscita, è necessario assicurarsi di consentire l'accesso al servizio pubblico AppID's dal cluster. Per ottenere l'intervallo di indirizzi IP per questo servizio, inoltrare una richiesta tramite l'assistenza clienti.

9. Facoltativo: puoi personalizzare il funzionamento predefinito di OAuth2-Proxy creando una ConfigMap Kubernetes.

   1. Creare un file YAML ConfigMap che specifica i valori per le impostazioni OAuth2-Proxy che si desidera modificare.

      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. Applicare la risorsa ConfigMap al componente aggiuntivo. Le modifiche vengono applicate automaticamente.

      kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
      

Per l'elenco delle modifiche per ogni versione del componente aggiuntivo ALB OAuth Proxy, consulta il IBM Cloud ALB OAuth Proxy.

Conservazione dell'indirizzo IP di origine

Per impostazione predefinita, gli indirizzi IP di origine delle richieste client non sono conservati dall'ALB Ingress. Per preservare gli indirizzi IP di origine, puoi abilitare il protocollo PROXY nei cluster VPC o modificare il externalTrafficPolicy nei cluster classici.

Configurazione di protocolli SSL e cifrature SSL a livello di HTTP

Abilitare i protocolli e i cifrari SSL a livello globale HTTP modificando il file ibm-k8s-controller-config ConfigMap.

Ad esempio, se hai ancora dei client legacy che richiedono il supporto TLS 1.0 o 1.1, devi abilitare manualmente queste versioni TLS per sovrascrivere l'impostazione predefinita dei soli TLS 1.2 e TLS 1.3.

Quando specifichi i protocolli abilitati per tutti gli host, i parametri TLSv1.1 e TLSv1.2 (1.1.13, 1.0.12) funzionano solo se viene utilizzato OpenSSL 1.0.1 o superiore. Il parametro TLSv1.3 (1.13.0) funziona solo quando viene utilizzato OpenSSL 1.1.1 sviluppato con il supporto TLSv1.3.

Per modificare la mappa di configurazione per l'abilitazione di protocolli e cifrature SSL:

1. Modificare il file di configurazione della risorsa ibm-k8s-controller-config ConfigMap.

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

2. Aggiungi i protocolli e le cifrature SSL. Formattare i cifrari in base al formato dell'elenco dei cifrari della libreria 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. Salva il file di configurazione.

4. Verifica che le modifiche alla mappa di configurazione siano state applicate. Le modifiche vengono applicate automaticamente ai tuoi ALB.

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

Invio del tuo certificato personalizzato ai client legacy

Se si dispone di dispositivi legacy che non supportano la Server Name Indication (SNI) e si utilizza un certificato TLS personalizzato nelle risorse di Ingress, è necessario modificare le impostazioni del server dell'ALB per utilizzare il certificato TLS personalizzato e il segreto TLS personalizzato.

Quando crei un cluster classico, viene generato un certificato Let's Encrypt per il segreto Ingress predefinito fornito da IBM. Se crei un segreto personalizzato nel tuo cluster e lo specifichi per la terminazione TLS nelle tue risorse Ingress, l'ALB Ingress invia al client il certificato per il tuo segreto personalizzato invece del certificato Let's Encrypt predefinito. Tuttavia, se un client non supporta SNI, l'impostazione predefinita dell'ALB Ingress è il certificato Let's Encrypt in quanto il segreto predefinito viene elencato nelle impostazioni server predefinite dell'ALB. Per inviare il certificato personalizzato a dispositivi che non supportano l'SNI, completare i passaggi seguenti per modificare le impostazioni del server predefinito dell'ALB con il segreto personalizzato.

I certificati Let' s Encrypt generati per impostazione predefinita non sono destinati all'utilizzo in produzione. Per i carichi di lavoro di produzione, porta il tuo certificato personalizzato.

1. Modifica la risorsa Ingress alb-default-server.

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

2. Nella sezione spec.tls, modifica il valore dell'impostazione hosts.secretName con il nome del tuo segreto personalizzato che contiene il tuo certificato personalizzato. Esempio:

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

3. Salva il file di risorse.

4. Verifica che ora la risorsa punti al nome del tuo segreto personalizzato. Le modifiche vengono applicate automaticamente ai tuoi ALB.

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

Gestione fine delle connessioni

Le impostazioni client-header-timeout, client-body-timeout e keep-alive sono configurazioni cruciali che dettano il tempo in cui le connessioni rimangono attive tra i client, il controller Ingress e i server backend. Questi timeout svolgono un ruolo importante nell'ottimizzazione della gestione delle richieste, in particolare quando si tratta di connessioni client di lunga durata, di risposte ritardate dai server di backend e di salvaguardare risorse preziose dall'essere occupate inutilmente.

client-header-timeout definisce il tempo massimo di attesa del server per un'intestazione completa del client. Allo stesso modo, client-body-timeout indica la durata dell'attesa del server per l'invio del corpo della richiesta da parte del client. Entrambi i timeout devono essere in linea con il parametro keep-alive, che regola il tempo in cui il server mantiene aperta la connessione in attesa di ulteriori richieste. Se questi timeout non coincidono con l'impostazione keep-alive, NGINX termina la connessione, il che potrebbe portare a un comportamento inatteso del client o al fallimento della richiesta.

È possibile impostare i parametri di cui sopra nello spazio dei nomi ibm-k8s-controller-config ConfigMap kube-system.

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"

Per ulteriori informazioni, consultare la sezione client-header-timeout, client-body-timeout e keep-alive nella documentazione di Ingress Nginx.

Ottimizzazione delle prestazioni ALB

Per ottimizzare le prestazioni dei tuoi ALB Ingress, puoi modificare le impostazioni predefinite in base alle tue necessità.