Aggiunta di una porta del server a un'intestazione host

Per aggiungere una porta del server alla richiesta del client prima che la richiesta sia inoltrata all'applicazione di back-end, configurare un proxy ai servizi esterni in un' annotazione dello snippet del server o come campo di 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

Configurare Ingress con IBM Cloud App ID per imporre l'autenticazione alle proprie applicazioni modificando specifici campi di Kubernetes Ingress. Per ulteriori informazioni, vedere Aggiunta dell'autenticazione App ID alle app.

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, utilizzare la seguente annotazione della risorsa Kubernetes Ingress.

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 azioni personalizzate che l'ALB può intraprendere per specifici errori di 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 ciascun servizio ALB con i seguenti campi Kubernetes Ingress ibm-ingress-deploy-config ConfigMap.

Impostazione campo di esempio.

httpPort=8080
httpsPort=8443

Personalizzazione dell'intestazione della richiesta

Per aggiungere informazioni di intestazione a una richiesta del client prima di inoltrarla all'applicazione back-end, utilizzare il seguente campodella mappa di configurazione Kubernetes ibm-k8s-controller-config

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 percorso ai servizi esterni

Per aggiungere definizioni di percorso a servizi esterni, come quelli ospitati in IBM Cloud, configurare un proxy ai servizi esterni in uno snippet di localizzazione. In alternativa, sostituire il proxy con un reindirizzamento permanente ai servizi esterni.

Reindirizzamento delle richieste non sicure

Per impostazione predefinita, le richieste insicure del client HTTP 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 è abilitata per impostazione predefinita.

• Per aggiungere l'età massima e la granularità del sottodominio, consultare 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 possono essere servite attraverso una connessione keepalive, utilizzare 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 la configurazione di Ingress è stata migrata da IBM Cloud Kubernetes Service Ingress a Kubernetes Ingress, potrebbe essere necessario modificare keep-alive-requests per superare i test di prestazione esistenti.

Impostazione di un timeout massimo di richiesta keepalive

Per impostare il tempo massimo in cui una connessione keepalive rimane aperta tra il client e il server proxy ALB, utilizzare 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 e la dimensione massima dei buffer che leggono le intestazioni delle richieste dei client di grandi dimensioni, utilizzare 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 confronta l'URI della richiesta con il percorso dell'applicazione, utilizzare la seguente annotazione della risorsa Kubernetes Ingress.

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 personalizzata del blocco di localizzazione per un servizio, utilizzare la seguente annotazione della risorsa Kubernetes Ingress.

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, utilizzare le seguenti annotazioni della risorsa Kubernetes Ingress. Si noti che la mutua autenticazione 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 del proxy che legge la prima parte della risposta, utilizzare la seguente annotazione della risorsa Kubernetes Ingress.

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

Configurazione dei numeri di buffer proxy

Per configurare il numero di buffer proxy per l'ALB, utilizzare la seguente annotazione della risorsa Kubernetes Ingress.

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, consultare i documenti di NGINX.

Configurazione quando un ALB può passare una richiesta

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

• 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 al client dall'applicazione back-end prima che la risposta venga inviata al client. Configurare la rimozione dell'intestazione della risposta in uno snippet di localizzazione, oppure utilizzare il campo proxy_hide_header come snippet di configurazione nel file ibm-k8s-controller-config ConfigMap.

Riscrittura dei percorsi

Per instradare il traffico di rete in arrivo su un percorso del dominio ALB verso un percorso diverso su cui l'applicazione back-end è in ascolto, utilizzare la seguente annotazione della risorsa Kubernetes Ingress.

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

Personalizzare le configurazioni dei blocchi del server

Per aggiungere una configurazione personalizzata del blocco server, utilizzare la seguente annotazione della risorsa Kubernetes Ingress.

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 entrata verso lo stesso server upstream utilizzando un cookie appiccicoso, utilizzare le seguenti annotazioni della risorsa Kubernetes Ingress.

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 controllore di ingress Kubernetes aggiunge gli attributi Secure e HttpOnly ai cookie appiccicosi per impostazione predefinita, che non può essere modificata.

Consentire il supporto dei servizi di SSL per crittografare il traffico

