Aggiunta di una porta del server all'intestazione dell'host

Per impostazione predefinita, Traefik gestisce l'intestazione Host in modo compatibile con la maggior parte delle app moderne. Si sconsiglia di modificare l'intestazione Host per includervi una porta. Prima di apportare qualsiasi modifica, verifica come Traefik gestisce l'intestazione per impostazione predefinita e cerca di capire in quali casi è opportuno sovrascriverla.

Gestione predefinita dell'intestazione " Host "

Traefik inoltra per impostazione predefinita l'intestazione originale " Host " con passHostHeader: true. Aggiunge automaticamente le seguenti intestazioni di inoltro separate, invece di incorporare la porta nell'intestazione " Host ":

• X-Forwarded-Host

• X-Forwarded-Port

Sovrascrittura dell'intestazione " Host " per le app legacy

Se la tua app richiede la porta incorporata nell'intestazione " Host ", utilizza Traefik Header e middleware per sovrascriverla.

# Example (Kubernetes Middleware)
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-header
spec:
  headers:
    customRequestHeaders:
      Host: "legacy-app.example:8080"

Applica il middleware alla tua risorsa Ingress utilizzando l'annotazione Traefik Ingress. Assicurarsi che l'elaborazione CRD sia abilitata (impostazione predefinita). Per configurare l'elaborazione dei CRD, consultare la guida " ibm-ingress-deploy-config ConfigMap processTraefikCRDs campo".

Instradamento delle richieste in entrata tramite un ALB privato

Per impostazione predefinita, gli ALB pubblici elaborano le risorse Ingress. Per instradare invece le richieste in entrata attraverso un ALB privato, specifica la classe private-iks-traefik nel campo spec.ingressClassName della tua risorsa Ingress.

spec.ingressClassName: "private-iks-traefik"

Autenticazione delle app con App ID

Configurare Traefik Ingress con IBM Cloud App ID per applicare l'autenticazione alle tue app. Per ulteriori informazioni, consulta la sezione " Aggiunta dell'autenticazion App ID e alle app ".

Impostazione della dimensione massima del corpo della richiesta del client

Per impostazione predefinita, Traefik non impone alcun limite alle dimensioni del corpo delle richieste dei client. Per impostare un limite massimo, crea un middleware di buffering e applicalo alla tua risorsa Ingress.

Traefik respinge qualsiasi richiesta che superi il limite configurato con una risposta 413 " HTTP ".

1. Crea una risorsa "Traefik Buffering Middleware ". Imposta il parametro " maxRequestBodyBytes " sul numero massimo di byte che il client può inviare. L'esempio seguente imposta un limite di 2 MB (2097152 byte).

   # Example (Kubernetes Middleware)
   apiVersion: traefik.io/v1alpha1
   kind: Middleware
   metadata:
     name: limit
   spec:
     buffering:
       maxRequestBodyBytes: 2097152
   

2. Applica il middleware alla tua risorsa Ingress utilizzando l'annotazione Traefik Ingress.

Abilitazione del buffering dei dati di risposta dei client

Per impostazione predefinita, Traefik trasmette le risposte direttamente senza buffer. Grazie al middleware di buffering, Traefik può memorizzare le risposte in memoria o salvarle su disco prima di inviarle al client. Utilizza questo middleware solo se la tua app lo richiede, poiché nella maggior parte dei casi il buffering delle risposte non è consigliato.

Per abilitare il buffering delle risposte, procedere come segue:

1. Crea una risorsa "Traefik Buffering Middleware ". Impostare maxResponseBodyBytes sulla dimensione massima della risposta in byte e memResponseBodyBytes sulla soglia oltre la quale la risposta viene scritta su disco anziché essere mantenuta in memoria. L'esempio seguente memorizza in buffer fino a 5 MB in totale, di cui il primo 1 MB viene mantenuto in memoria.

   # Example (Kubernetes Middleware)
   apiVersion: traefik.io/v1alpha1
   kind: Middleware
   metadata:
     name: response-buffer
   spec:
     buffering:
       maxResponseBodyBytes: 5242880    # 5 MB max response size
       memResponseBodyBytes: 1048576    # 1 MB in memory, then disk
   

2. Applica il middleware alla tua risorsa Ingress utilizzando l'annotazione Traefik Ingress.

Regolazione dei timeout

Traefik mette a disposizione due tipi di impostazioni relative ai timeout: i timeout tra il client e l'ALB e quelli tra l'ALB e l'applicazione back-end. Configurali separatamente a seconda di dove si trova il collo di bottiglia.

Per impostare i timeout tra il client e l'ALB, configurare i campi corrispondenti in ibm-ingress-deploy-config ConfigMap:

• Per configurare il tempo di attesa di una richiesta in entrata su HTTP o HTTPS prima che l'istanza di Traefik risponda, utilizzare i campi httpReadTimeout e httpsReadTimeout.
• Per configurare la durata massima prima che la risposta scada, utilizzare i campi “ httpWriteTimeout ” e “ httpsWriteTimeout ”.
• Per configurare la durata massima durante la quale una connessione keepalive rimane aperta prima di chiudersi, utilizzare i campi " httpIdleTimeout " e " httpsIdleTimeout ".

