Ajouter un port de serveur à un en-tête d'hôte

Par défaut, Traefik gère l'en-tête « Host » d'une manière compatible avec la plupart des applications modernes. Il n'est pas recommandé de modifier l'en-tête « Host » pour y inclure un port. Avant d'effectuer la moindre modification, vérifiez comment Traefik gère les en-têtes par défaut et assurez-vous de bien comprendre dans quels cas il est approprié de les remplacer.

Gestion par défaut des en-têtes « Host »

Par défaut, Traefik transmet l'en-tête « Host » d'origine avec passHostHeader: true. Il ajoute automatiquement les en-têtes de transfert distincts suivants au lieu d'intégrer le port dans l'en-tête « Host » :

• X-Forwarded-Host

• X-Forwarded-Port

Remplacer l'en-tête « Host » pour les applications héritées

Si votre application nécessite le port intégré dans l'en-tête « Host », utilisez Traefik En-têtes et middleware pour le remplacer.

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

Appliquez le middleware à votre ressource Ingress à l'aide de l'annotation Traefik Ingress. Assurez-vous que le traitement CRD est activé (c'est le réglage par défaut). Pour configurer le traitement des CRD, consultez la rubrique « ibm-ingress-deploy-config » ( ConfigMap )dans le champ « processTraefikCRDs ».

Acheminement des requêtes entrantes à l'aide d'un ALB privé

Par défaut, les ALB publiques traitent les ressources Ingress. Pour acheminer les requêtes entrantes via un ALB privé, indiquez la classe « private-iks-traefik » dans le champ « spec.ingressClassName » de votre ressource Ingress.

spec.ingressClassName: "private-iks-traefik"

Authentification des applications avec App ID

Configurez Traefik Ingress avec l'IBM Cloud App ID pour appliquer l'authentification à vos applications. Pour plus d'informations, consultez la section « Ajouter l'authentification par l App ID s aux applications ».

Définition de la taille maximale du corps d'une requête client

Par défaut, Traefik n'impose aucune limite quant à la taille du corps des requêtes client. Pour définir une limite maximale, créez un middleware de mise en mémoire tampon et appliquez-le à votre ressource Ingress.

Traefik rejette toute requête dépassant la limite configurée en renvoyant une réponse 413 « HTTP ».

1. Créez une ressource « Traefik Buffering Middleware ». Définissez maxRequestBodyBytes sur le nombre maximal d'octets que le client peut envoyer. L'exemple suivant définit une limite de 2 Mo (2 097 152 octets).

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

2. Appliquez le middleware à votre ressource Ingress à l'aide de l'annotation Traefik Ingress.

Activation de la mise en mémoire tampon des données de réponse client

Par défaut, Traefik transmet les réponses directement, sans mise en mémoire tampon. Grâce au middleware de mise en mémoire tampon, Traefik peut stocker les réponses en mémoire ou les enregistrer sur le disque avant de les envoyer au client. N'utilisez ce middleware que si votre application en a besoin, car la mise en mémoire tampon des réponses n'est pas recommandée dans la plupart des cas.

Pour activer la mise en mémoire tampon des réponses, procédez comme suit :

1. Créez une ressource « Traefik Buffering Middleware ». Définissez maxResponseBodyBytes sur la taille maximale de la réponse en octets et memResponseBodyBytes sur le seuil au-delà duquel la réponse est enregistrée sur le disque au lieu d'être conservée en mémoire. L'exemple suivant met en mémoire tampon jusqu'à 5 Mo au total, dont le premier Mo est conservé en mémoire.

   # 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. Appliquez le middleware à votre ressource Ingress à l'aide de l'annotation Traefik Ingress.

Réglage des délais d'expiration

Traefik propose deux types de paramètres de délai d'expiration : les délais d'expiration entre le client et l'ALB, et ceux entre l'ALB et votre application back-end. Configurez-les séparément en fonction de l'emplacement du goulot d'étranglement.

Pour définir les délais d'expiration entre le client et l'ALB, configurez les champs correspondants dans ibm-ingress-deploy-config ConfigMap:

• Pour configurer le délai d'attente d'une requête entrante sur HTTP ou HTTPS avant que l'instance Traefik ne réponde, utilisez les champs « httpReadTimeout » et « httpsReadTimeout ».
• Pour configurer la durée maximale avant l'expiration de la réponse, utilisez les champs « httpWriteTimeout » et « httpsWriteTimeout ».
• Pour configurer la durée maximale pendant laquelle une connexion « keepalive » reste ouverte avant de se fermer, utilisez les champs « httpIdleTimeout » et « httpsIdleTimeout ».

Pour définir le délai d'expiration de la connexion et de la lecture entre l'ALB et votre application back-end, utilisez ServersTransport pour configurer le transport entre Traefik et vos serveurs d' HTTP.

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

Pour les clusters VPC, vous devez également modifier le délai d'expiration des connexions inactives sur le service d'équilibrage de charge qui expose votre ALB public. Remplacez « CLUSTER_ID » par l'identifiant de votre cluster, que vous pouvez obtenir en exécutant la commande « ibmcloud ks cluster get --cluster CLUSTER_NAME_OR_ID ». L'exemple suivant définit le délai d'expiration à 910 secondes :

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

Traefik prend en charge la valeur « 0 » pour ses délais d'expiration, ce qui désactive le délai d'expiration.

L'annotation « ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout » du répartiteur de charge VPC ne prend pas en charge la valeur zéro. Vous pouvez définir un délai d'expiration compris entre 50 secondes et 7 200 secondes (2 heures). Si vous avez besoin d'un délai supérieur à 2 heures, ouvrez un dossier d'assistance et fournissez une justification métier.

Si vos clusters sont exposés via IBM Cloud Internet Services (CIS) ou Cloudflare avec le pare-feu d'application web (WAF) ou l'équilibrage de charge global activé, définissez ces délais d'expiration sur une valeur supérieure à 900 secondes. Pour plus d'informations, consultez la documentation de Cloudflare.

Une fois la ressource « ServersTransport » créée, appliquez-la à votre ressource « Service » à l'aide de l'annotation « Traefik Service ».

Personnalisation des actions en cas d'erreur

Pour définir les actions personnalisées que l'ALB peut effectuer en cas d'erreurs spécifiques d' HTTP, configurez le paramètre Traefik « Erreurs liées au middleware ». Une fois le middleware créé, appliquez-le à votre ressource Ingress à l'aide de l'annotation Traefik Ingress.

Modification des ports par défaut HTTP et HTTPS

Par défaut, les ALB écoutent sur le port 80 pour HTTP et sur le port 443 pour HTTPS. Si votre cluster nécessite des ports non standard, vous pouvez modifier ces valeurs pour chaque ALB à l'aide des champs « httpPort » et « httpsPort » dans la section « ibm-ingress-deploy-config » ConfigMap.

Personnalisation de l'en-tête de la requête

Utilisez le middleware « Headers » de Traefik pour ajouter, remplacer ou supprimer des champs d'en-tête dans une requête client avant de la transférer vers votre application back-end. Cela s'avère utile pour injecter des éléments de contexte tels que les noms de scripts, les identifiants de locataires ou d'autres métadonnées dont votre application a besoin.

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

Une fois le middleware créé, appliquez-le à votre ressource Ingress à l'aide de l'annotation Traefik Ingress.

Personnalisation de l'en-tête de réponse

Utilisez le middleware « Headers » de Traefik pour ajouter, remplacer ou supprimer des champs d'en-tête dans une réponse avant de l'envoyer au client. Cela s'avère utile pour appliquer des politiques de sécurité, ajouter des en-têtes d' CORS, ou supprimer les en-têtes internes avant qu'ils n'atteignent le client.

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

Une fois le middleware créé, appliquez-le à votre ressource Ingress à l'aide de l'annotation Traefik Ingress.

Rediriger les requêtes non sécurisées

Pour n'autoriser que l'accès via HTTPS et rediriger de manière permanente toutes les requêtes entrantes vers HTTP vers le point de terminaison HTTPS, définissez le champ httpsRedirect dans le fichier ibm-ingress-deploy-config ConfigMap.

Activation et désactivation de la sécurité de transport stricte ( HTTP )

HTTP La fonctionnalité « Strict Transport Security » ( HSTS ) impose aux navigateurs d'accéder à un domaine uniquement via le protocole HTTPS, ce qui empêche les attaques par rétrogradation de protocole. Cette fonctionnalité est disponible sur inscription pour Traefik. Pour l'activer, utilisez le middleware « Headers » en renseignant les champs « stsSeconds », « stsIncludeSubdomains » et « 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

Appliquez le middleware à votre ressource Ingress à l'aide de l'annotation Traefik Ingress suivante.

Modification de la manière dont l'ALB fait correspondre l'URI de la requête

Par défaut, Traefik utilise le module de correspondance « PathPrefix » pour acheminer les requêtes. Si votre application nécessite une correspondance exacte des chemins d'accès ou un routage basé sur des expressions régulières, remplacez le module de correspondance à l'aide de l'annotation Ingress de Traefik suivante.

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

Configuration de l'authentification mutuelle

L' TLS mutuelle ( mTLS ) exige que le serveur et le client présentent tous deux des certificats valides, ce qui garantit une authentification plus sûre que l' TLS standard. Pour exiger l'authentification par certificat client sur votre ALB, créez une ressource TLSOption qui fait référence au secret de votre certificat d'autorité de certification.

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

Une fois la ressource « TLSOption » créée, appliquez-la à votre ressource Ingress à l'aide de l'annotation Traefik Ingress.

Configuration du comportement de réessai pour les requêtes en amont

Lorsqu'un serveur back-end ne répond pas, Traefik peut automatiquement réessayer d'envoyer la requête vers un autre serveur en amont. Configurez le comportement de réessai à l'aide du middleware de réessai Traefik. Une fois le middleware créé, appliquez-le à votre ressource Ingress à l'aide de l'annotation Traefik Ingress.

Limitation de débit

La limitation de débit protège vos applications back-end contre les pics de trafic et les abus en plafonnant le nombre de requêtes traitées par l'ALB au cours d'un intervalle de temps donné. Configurez la limitation de débit à l'aide de Traefik RateLimit Middleware. Une fois le middleware créé, appliquez-le à votre ressource Ingress à l'aide de l'annotation Traefik Ingress.

Réécriture des chemins d'accès

La réécriture d'URL vous permet de mettre à disposition une URL publique URL différente de celle sur laquelle votre application back-end est à l'écoute. Par exemple, vous pouvez rediriger les requêtes arrivant à l'adresse /app vers une application back-end qui écoute sur /. Utilisez l'une des ressources Traefik suivantes, selon que vous ayez besoin d'un remplacement fixe ou d'un remplacement basé sur des modèles :

• La ressource « Traefik » sur ReplacePath Middleware
• La ressource « Traefik » sur ReplacePathRegex Middleware

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

Appliquez le middleware à votre ressource Ingress à l'aide de l'annotation Traefik Ingress suivante.

Acheminement du trafic à l'aide de cookies persistants

Les sessions persistantes garantissent que les requêtes d'un client sont toujours acheminées vers le même serveur back-end pendant toute la durée d'une session. Cela s'avère utile pour les applications avec état qui stockent les données de session localement sur le serveur. Activez les sessions persistantes en configurant le service Traefik Annotation « cookie persistant » sur votre ressource Ingress.

Chiffrement du trafic entre votre application et l'ALB

Par défaut, Traefik redirige le trafic vers votre application back-end via le protocole HTTP. Si votre application nécessite des connexions en amont chiffrées, utilisez une ServersTransport ressource pour configurer l' TLS e entre l'ALB et votre application, en indiquant notamment le certificat de l'autorité de certification et le nom de serveur attendu.

# 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

Appliquez l'annotation « ServersTransport » à votre ressource Service à l'aide de l'annotation Traefik Service suivante.

Personnalisation du déploiement d'équilibreur de charge d'application

Le fichier « ibm-ingress-deploy-config » ( ConfigMap ) permet de contrôler les paramètres au niveau de l'ALB, tels que le nombre de répliques, les ports, le niveau de journalisation, les délais d'expiration et le fournisseur Ingress. Utilisez cette ConfigMap pour appliquer des modifications de configuration à un ou plusieurs ALB de votre cluster sans avoir à modifier les ressources Ingress individuelles.

1. Récupérez les noms des services qui exposent chaque équilibreur de charge d'application. Notez bien les noms de ces services, car vous en aurez besoin dans les étapes suivantes.

   • Clusters classiques :

       kubectl get svc -n kube-system | grep alb
       ```
   * Clusters VPC : dans la sortie, recherchez un nom de service formaté de la manière suivante `public-crc204dl7w0qf6n6sp7tug`.
   
   ```sh {: pre}
       kubectl get svc -n kube-system | grep LoadBalancer
       ```
   

2. Créez un fichier YAML pour une mappe de configuration ibm-ingress-deploy-config. Pour chaque ID d'équilibreur de charge d'application, vous pouvez indiquer un ou plusieurs des paramètres facultatifs spécifiés ci-après. Vous devez uniquement inclure les paramètres que vous souhaitez configurer.

   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

   Par défaut, chaque ALB dispose de deux répliques. Augmentez vos capacités de traitement d'équilibreur de charge d'application en augmentant le nombre de pods d'équilibreur de charge d'application. Pour plus d'informations, voir Augmentation du nombre de répliques de pod d'équilibreur de charge d'application.

   ingressClass

   Si vous avez spécifié une classe autre que « public-iks-traefik » ou « private-iks-traefik » dans votre ressource Ingress, saisissez ici le nom de cette classe.

   httpPort, httpsPort

   Exposer les ports autres que les ports par défaut pour l'équilibreur de charge d'application Ingress en ajoutant les ports HTTP ou HTTPS que vous voulez ouvrir.

   Valeurs par défaut : 80/443.

   logLevel

   Spécifiez le niveau de journalisation. Faites votre choix parmi : TRACE, DEBUG, INFO, WARN, ERROR, FATAL, PANIC.

   Par défaut : INFO.

   ingressProvider

   Indiquez quel fournisseur Ingress Traefik utiliser pour cet ALB. Valeurs valides :

   ingress: Utilise le contrôleur d'entrée propre à Traefik. Il traite les annotations spécifiques à Traefik sur les ressources Ingress.

   ingress-nginx: Utilise une Couche de compatibilité pour Ingress(NGINX)dans Traefik ion temporaire. Il traite les annotations créées pour Ingress ( NGINX ) et reproduit, dans la mesure du possible, le comportement d'Ingress ( NGINX ). Utilisez cette valeur pour faciliter la migration d'Ingress ( NGINX ) vers Traefik.

   Par défaut : ingress.

   processTraefikCRDs

   Lorsqu'il est configuré sur « true », Traefik traite ses propres ressources CRD en plus des ressources Ingress. Les CRD pris en charge sont notamment IngressRoute, Middleware et TLSOption. Pour consulter la liste complète, reportez-vous à la documentation de Traefik sur les CRD. Par : défaut : true.

   traefikIngressNginxAllowExternalNameServices

   Active la prise en charge des services « ExternalName » pour les objets Ingress traités par le fournisseur « ingress-nginx ». Cette option ne s'applique que lorsque le paramètre « ingressProvider » est défini sur « ingress-nginx ». Par : défaut : true.

   traefikCRDAllowCrossNamespace

   Permet aux ressources « IngressRoute » (CRD Traefik) de faire référence à des ressources situées dans d’autres espaces de noms. Par : défaut : false.

   traefikCRDAllowExternalNameServices

   Permet aux ressources « IngressRoute » (CRD Traefik) de faire référence aux services « ExternalName ». Par : défaut : false.

   httpReadTimeout, httpsReadTimeout

   Configure le délai d'expiration de lecture HTTP / HTTPS entre l'ALB et le client. La valeur doit être un nombre entier de secondes; la définir sur zéro désactive le délai d'expiration.

   Pour plus d'informations, consultez la documentation de Traefik.

   httpWriteTimeout, httpsWriteTimeout

   Configure le délai d'expiration d'écriture de l' HTTP / HTTPS entre l'ALB et le client. La valeur doit être un nombre entier de secondes; la définir sur zéro désactive le délai d'expiration.

   Pour plus d'informations, consultez la documentation de Traefik.

   httpIdleTimeout, httpsIdleTimeout

   Configure le délai d'inactivité (keepalive) de la connexion HTTP / HTTPS entre l'ALB et le client. La valeur doit être un nombre entier de secondes; la définir sur zéro désactive le délai d'expiration.

   Pour plus d'informations, consultez la documentation de Traefik.

   Si vous utilisez IBM Cloud Internet Services (CIS) ou Cloudflare avec un pare-feu d'application web (WAF) ou un équilibrage de charge global, configurez cette valeur sur plus de 900 secondes. Pour plus d'informations, consultez la section « Réglage des délais d'expiration ».

   httpsRedirect

   Permet de rediriger de manière permanente toutes les requêtes entrantes vers HTTP vers le point de terminaison HTTPS. Par : défaut : false.

   customEntryPoints

   Spécifie des points d’entrée personnalisés supplémentaires pour Traefik. Le nom du point d'entrée servira de clé à l'objet. Les noms de points d’entrée suivants sont réservés et ne peuvent pas être utilisés : web, websecure, traefik, hc, et http https.

   En cas de configuration incorrecte des points d’entrée, aucun des points d’entrée personnalisés ne sera traité!

   customEntryPoints.<name>.port

   Port du point d'entrée à utiliser. Cette zone est obligatoire. Assurez-vous qu’il n’y ait pas de conflit avec d’autres ports.

   Le port et le protocole définis ici doivent être configurés manuellement sur l'équilibreur de charge; voir ci-dessous pour les instructions.

   customEntryPoints.<name>.protocol

   Protocole du point d'entrée à utiliser. Cette zone est obligatoire. Les valeurs valides sont TCP et UDP.

   customEntryPoints.<name>.readTimeout

   Configure le délai d'expiration de lecture du point d'entrée, entre l'ALB et le client. La valeur doit être un nombre entier de secondes; si elle est définie sur zéro, le délai d'expiration est désactivé.

   Pour plus d'informations, consultez la documentation de Traefik.

   customEntryPoints.<name>.writeTimeout

   Configure le délai d’expiration d’écriture du point d’entrée entre l’ALB et le client. La valeur doit être un nombre entier de secondes; si elle est définie sur zéro, le délai d'expiration est désactivé.

   Pour plus d'informations, consultez la documentation de Traefik.

   customEntryPoints.<name>.idleTimeout

   Configure le délai d'inactivité (keepalive) du point d'entrée entre l'ALB et le client. La valeur doit être un nombre entier de secondes; si elle est définie sur zéro, le délai d'expiration est désactivé.

   Pour plus d'informations, consultez la documentation de Traefik.

   customEntryPoints.<name>.udpTimeout

   Configure le délai d'expiration en inactivité du point d'entrée pour le listener UDP. Ce champ n'est pris en compte que pour les points de terminaison utilisant le protocole UDP. La valeur doit être un nombre entier de secondes supérieur à zéro.

   Pour plus d'informations, consultez la documentation de Traefik.

   tolerations

   Définit des tolérances personnalisées supplémentaires pour les pods ALB. Pour plus d'informations, consultez la section Taints et tolérances.

3. Créez la mappe de configuration ibm-ingress-deploy-config dans votre cluster.

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

4. Mettez à jour vos ALB pour que les modifications soient prises en compte. Les modifications peuvent prendre jusqu'à cinq minutes pour prendre effet. Si la commande s'exécute sans afficher de résultat, cela signifie que la mise à jour a été envoyée avec succès.

   ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID
   

5. Si vous avez spécifié des ports HTTP ou HTTPS non standard, ou si vous avez créé des points d'entrée supplémentaires, vous devez ouvrir les ports sur chaque service ALB.

   1. Editez le fichier YAML pour chaque service d'équilibreur de charge d'application trouvé à l'étape 1.

       kubectl edit svc -n kube-system <alb_svc_name>
       ```
   2. Dans la section `spec.ports`, ajoutez les ports que vous voulez ouvrir. Par défaut, les ports 80 et 443 sont ouverts. Si vous souhaitez conserver les ports 80 et 443 ouverts, ne les supprimez pas de ce fichier. Tout port non spécifié est fermé. Ne spécifiez pas de port de noeud (`nodePort`). Une fois que vous avez ajouté le port et appliqué les modifications, un `nodePort` est automatiquement affecté.
   
   ```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. Sauvegardez et fermez le fichier. Vos modifications sont appliquées automatiquement.
   
   

Personnalisation de la classe Ingress

Une classe Ingress associe un nom de classe à un type de contrôleur Ingress, ce qui permet à plusieurs contrôleurs de coexister au sein d'un même cluster. Utilisez la IngressClass ressource pour définir une classe personnalisée pour vos ALB.

Traefik ne traite que les classes Ingress pour lesquelles la propriété « .spec.controller » est définie sur « traefik.io/ingress-controller ».

Ajout de l'authentification App ID à des applications

Protégez vos applications contre les accès non authentifiés en intégrant IBM Cloud App ID à votre Ingress ALB. Lorsque l'authentification est configurée, l'ALB transfère les requêtes via un module de gestion des identités ( OAuth2-Proxy ) qui valide les identifiants auprès d' App ID avant de transmettre le trafic à votre application.

1. Choisissez une instance existante ou créer une nouvelle instance App ID.

   Une instance App ID ne peut être utilisée que dans un seul espace de noms de votre cluster. Si vous voulez configurer App ID pour des ressources Ingress dans plusieurs espaces de noms, répétez les étapes de cette section afin de spécifier une unique instance App ID pour les ressources Ingress de chaque espace de noms.

   • Pour utiliser une instance existante, assurez-vous que le nom de l'instance du service ne contient que des caractères alphanumériques en minuscules et que sa longueur ne dépasse pas 25 caractères. Pour modifier le nom, sélectionnez Renommer le service dans le menu des options supplémentaires de la page de détails de votre instance de service.
   • Pour mettre à disposition une nouvelle instance App ID :
     1. Remplacez le nom du service par votre propre nom unique pour l'instance de service. Le nom de l'instance de service doit contenir uniquement des caractères alphanumériques en minuscules et ne doit pas dépasser 25 caractères.
     2. Choisissez la même région que celle dans laquelle est déployé votre cluster.
     3. Cliquez sur Créer.

2. Ajoutez des URL de redirection pour votre application. Une URL de redirection est l'URL du point de terminaison de rappel de votre application. Pour éviter les attaques par hameçonnage, IBM Cloud App ID valide l'URL de la demande par rapport à la liste autorisée des URL de redirection.

   1. Dans la console de gestion App ID, accédez à Gérer l'authentification.
   2. Dans l'onglet Fournisseurs d'identité, assurez-vous qu'un fournisseur d'identité a été sélectionné. Si aucun fournisseur d'identité n'est sélectionné, vous n'êtes pas authentifié, mais un jeton d'accès vous est attribué pour un accès anonyme à l'application.
   3. Dans l'onglet Paramètres d'authentification, ajoutez des URL de redirection pour votre application au format https://<hostname>/oauth2-<App_ID_service_instance_name>/callback. Toutes les lettres du nom de l'instance de service doivent être en minuscules.

   Si vous utilisez la fonction de déconnexion IBM Cloud App ID, ajoutez /sign_out à votre domaine au format https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out et incluez cette URL dans la liste des URL de redirection. Pour utiliser une page de déconnexion personnalisée, définissez la valeur « whitelist_domains » dans le fichier OAuth2-Proxy ConfigMap. Appelez le point de terminaison https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out avec le paramètre de requête rd ou définissez l'en-tête X-Auth-Request-Redirect avec l'URL de votre page de déconnexion personnalisée URL. Pour plus d'informations, consultez la section « Se déconnecter ».

3. Effectuez la liaison de l'instance de service App ID à votre cluster. La commande crée une clé de service pour l'instance de service; vous pouvez également inclure l'option --key pour utiliser les identifiants de clé de service existants. Associez l'instance du service au même espace de noms que celui dans lequel se trouvent vos ressources Ingress. Toutes les lettres du nom de l'instance de service doivent être en minuscules.

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

   Une fois le service correctement associé à votre cluster, un secret de cluster est créé; il contient les informations d'identification de votre instance de service. Voici un exemple de la sortie :

   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. Activez le module complémentaire Proxy ALB OAuth dans votre cluster. Cet add-on crée et gère les ressources Kubernetes suivantes : un déploiement OAuth2-Proxy pour votre instance du service App ID, un secret contenant la configuration OAuth2-Proxy, ainsi qu’une ressource Ingress qui achemine les requêtes entrantes vers le déploiement OAuth2-Proxy. Le nom de chaque ressource commence par oauth2-.

   1. Activez l'additif alb-oauth-proxy.

       ibmcloud ks cluster addon enable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID
       ```
   2. Vérifiez que le statut du module complémentaire Proxy ALB OAuth est `Addon Ready`. Attendez quelques minutes, puis relancez la commande si le statut indique « `Enabling` ».
   ```sh {: pre}
       ibmcloud ks cluster addon ls --cluster CLUSTER_NAME_OR_ID
       ```
   

5. Dans les ressources Ingress destinées aux applications auxquelles vous souhaitez ajouter l'authentification « App ID », veillez à ce que le nom de la ressource ne dépasse pas 25 caractères. Configurez ensuite le middleware « ForwardAuth » :

   1. Créez une ressource « Traefik ForwardAuth Middleware ». Le fichier spécifie address l’ URL de l’ OAuth2-Proxy pour votre instance App ID, qui fait office de partie de confiance (RP) OIDC. Toutes les lettres du nom de l'instance de service doivent être en minuscules.

       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
       ```
       Par défaut, Traefik valide les noms alternatifs de sujet (SAN) de type « TLS ». IBM- Les certificats fournis risquent de ne pas passer cette validation; utilisez donc l'option « `insecureSkipVerify: true` ». Ce paramètre garantit que l'instance Traefik, ou ALB, puisse communiquer avec les instances de déploiement d' `oauth2-proxy`.
       {: note}
   
   2. Sélectionnez les jetons à envoyer à votre application dans l'en-tête `Authorization`. Pour plus d’informations sur les identifiants et les jetons d’accès, consultez la [documentation relative à l’ App ID.](/docs/appid?topic=appid-tokens)
       * Pour n'envoyer que les données de l' `ID Token`, ajoutez l'option `authResponseHeaders` à votre 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
           ```
       * Pour n'envoyer que les données de l' `Access Token`, ajoutez l'option `authResponseHeaders` à votre 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
           ```
       * Pour envoyer à la fois les messages « `Access Token` » et « `ID Token` », ajoutez l'option « `authResponseHeaders` » à votre 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. Facultatif : si votre application prend en charge la [stratégie « application Web](/docs/appid?topic=appid-key-concepts#term-web-strategy) » en plus de la [stratégie « API](/docs/appid?topic=appid-key-concepts#term-api-strategy) » ou à la place de celle-ci, ajoutez l' `authSigninURL` à votre middleware ForwardAuth. Toutes les lettres du nom de l'instance de service doivent être en minuscules.
   
   ```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
       ```
       * Si vous indiquez `authSigninURL` et que l'authentification du client échoue, celui-ci est redirigé vers OAuth2-Proxy, qui le redirige ensuite vers la page de connexion App ID.
       * Si vous ne spécifiez pas `authSigninURL`, un client doit s'authentifier à l'aide d'un jeton bearer valide. Si l'authentification échoue, la requête est rejetée avec une erreur « `401 Unauthorized` ».
   
   

6. Facultatif : si votre configuration l'exige, créez une ressource Traefik ServersTransport afin de contourner la vérification « TLS » pour les requêtes transmises à la ressource Service de votre application.

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

   Appliquez l' ServersTransport e à votre ressource Service à l'aide de l'annotation Traefik Service.

7. Modifiez vos ressources Ingress afin d'imposer l'authentification via App ID en appliquant le middleware « ForwardAuth » que vous avez créé. Utilisez l'annotation Ingress de Traefik suivante.

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

   Une fois qu’une ressource Ingress comportant les annotations appropriées a été réappliquée, le module complémentaire ALB OAuth Proxy déploie un déploiement oauth2-proxy, crée un service pour ce déploiement, puis crée une ressource Ingress distincte afin de configurer le routage pour ce oauth2-proxy déploiement. Ne supprimez pas ces ressources complémentaires.

8. Vérifiez que l'authentification App ID est imposée à vos applications.

   • Si votre application prend en charge la stratégie d'application Web: accédez à l' URL de votre application dans un navigateur Web. Si App ID est correctement appliqué, vous êtes redirigé vers une page de connexion d'authentification App ID.
   • Si votre application prend en charge la stratégie API: indiquez votre jeton d’accès Bearer dans l’en-tête Authorization des requêtes adressées aux applications. Pour obtenir votre jeton d'accès, consultez la documentation App ID. Si App ID est correctement appliqué, la demande est authentifiée avec succès et acheminée vers votre application. Si vous envoyez des requêtes à vos applications sans jeton d'accès dans l'en-tête Authorization, ou si le jeton d'accès n'est pas accepté par App ID, la requête est rejetée.

9. Facultatif : si vous utilisez des stratégies réseau ou une autre solution de pare-feu sur votre cluster pour limiter le trafic sortant, assurez-vous que votre cluster peut accéder au service public App ID. Pour obtenir la plage d'adresses IP de ce service, veuillez envoyer une demande au service client.

10. Facultatif : vous pouvez personnaliser le comportement par défaut de OAuth2-Proxy en créant une mappe de configuration Kubernetes.

    1. Créez un fichier YAML ConfigMap qui spécifie des valeurs pour les paramètres OAuth2-Proxy que vous voulez modifier.

        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. Appliquez la ressource de mappe de configuration (ConfigMap) à votre module complémentaire. Vos modifications sont appliquées automatiquement.
    ```sh {: pre}
        kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
        ```
    

Pour consulter la liste des modifications apportées à chaque version du module complémentaire ALB OAuth Proxy, reportez-vous au journal des modifications du module complémentaire ALB OAuth Proxy d' IBM Cloud.

Mise à niveau du module complémentaire ALB OAuth Proxy

Pour mettre à niveau le module complémentaire « ALB OAuth Proxy » vers une version plus récente, désactivez l'installation actuelle, puis réactivez-la avec la version souhaitée. Vos instances existantes d' oauth2-proxy ne sont pas interrompues pendant la mise à niveau.

Le processus de mise à niveau s’effectue sans interruption, car les oauth2-proxy instances supervisées restent sur le cluster même lorsque le module complémentaire est désactivé.

1. Désactivez le module complémentaire.

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

2. Répertoriez les versions des modules complémentaires disponibles et indiquez celle que vous souhaitez utiliser. Le résultat affiche les versions disponibles et indique quelle est la version par défaut.

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

3. Activez le module complémentaire et spécifiez l'option --version. Si vous ne spécifiez pas de version, la version par défaut est activée.

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

Conservation de l'adresse IP source

Par défaut, l'ALB Ingress ne conserve pas l'adresse IP source d'origine des requêtes des clients. Cela peut empêcher le bon fonctionnement du contrôle d'accès basé sur l'adresse IP, de la journalisation et des politiques de sécurité. Sélectionnez la méthode qui correspond à votre type de cluster pour activer la conservation de l'adresse IP source.

Configuration des protocoles et des algorithmes de chiffrement d' TLS

Utilisez une ressource TLSOption pour imposer des versions minimales d' TLS, restreindre les suites de chiffrement et configurer d'autres paramètres de connexion d' TLS pour le trafic qui parvient à votre ALB. Une fois la ressource « TLSOption » créée, appliquez-la à votre ressource Ingress à l'aide de l'annotation Traefik Ingress.

Envoi de votre certificat personnalisé aux clients existants

Les appareils hérités qui ne prennent pas en charge la fonction SNI (Server Name Indication) ne peuvent pas déterminer quel certificat TLS utiliser; ils reçoivent donc le certificat Let's Encrypt par défaut de l'ALB au lieu de votre certificat personnalisé. Pour vous assurer que ces appareils reçoivent votre certificat personnalisé, modifiez les paramètres par défaut du serveur ALB afin qu'ils pointent vers votre secret « TLS » personnalisé.

Les certificats Let's Encrypt générés par défaut ne sont pas destinés à l'utilisation de la production. Pour les charges de travail de production, apportez votre propre certificat personnalisé.

Lorsque vous créez un cluster classique, IBM fournit un certificat Let's Encrypt pour le secret Ingress par défaut. Si vous créez un secret personnalisé et que vous le spécifiez pour la termina TLS e dans vos ressources Ingress, l'ALB envoie votre certificat personnalisé aux clients à la place du certificat Let's Encrypt. Toutefois, si un client ne prend pas en charge le SNI, l'ALB utilise par défaut le certificat Let's Encrypt, car le secret par défaut figure dans les paramètres de serveur par défaut de l'ALB. Pour envoyer votre certificat personnalisé à des appareils ne prenant pas en charge le SNI, procédez comme suit.

1. Editez la ressource Ingress alb-default-server.

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

2. Dans la section spec.tls, remplacez la valeur du paramètre hosts.secretName par le nom de votre secret personnalisé qui contient votre certificat personnalisé.

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

3. Sauvegardez le fichier de ressources.

4. Vérifiez que la ressource pointe désormais vers votre nom de secret personnalisé. Les modifications sont automatiquement appliquées à vos équilibreurs de charge d'application. Dans la sortie, vérifiez que « spec.tls[].secretName » correspond au nom de votre secret personnalisé.

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

Optimisation des performances de l'équilibreur de charge d'application (ALB)

Les nœuds de travail sont automatiquement configurés avec des paramètres de noyau optimisés, adaptés à la plupart des charges de travail. Si votre cluster présente des exigences spécifiques en matière de haut débit ou de faible latence, vous pouvez modifier les paramètres du noyau Linux(sysctl)sur les nœuds de travail afin d’optimiser davantage les performances de l’ALB. Ne modifiez ces paramètres que si vous avez un besoin précis d'optimisation des performances, car des valeurs incorrectes peuvent déstabiliser le nœud.

Etapes suivantes

• Gérez vos ALB Ingress pour les adapter, les mettre à jour ou les désactiver dans votre cluster.
• Configurez Ingress pour rendre vos applications accessibles à l'aide du service Ingress géré.
• Utilisez le mode débogage d'Ingress pour diagnostiquer et résoudre les problèmes courants liés à Ingress.

Liens connexes

• Documentation Traefik
• Guide de référence du middleware Traefik
• Référence CRD de Traefik
• Documentation IBM Cloud App ID