Per consentire il supporto dei servizi SSL per crittografare il traffico verso le applicazioni upstream che richiedono HTTPS, utilizzare la risorsa Kubernetes Ingress annotazione del protocollo del backend e annotazioni di autenticazione del certificato di 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 applicazioni con porte non standard TCP

Per accedere a un'applicazione tramite una porta non standard TCP, procedere come segue.

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

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

2. Creare l' ConfigMap e nel namespace 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 servite attraverso una connessione keepalive, utilizzare 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 in cui una connessione keepalive rimane aperta tra il server proxy ALB e il server upstream dell'applicazione, utilizzare il seguente campo Kubernetes ibm-k8s-controller-config configmap.

upstream-keepalive-timeout: 32

Personalizzazione della distribuzione ALB

Personalizzare la distribuzione per gli ALB che eseguono l'immagine Kubernetes Ingress creando un'immagine 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`.
   
   ```sh {: pre}
       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

Applicate l'autenticazione per le vostre applicazioni configurando Ingress con IBM Cloud App ID.

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

   Un'istanza di App ID può essere utilizzata in un solo spazio dei nomi del cluster. Se si desidera configurare App ID per le risorse di Ingress in più spazi dei nomi, ripetere i passaggi di questa sezione per specificare un'istanza App ID unica per le risorse di Ingress in ogni 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 un nome univoco a tua scelta 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 verrà autenticato, ma gli verrà rilasciato un token di accesso per l'accesso anonimo all'app.
   3. Nella scheda " Impostazioni di autenticazione ", aggiungi gli URL di reindirizzamento per la tua app 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 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 vuole utilizzare una pagina di logout personalizzata, è necessario impostare whitelist_domains nel campo 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; in alternativa, è possibile includere l'opzione --key per utilizzare le credenziali della chiave di servizio già esistenti. 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]
   

   Una volta che il servizio è stato associato correttamente 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: un'installazione client OAuth2-Proxy per l'istanza di servizio App ID, un segreto che contiene la configurazione dell'installazione client OAuth2-Proxy e una risorsa Ingress che configura gli ALB per instradare le richieste in arrivo all'installazione client OAuth2-Proxy per l'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 lo stato del componente aggiuntivo “ALB OAuth Proxy” sia “ `Addon Ready` ”.
   ```sh {: pre}
       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`.
   ```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. Scegli quali token inviare nell'intestazione `Authorization` alla tua applicazione. Per ulteriori informazioni su ID e token di accesso, consulta la [documentazione diApp ID](/docs/appid?topic=appid-tokens){: external}.
       * Per inviare solo `ID Token`, aggiungere la seguente annotazione:
   
           ```yaml {: codeblock}
           ...
           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.)
   
           ```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
               }
           ...
           ```
       * Per inviare `Access Token` e `ID Token`, aggiungere le seguenti informazioni all'annotazione `configuration-snippet`. (Questo estende il frammento dal passo 5.2.)
           ```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. Facoltativo: se la tua applicazione supporta la [strategia dell'applicazione Web](/docs/appid?topic=appid-key-concepts#term-web-strategy) in aggiunta o al posto della [strategia API](/docs/appid?topic=appid-key-concepts#term-api-strategy), 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. Dopo aver riapplicato una risorsa di 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 di Ingress separata per configurare l'instradamento dei messaggi della 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.
   ```sh {: pre}
       kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
       ```
   

Per l'elenco delle modifiche apportate a ciascuna versione del componente aggiuntivo ALB OAuth Proxy, consultare il registro delle modifiche del componente aggiuntivo 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 gli algoritmi di crittografia " 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. Modifica 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 codici di cifratura secondo il formato dell'elenco dei codici di cifratura 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 disponi di dispositivi legacy che non supportano la Server Name Indication (SNI) e utilizzi un certificato personalizzato TLS nelle tue risorse Ingress, devi modificare le impostazioni del server ALB per utilizzare il tuo certificato personalizzato TLS e il tuo segreto personalizzato TLS.

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 ai dispositivi che non supportano SNI, segui questi passaggi per modificare le impostazioni predefinite del server ALB in modo da utilizzare il tuo 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 delle richieste.

È possibile impostare questi parametri nel file ibm-k8s-controller-config ConfigMap, nello spazio dei nomi 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à.