Per impostare il timeout di connessione e di lettura tra l'ALB e l'applicazione back-end, utilizzare ServersTransport per configurare il trasporto tra Traefik e i tuoi server HTTP.

# Example (Kubernetes ServersTransport)
apiVersion: traefik.io/v1alpha1
kind: ServersTransport
metadata:
  name: mytransport
spec:
  forwardingTimeouts:
    dialTimeout: 30s
    responseHeaderTimeout: 10s
    idleConnTimeout: 90s

Per i cluster VPC, è inoltre necessario modificare il timeout di inattività delle connessioni sul servizio di bilanciamento del carico che espone l'ALB pubblico. Sostituisci CLUSTER_ID con l'ID del tuo cluster, che puoi recuperare eseguendo il comando ibmcloud ks cluster get --cluster CLUSTER_NAME_OR_ID. L'esempio seguente imposta il timeout a 910 secondi:

kubectl annotate svc -n kube-system public-cr<clusterid> service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout="910"

Traefik supporta il valore " 0 " per i propri timeout, che disabilita il timeout stesso.

L'annotazione " ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout " sul bilanciatore di carico VPC non supporta il valore zero. È possibile impostare un valore di timeout compreso tra 50 secondi e 7200 secondi (2 ore). Se hai bisogno di un valore superiore a 2 ore, apri una richiesta di assistenza e fornisci la motivazione aziendale.

Se i cluster sono esposti tramite IBM Cloud Internet Services (CIS) o Cloudflare con il Web Application Firewall (WAF) o il bilanciamento del carico globale abilitato, impostare questi timeout su un valore superiore a 900 secondi. Per ulteriori informazioni, consulta la documentazione di Cloudflare.

Dopo aver creato la risorsa ServersTransport , applicala alla tua risorsa Service utilizzando l'annotazione Traefik Service.

Personalizzazione delle azioni in caso di errore

Per specificare le azioni personalizzate che l’ALB può intraprendere in caso di errori specifici di HTTP, configurare il parametro Traefik Errori nel middleware. Dopo aver creato il middleware, applicalo alla tua risorsa Ingress utilizzando l'annotazione Traefik Ingress.

Modifica delle porte predefinite HTTP e HTTPS

Per impostazione predefinita, gli ALB ascoltano sulla porta 80 per HTTP e sulla porta 443 per HTTPS. Se il cluster richiede porte non standard, è possibile modificare questi valori per ciascun ALB utilizzando i campi “ httpPort ” e “ httpsPort ” nella pagina “ ibm-ingress-deploy-config ” ConfigMap.

Personalizzazione dell'intestazione della richiesta

Utilizza l'Header e middleware e di Traefik per aggiungere, sovrascrivere o rimuovere i campi di intestazione da una richiesta del client prima di inoltrarla alla tua applicazione back-end. Ciò è utile per inserire informazioni di contesto quali nomi di script, identificatori di tenant o altri metadati richiesti dall'app.

# Example (Kubernetes Middleware)
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-header
spec:
  headers:
    customRequestHeaders:
      X-Script-Name: "test"

Dopo aver creato il middleware, applicalo alla tua risorsa Ingress utilizzando l'annotazione Traefik Ingress.

Personalizzazione dell'intestazione della risposta

Utilizza il middleware "Headers " di Traefik per aggiungere, sovrascrivere o rimuovere i campi di intestazione da una risposta prima di inviarla al client. Ciò è utile per applicare le politiche di sicurezza, aggiungere intestazioni CORS o rimuovere le intestazioni interne prima che raggiungano il client.

# Example (Kubernetes Middleware)
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-header
spec:
  headers:
    customResponseHeaders:
      X-Custom-Response-Header: "value"

Dopo aver creato il middleware, applicalo alla tua risorsa Ingress utilizzando l'annotazione Traefik Ingress.

Reindirizzamento delle richieste non sicure

Per garantire l'accesso esclusivamente tramite HTTPS e reindirizzare in modo permanente tutte le richieste in entrata a HTTP all'endpoint HTTPS, impostare il campo httpsRedirect nel ibm-ingress-deploy-config ConfigMap.

Attivazione e disattivazione della sicurezza rigorosa del trasporto ( HTTP )

HTTP La funzione "Strict Transport Security" ( HSTS ) impone ai browser di accedere a un dominio esclusivamente tramite HTTPS, impedendo così gli attacchi di downgrade del protocollo. Questa funzionalità è attivabile su richiesta per Traefik. Per abilitarlo, utilizzare il middleware Headers con i campi stsSeconds, stsIncludeSubdomains e stsPreload.

# Example (Kubernetes Middleware) - produces: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: security-headers
spec:
  headers:
    stsSeconds: 31536000            # max-age=1 year
    stsIncludeSubdomains: true
    stsPreload: true

Applica il middleware alla tua risorsa Ingress utilizzando la seguente annotazione Traefik Ingress.

Modifica delle modalità con cui l'ALB abbina l'URI della richiesta

Per impostazione predefinita, Traefik utilizza il matcher “ PathPrefix ” per instradare le richieste. Se la tua app richiede la corrispondenza esatta del percorso o un routing basato su espressioni regolari, sovrascrivi il matcher utilizzando la seguente annotazione Ingress di Traefik.

traefik.ingress.kubernetes.io/router.pathmatcher: PathRegexp

Configurazione dell'autenticazione reciproca

L'autenticazione reciproca ( TLS ) ( mTLS ) richiede che sia il server che il client presentino certificati validi, garantendo un'autenticazione più sicura rispetto al protocollo standard TLS. Per richiedere l'autenticazione tramite certificato client sul proprio ALB, creare una risorsa TLSOption che faccia riferimento al segreto del certificato CA.

# Example (Kubernetes TLSOption)
apiVersion: traefik.io/v1alpha1
kind: TLSOption
metadata:
  name: mtls
  namespace: default
spec:
  minVersion: VersionTLS12
  clientAuth:
    secretNames:
      - my-ca-secret
    clientAuthType: RequireAndVerifyClientCert

Dopo aver creato la risorsa TLSOption, applicala alla tua risorsa Ingress utilizzando l'annotazione Traefik Ingress.

Configurazione del comportamento dei tentativi di ripetizione per le richieste a monte

Quando un server back-end non risponde, Traefik può riprovare automaticamente a inviare la richiesta a un altro server upstream. Configurare il comportamento dei tentativi di ricarica utilizzando il file [Middleware di riprova](https://doc.traefik.io/traefik/reference/routing-configuration/http/middlewares/retry/){: external} di Traefik. Dopo aver creato il middleware, applicalo alla tua risorsa Ingress utilizzando l'annotazione Traefik Ingress.

Limitazione della frequenza

La limitazione della frequenza protegge le tue applicazioni back-end dai picchi di traffico e dagli abusi, limitando il numero di richieste elaborate dall'ALB in un determinato intervallo di tempo. Configurare la limitazione della velocità utilizzando il plugin Traefik RateLimit Middleware. Dopo aver creato il middleware, applicalo alla tua risorsa Ingress utilizzando l'annotazione Traefik Ingress.

Riscrittura dei percorsi

La riscrittura dei percorsi consente di esporre un percorso pubblico URL diverso da quello su cui è in ascolto l'applicazione back-end. Ad esempio, è possibile reindirizzare le richieste in arrivo su /app verso un'applicazione back-end che ascolta su /. Utilizza una delle seguenti risorse di Traefik a seconda che tu abbia bisogno di una sostituzione fissa o di una sostituzione basata su pattern:

• La risorsa " ReplacePath Middleware " di Traefik
• La risorsa " ReplacePathRegex Middleware " di Traefik

# Example Replace the path with /foo
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-replacepath
spec:
  replacePath:
    path: "/foo"

# Example Replace path with regex
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-replacepathregex
spec:
  replacePathRegex:
    regex: "^/foo/(.*)"
    replacement: "/bar/$1"

Applica il middleware alla tua risorsa Ingress utilizzando la seguente annotazione Traefik Ingress.

Instradamento del traffico con cookie “sticky”

Le sessioni "sticky" garantiscono che le richieste di un client vengano sempre indirizzate allo stesso server back-end per tutta la durata della sessione. Ciò è utile per le applicazioni con stato che memorizzano i dati di sessione localmente sul server. Abilita le sessioni persistenti configurando l'annotazione "sticky cookie " del servizio Traefik sulla tua risorsa Ingress.

Crittografia del traffico tra la tua app e l'ALB

Per impostazione predefinita, Traefik inoltra il traffico all'applicazione back-end tramite il protocollo HTTP. Se la tua app richiede connessioni upstream crittografate, utilizza una ServersTransport risorsa per configurare TLS tra l'ALB e la tua app, includendo il certificato CA e il nome del server previsto.

# Example (Kubernetes ServersTransport)
apiVersion: traefik.io/v1alpha1
kind: ServersTransport
metadata:
  name: backend-transport
spec:
  rootCAs:
    - secret: my-ca-cert
  serverName: <myapp.example.com> # must match your certificate

Applica l'annotazione " ServersTransport " alla tua risorsa Service utilizzando la seguente annotazione Traefik Service.

Personalizzazione della distribuzione dell'ALB

Il file ibm-ingress-deploy-config ConfigMap controlla le impostazioni a livello di ALB, quali il numero di repliche, le porte, il livello di log, i valori di timeout e il provider di ingresso. Utilizza questo ConfigMap per applicare le modifiche di configurazione a uno o più ALB del tuo cluster senza modificare le singole risorse Ingress.

1. Ottieni i nomi dei servizi esposti da ciascun ALB. Prendi nota dei nomi dei servizi, poiché li utilizzerai nei passaggi successivi.

   • Cluster classici:

       kubectl get svc -n kube-system | grep alb
       ```
   * Cluster VPC: nell'output, cerca un nome di servizio con un formato simile a `public-crc204dl7w0qf6n6sp7tug`.
   
   ```sh {: pre}
       kubectl get svc -n kube-system | grep LoadBalancer
       ```
   

2. Crea un file YAML per una mappa di configurazione ibm-ingress-deploy-config. Per ogni ID ALB, è possibile specificare una o più delle seguenti impostazioni opzionali. È sufficiente includere solo le impostazioni che si desidera configurare.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-ingress-deploy-config
     namespace: kube-system
   data:
     <alb1-id>: '{"replicas":<number_of_replicas>, "ingressClass":"<class>", "httpsPort":"<port>", "httpPort":"<port>", "logLevel": "<TRACE|DEBUG|INFO|WARN|ERROR|FATAL|PANIC>", "ingressProvider": "<ingress|ingress-nginx>", "processTraefikCRDs": <true|false>, "traefikIngressNginxAllowExternalNameServices": <true|false>, "traefikCRDAllowCrossNamespace": <true|false>, "traefikCRDAllowExternalNameServices": <true|false>, "httpReadTimeout": <seconds>, "httpWriteTimeout": <seconds>, "httpIdleTimeout": <seconds>, "httpsReadTimeout": <seconds>, "httpsWriteTimeout": <seconds>, "httpsIdleTimeout": <seconds>, "httpsRedirect": <true|false>, "customEntryPoints": {"<name>": {"port": <port>, "protocol": "<TCP|UDP>", "readTimeout": <seconds|0>, "writeTimeout": <seconds|0>, "idleTimeout": <seconds|0>, "udpTimeout": <seconds>}}, "tolerations": [{"key":"<key>","operator":"<Equal|Exists>","value":"<value>","effect":"<NoSchedule|PreferNoSchedule|NoExecute>"}]}'
     <alb2-id>: '{"replicas":<number_of_replicas>, "ingressClass":"<class>", "httpsPort":"<port>", "httpPort":"<port>", "logLevel": "<TRACE|DEBUG|INFO|WARN|ERROR|FATAL|PANIC>", "ingressProvider": "<ingress|ingress-nginx>", "processTraefikCRDs": <true|false>, "traefikIngressNginxAllowExternalNameServices": <true|false>, "traefikCRDAllowCrossNamespace": <true|false>, "traefikCRDAllowExternalNameServices": <true|false>, "httpReadTimeout": <seconds>, "httpWriteTimeout": <seconds>, "httpIdleTimeout": <seconds>, "httpsReadTimeout": <seconds>, "httpsWriteTimeout": <seconds>, "httpsIdleTimeout": <seconds>, "httpsRedirect": <true|false>, "customEntryPoints": {"<name>": {"port": <port>, "protocol": "<TCP|UDP>", "readTimeout": <seconds|0>, "writeTimeout": <seconds|0>, "idleTimeout": <seconds|0>, "udpTimeout": <seconds>}}, "tolerations": [{"key":"<key>","operator":"<Equal|Exists>","value":"<value>","effect":"<NoSchedule|PreferNoSchedule|NoExecute>"}]}'
   

   replicas

   Per impostazione predefinita, ogni ALB dispone di due repliche. Amplia le capacità di elaborazione degli ALB aumentando il numero di pod ALB. Per ulteriori informazioni, consultare la sezione " Aumentare il numero di repliche dei pod ALB ".

   ingressClass

   Se nella risorsa Ingress hai specificato una classe diversa da public-iks-traefik o private-iks-traefik, inserisci qui il nome della classe.

   httpPort, httpsPort

   Rendere accessibili le porte non predefinite per l'ALB Ingress aggiungendo le porte HTTP o HTTPS che si desidera aprire.

   Valori predefiniti: 80/443.

   logLevel

   Specificare il livello di registrazione. Scegli tra: TRACE, DEBUG, INFO, WARN, ERROR, FATAL, PANIC.

   Impostazione predefinita: INFO.

   ingressProvider

   Specificare quale provider Ingress di Traefik utilizzare per questo ALB. Valori validi:

   ingress: Utilizza il controller di ingresso proprio di Traefik. Elabora le annotazioni specifiche di Traefik sulle risorse Ingress.

   ingress-nginx: Utilizza un file temporaneo Livello di compatibilità per Ingress -NGINX in Traefik. Elabora le annotazioni create per Ingress ( NGINX ) e, quando possibile, riproduce il comportamento di Ingress ( NGINX ). Utilizza questo valore per facilitare la migrazione da Ingress ( NGINX ) a Traefik.

   Impostazione predefinita: ingress.

   processTraefikCRDs

   Quando è impostato su “ true ”, Traefik elabora le proprie risorse CRD oltre a quelle di Ingress. I CRD supportati includono IngressRoute, Middleware e TLSOption. Per l'elenco completo, consultare la documentazione di Traefik sui CRD.

   Impostazione predefinita: true.

   traefikIngressNginxAllowExternalNameServices

   Abilita il supporto per i servizi " ExternalName " per gli oggetti Ingress elaborati dal provider ingress-nginx. Questa opzione è valida solo se l'opzione " ingressProvider " è impostata su " ingress-nginx".

   Impostazione predefinita: true.

   traefikCRDAllowCrossNamespace

   Consente alle risorse " IngressRoute " (Traefik CRD) di fare riferimento a risorse presenti in altri spazi dei nomi.

   Impostazione predefinita: false.

   traefikCRDAllowExternalNameServices

   Consente alle risorse di “ IngressRoute ” (Traefik CRD) di fare riferimento ai servizi di “ ExternalName ”.

   Impostazione predefinita: false.

   httpReadTimeout, httpsReadTimeout

   Configura il timeout di lettura HTTP / HTTPS tra l'ALB e il client. Il valore deve essere un numero intero di secondi; impostandolo su zero si disattiva il timeout.

   Per ulteriori informazioni, consultare la documentazione di Traefik.

   httpWriteTimeout, httpsWriteTimeout

   Configura il timeout di scrittura HTTP / HTTPS tra l'ALB e il client. Il valore deve essere un numero intero di secondi; impostandolo su zero si disattiva il timeout.

   Per ulteriori informazioni, consultare la documentazione di Traefik.

   httpIdleTimeout, httpsIdleTimeout

   Configura il timeout di inattività (keepalive) HTTP / HTTPS tra l'ALB e il client. Il valore deve essere un numero intero di secondi; impostandolo su zero si disattiva il timeout.

   Per ulteriori informazioni, consultare la documentazione di Traefik.

   Se si utilizza IBM Cloud Internet Services (CIS) o Cloudflare con il Web Application Firewall (WAF) o il bilanciamento del carico globale, impostare questo valore su un valore superiore a 900 secondi. Per ulteriori informazioni, consultare la sezione " Regolazione dei timeout ".

   httpsRedirect

   Consente il reindirizzamento permanente di tutte le richieste in entrata all'indirizzo HTTP all'endpoint HTTPS.

   Impostazione predefinita: false.

   customEntryPoints

   Specifica ulteriori punti di ingresso personalizzati per Traefik. Il nome del punto di ingresso sarà la chiave dell'oggetto. I seguenti nomi di entrypoint sono riservati e non possono essere utilizzati: web, websecure, traefik, hc, http e https.

   In caso di configurazione non valida dei punti di ingresso, nessuno dei punti di ingresso personalizzati verrà elaborato!

   customEntryPoints.<name>.port

   Porta del punto di ingresso da utilizzare. Questo campo è obbligatorio. Assicurati che non sia in conflitto con altre porte.

   La porta e il protocollo qui definiti devono essere configurati manualmente sul bilanciatore di carico; si vedano le istruzioni riportate di seguito.

   customEntryPoints.<name>.protocol

   Protocollo del punto di accesso da utilizzare. Questo campo è obbligatorio. I valori validi sono TCP e UDP.

   customEntryPoints.<name>.readTimeout

   Configura il timeout di lettura del punto di ingresso tra l'ALB e il client. Il valore deve essere un numero intero di secondi; impostandolo a zero si disattiva il timeout.

   Per ulteriori informazioni, consultare la documentazione di Traefik.

   customEntryPoints.<name>.writeTimeout

   Configura il timeout di scrittura del punto di ingresso tra l'ALB e il client. Il valore deve essere un numero intero di secondi; impostandolo a zero si disattiva il timeout.

   Per ulteriori informazioni, consultare la documentazione di Traefik.

   customEntryPoints.<name>.idleTimeout

   Configura il timeout di inattività (keepalive) del punto di ingresso tra l'ALB e il client. Il valore deve essere un numero intero di secondi; impostandolo a zero si disattiva il timeout.

   Per ulteriori informazioni, consultare la documentazione di Traefik.

   customEntryPoints.<name>.udpTimeout

   Configura il timeout di inattività del punto di ingresso per il listener UDP. Questo campo viene preso in considerazione solo per gli endpoint che utilizzano il protocollo UDP. Il valore deve essere un numero intero di secondi e maggiore di zero.

   Per ulteriori informazioni, consultare la documentazione di Traefik.

   tolerations

   Specifica ulteriori tolleranze personalizzate per i pod ALB. Per ulteriori informazioni, consultare la sezione “Taints e Tolerations ”.

3. Crea la mappa di configurazione ibm-ingress-deploy-config nel tuo cluster.

   kubectl create -f ibm-ingress-deploy-config.yaml
   

4. Aggiorna i tuoi ALB per applicare le modifiche. Potrebbero essere necessari fino a cinque minuti prima che le modifiche abbiano effetto. Se il comando termina senza generare alcun output, l'aggiornamento è stato inviato con successo.

   ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID
   

5. Se sono state specificate porte non standard HTTP, HTTPS oppure sono stati creati punti di ingresso aggiuntivi, è necessario aprire le porte su ciascun servizio ALB.

   1. Per ogni servizio ALB individuato nel passaggio 1, modificare il file YAML.

       kubectl edit svc -n kube-system <alb_svc_name>
       ```
   2. Nella sezione “ `spec.ports` ”, aggiungi le porte che desideri aprire. Per impostazione predefinita, sono aperte le porte 80 e 443. Se vuoi mantenere aperte le porte 80 e 443, non eliminarle da questo file. Qualsiasi porta che non sia specificata viene chiusa. Non specificare un `nodePort`. Dopo aver aggiunto la porta e applicato le modifiche, viene assegnato automaticamente un numero di porta ( `nodePort` ).
   
   ```sh {: codeblock}
       ...
       ports:
       - name: port-80
         port: 80
         protocol: TCP
         targetPort: 80
       - name: port-443
         port: 443
         protocol: TCP
         targetPort: 443
       - name: <new_port>
         port: <port>
         protocol: TCP
         targetPort: <port>
       ...
       ```
   3. Salva e chiudi il file. Le modifiche vengono applicate automaticamente.
   
   

Personalizzazione della classe Ingress

Una classe Ingress associa un nome di classe a un tipo di controller Ingress, consentendo la coesistenza di più controller nello stesso cluster. Utilizza la IngressClass risorsa per definire una classe personalizzata per i tuoi ALB.

Traefik elabora solo le classi Ingress in cui il parametro .spec.controller è impostato su traefik.io/ingress-controller``.

Aggiunta dell'autenticazione " App ID " alle app

Proteggi le tue app dagli accessi non autenticati integrando IBM Cloud App ID con il tuo Ingress ALB. Una volta configurata l'autenticazione, l'ALB inoltra le richieste tramite un' OAuth2-Proxy, che verifica le credenziali con App ID prima di inoltrare il traffico all'app.

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

   Un'istanza di App ID può essere utilizzata in un solo namespace all'interno del cluster. Se si desidera configurare App ID per le risorse Ingress in più spazi dei nomi, ripetere i passaggi descritti in questa sezione per specificare un'istanza univoca di App ID per le risorse Ingress in ciascuno 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 "Altre opzioni" nella 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 del servizio deve contenere solo caratteri alfanumerici minuscoli e non può superare i 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'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. Tutte le lettere che compongono il nome dell'istanza del servizio devono essere minuscole.

   Se utilizzi la funzione di disconnessione di IBM Cloud App ID, aggiungi /sign_out al tuo dominio nel formato https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out e includi questo URL nell'elenco degli URL di reindirizzamento. Per utilizzare una pagina di disconnessione personalizzata, imposta whitelist_domains nel file OAuth2-Proxy ConfigMap. Chiama l'endpoint https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out con il parametro di query rd oppure imposta l'intestazione X-Auth-Request-Redirect con l'URL della tua pagina di logout personalizzata URL. Per ulteriori informazioni, consulta la sezione "Esci".

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 esistenti. Associa l'istanza del servizio allo stesso namespace in cui si trovano le tue risorse Ingress. Tutte le lettere che compongono il nome dell'istanza del servizio devono essere minuscole.

   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 associato correttamente al cluster, viene creato un segreto del cluster che contiene le credenziali dell'istanza del servizio. Il seguente esempio mostra l'output:

   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. Abilita il componente aggiuntivo ALB OAuth Proxy nel tuo cluster. Questo add-on crea e gestisce le seguenti risorse di Kubernetes: una distribuzione OAuth2-Proxy per l'istanza del servizio App ID, un segreto contenente la configurazione OAuth2-Proxy e una risorsa Ingress che instrada le richieste in entrata verso la distribuzione OAuth2-Proxy. Il nome di ogni risorsa inizia con oauth2-.

   1. Abilita l'estensione " 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` ”. Attendi qualche minuto e riesegui il comando se lo stato indica “ `Enabling` ”.
   ```sh {: pre}
       ibmcloud ks cluster addon ls --cluster CLUSTER_NAME_OR_ID
       ```
   

5. Nelle risorse Ingress relative alle app in cui si desidera aggiungere l'autenticazione " App ID ", assicurarsi che il nome della risorsa non superi i 25 caratteri. Quindi configurare il middleware ForwardAuth:

   1. Crea una risorsa " ForwardAuth Middleware " in Traefik. L' address e specifica l' URL e dell' OAuth2-Proxy e per la tua istanza di App ID, che funge da OIDC Relying Party (RP). Tutte le lettere che compongono il nome dell'istanza del servizio devono essere minuscole.

       apiVersion: traefik.io/v1alpha1
       kind: Middleware
       metadata:
         name: oauth-verify
         namespace: default
       spec:
         forwardAuth:
           address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
           tls:
             insecureSkipVerify: true
       ```
       Per impostazione predefinita, Traefik verifica la validità dei nomi alternativi del soggetto (SAN) di tipo “ TLS ”. IBM-I certificati forniti potrebbero non superare questa verifica, pertanto si consiglia di utilizzare l'opzione " `insecureSkipVerify: true` ". Questa impostazione garantisce che l'istanza di Traefik, o l'ALB, possa comunicare con le istanze di distribuzione di `oauth2-proxy`.
       {: note}
   
   2. Scegli quali token inviare nell'intestazione ` `Authorization` ` alla tua app. Per ulteriori informazioni sugli ID e sui token di accesso, consultare la [documentazione di App ID](/docs/appid?topic=appid-tokens).
       * Per inviare solo l' `ID Token`, aggiungi l'opzione `authResponseHeaders` al tuo middleware ForwardAuth:
   
           ```yaml {: codeblock}
           apiVersion: traefik.io/v1alpha1
           kind: Middleware
           metadata:
             name: oauth-verify
             namespace: default
           spec:
             forwardAuth:
               address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
               authResponseHeaders:
                 - Authorization
               tls:
                 insecureSkipVerify: true
           ```
       * Per inviare solo l' `Access Token`, aggiungi l'opzione `authResponseHeaders` al tuo middleware ForwardAuth:
   
           ```yaml {: codeblock}
           apiVersion: traefik.io/v1alpha1
           kind: Middleware
           metadata:
             name: oauth-verify
             namespace: default
           spec:
             forwardAuth:
               address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
               authResponseHeaders:
                 - X-Auth-Request-Access-Token
               tls:
                 insecureSkipVerify: true
           ```
       * Per inviare sia l' `Access Token` che l' `ID Token`, aggiungi l'opzione `authResponseHeaders` al tuo middleware ForwardAuth:
   
           ```yaml {: codeblock}
           apiVersion: traefik.io/v1alpha1
           kind: Middleware
           metadata:
             name: oauth-verify
             namespace: default
           spec:
             forwardAuth:
               address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
               authResponseHeaders:
                 - X-Auth-Request-Access-Token
                 - Authorization
               tls:
                 insecureSkipVerify: true
           ```
   3. Facoltativo: se la tua app supporta la [strategia "web app](/docs/appid?topic=appid-key-concepts#term-web-strategy) " in aggiunta o in sostituzione della [strategia API](/docs/appid?topic=appid-key-concepts#term-api-strategy), aggiungi l' `authSigninURL` al tuo middleware ForwardAuth. Tutte le lettere che compongono il nome dell'istanza del servizio devono essere minuscole.
   
   ```yaml {: codeblock}
       apiVersion: traefik.io/v1alpha1
       kind: Middleware
       metadata:
         name: oauth-verify
         namespace: default
       spec:
         forwardAuth:
           address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
           authResponseHeaders:
             - X-Auth-Request-Access-Token
             - Authorization
           authSigninURL: /oauth2-<App_ID_service_instance_name>/sign_in?rd={url}
           tls:
             insecureSkipVerify: true
       ```
       * Se si specifica `authSigninURL` e l'autenticazione del client non va a buon fine, il client viene reindirizzato a OAuth2-Proxy, che a sua volta reindirizza il client alla pagina di accesso App ID.
       * Se non si specifica " `authSigninURL`", il client deve autenticarsi con un token "bearer" valido. Se l'autenticazione non va a buon fine, la richiesta viene respinta con un errore " `401 Unauthorized` ".
   
   

6. Facoltativo: se la tua configurazione lo richiede, crea una risorsa Traefik ServersTransport per ignorare la verifica " TLS " per le richieste inoltrate alla risorsa Service della tua app.

   # Example (Kubernetes ServersTransport)
   apiVersion: traefik.io/v1alpha1
   kind: ServersTransport
   metadata:
     name: skip-tls-verify
   spec:
     insecureSkipVerify: true
   

   Applica l' ServersTransport a alla tua risorsa Service utilizzando l'annotazione Traefik Service.

7. Modifica le tue risorse Ingress per imporre l'autenticazione tramite App ID applicando il middleware ForwardAuth che hai creato. Utilizza la seguente annotazione Ingress di Traefik.

   traefik.ingress.kubernetes.io/router.middlewares: "default-oauth-verify@kubernetescrd"
   

   Dopo che una risorsa Ingress con le annotazioni appropriate è stata riapplicata, l'add-on ALB OAuth Proxy esegue il deployment di un'istanza di oauth2-proxy, crea un servizio per tale deployment e crea una risorsa Ingress separata per configurare l'instradamento per l'istanza di oauth2-proxy. Non eliminare queste risorse aggiuntive.

8. Verifica che per le tue app sia attiva l'autenticazione tramite App ID.

   • Se la tua app supporta la strategia delle app web: accedi all' URL della tua app tramite un browser web. Se l' App ID e viene applicata correttamente, verrai reindirizzato alla pagina di autenticazione App ID.
   • Se la tua app supporta la strategia API: specifica il tuo token di accesso Bearer nell'intestazione Authorization delle richieste inviate alle app. Per ottenere il tuo token di accesso, consulta la documentazione su App ID. Se " App ID " viene applicato correttamente, la richiesta viene autenticata con successo e indirizzata alla tua app. Se invii richieste alle tue app senza un token di accesso nell'intestazione "Authorization", oppure se il token di accesso non è accettato da App ID, la richiesta viene respinta.

9. Facoltativo: se sul cluster si utilizzano criteri di rete o un’altra soluzione firewall per limitare il traffico in uscita, assicurarsi che il cluster possa accedere al servizio pubblico App ID. Per ottenere l'intervallo di indirizzi IP relativo a questo servizio, inviare una richiesta all'assistenza clienti.

10. Opzionale: è possibile personalizzare il comportamento predefinito dell' OAuth2-Proxy e creando un file Kubernetes ConfigMap.

    1. Creare un file YAML denominato “ ConfigMap ” in cui specificare i valori delle impostazioni di “ 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 back-end app via the X-Forwarded-Access-Token header.
          request_logging: <true|false>
          # Log all requests to the back-end 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 as when using the Traefik ForwardAuth Middleware.
          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 Traefik ForwardAuth Middleware.
          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. Applica la risorsa " ConfigMap " al tuo componente aggiuntivo. Le modifiche vengono applicate automaticamente.
    ```sh {: pre}
        kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
        ```
    

Per l'elenco delle modifiche relative a ciascuna versione del componente aggiuntivo " OAuth " di ALB, consultare il registro delle modifiche del componente aggiuntivo " IBM Cloud " di ALB OAuth.

Aggiornamento del componente aggiuntivo "ALB OAuth Proxy"

Per aggiornare il componente aggiuntivo ALB OAuth Proxy a una versione più recente, disattivare l'installazione corrente e riattivarla con la versione desiderata. Le istanze esistenti di oauth2-proxy non subiscono alcuna interruzione durante l'aggiornamento.

Il processo di aggiornamento non comporta alcuna interruzione, poiché le istanze di oauth2-proxy in modalità supervisionata rimangono nel cluster anche quando il componente aggiuntivo è disabilitato.

1. Disabilita il componente aggiuntivo.

   ibmcloud ks cluster addon disable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID
   

2. Elenca le versioni dei componenti aggiuntivi disponibili e prendi nota di quella che desideri utilizzare. L'output mostra le versioni disponibili e quale di esse è quella predefinita.

   ibmcloud ks cluster addon versions --addon alb-oauth-proxy
   

3. Attiva il componente aggiuntivo e imposta l'opzione " --version ". Se non si specifica una versione, viene attivata quella predefinita.

   ibmcloud ks cluster addon enable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID [--version VERSION]
   

Conservazione dell'indirizzo IP di origine

Per impostazione predefinita, l'ALB di Ingress non conserva l'indirizzo IP di origine originale delle richieste dei client. Ciò può impedire il corretto funzionamento del controllo degli accessi basato su IP, della registrazione delle attività e delle politiche di sicurezza. Scegli il metodo adatto al tipo di cluster in uso per abilitare il mantenimento dell'IP di origine.

Configurazione dei protocolli e degli algoritmi di crittograf TLS

Utilizza una risorsa TLSOption per imporre versioni minime di TLS, limitare le suite di cifratura e configurare altri parametri di connessione TLS per il traffico che raggiunge il tuo ALB. Dopo aver creato la risorsa TLSOption, applicala alla tua risorsa Ingress utilizzando l'annotazione Traefik Ingress.

Invio del tuo certificato personalizzato ai client legacy

I dispositivi legacy che non supportano la Server Name Indication (SNI) non sono in grado di negoziare quale certificato TLS utilizzare, pertanto ricevono il certificato Let's Encrypt predefinito dell'ALB anziché il certificato personalizzato. Per garantire che questi dispositivi ricevano il tuo certificato personalizzato, aggiorna le impostazioni predefinite del server ALB in modo che puntino al tuo segreto personalizzato TLS.

I certificati Let's Encrypt generati per impostazione predefinita non sono destinati all'uso in ambiente di produzione. Per i carichi di lavoro di produzione, utilizza un certificato personalizzato di tua scelta.

Quando si crea un cluster classico, IBM fornisce un certificato Let's Encrypt per il segreto Ingress predefinito. Se si crea un segreto personalizzato e lo si specifica per la terminazione " TLS " nelle risorse Ingress, l'ALB invia ai client il certificato personalizzato anziché quello di Let's Encrypt. Tuttavia, se un client non supporta SNI, l'ALB utilizza per impostazione predefinita il certificato Let's Encrypt, poiché il segreto predefinito è indicato nelle impostazioni predefinite del server dell'ALB. Per inviare il certificato personalizzato a dispositivi non SNI, segui questi passaggi.

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.

   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. Nell'output, verifica che " spec.tls[].secretName " corrisponda al nome del tuo segreto personalizzato.

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

Ottimizzazione delle prestazioni ALB

I nodi di lavoro vengono configurati automaticamente con impostazioni ottimizzate del kernel adatte alla maggior parte dei carichi di lavoro. Se il cluster presenta requisiti specifici in termini di elevata produttività o bassa latenza, è possibile modificare i parametri del kernel Linux sysctl sui nodi di lavoro per ottimizzare ulteriormente le prestazioni dell’ALB. Modifica queste impostazioni solo se hai una chiara esigenza di ottimizzazione delle prestazioni, poiché valori errati potrebbero destabilizzare il nodo.

Passi successivi

• Gestisci i tuoi ALB di Ingress per ridimensionarli, aggiornarli o disattivarli nel tuo cluster.
• Configura Ingress per rendere accessibili le tue app utilizzando il servizio Ingress gestito.
• Utilizza il debug di Ingress per diagnosticare e risolvere i problemi più comuni di Ingress.

Link correlati

• Documentazione di Traefik
• Guida di riferimento al middleware Traefik
• Guida di riferimento a Traefik CRD
• Documentazione di IBM Cloud App ID