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

Pour ajouter un port de serveur à la demande du client avant que la demande ne soit transmise à votre application de back end, configurez un proxy vers des services externes dans une annotation de fragment de serveur ou en tant que zone ibm-k8s-controller-config ConfigMap .

Routage des demandes entrantes avec un équilibreur de charge d'application privé

Pour acheminer les demandes entrantes vers vos applications avec un équilibreur de charge d'application privé, spécifiez l'annotation de classe private-iks-k8s-nginx dans la ressource Ingress. Les équilibreurs de charge d'application privés sont configurés pour utiliser des ressources avec cette classe.

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

Authentification des applications avec App ID

Configurez Ingress avec IBM Cloud App ID pour appliquer l'authentification pour vos applications en modifiant des zones Ingress Kubernetes spécifiques. Pour plus d'informations, voir Ajout de l'authentification App ID aux applications.

Définition de la taille maximale du corps de la demande client

Pour définir la taille maximale du corps que le client peut envoyer dans le cadre d'une demande, utilisez l'annotation Kubernetes Ingress resource suivante.

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

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

Vous pouvez désactiver ou activer le stockage des données de réponse sur l'ALB pendant que les données sont envoyées au client. Par défaut, ce paramètre est désactivé. Pour l'activer, définissez l'annotationde ressource Ingress suivante:

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

Personnalisation des délais de connexion et de lecture

Pour définir la durée pendant laquelle l'équilibreur de charge d'application attend de se connecter à l'application de back end et de la lire avant de la considérer comme non disponible, utilisez les annotationssuivantes.

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

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

Personnalisation des actions d'erreur

Pour indiquer les actions personnalisées que l'ALB peut entreprendre pour des erreurs d' HTTP s spécifiques, définissez le champ « custom-http-errors ».

Modification des ports par défaut HTTP et HTTPS

Pour modifier les ports par défaut pour le trafic réseau HTTP (port 80) et HTTPS (port 443), modifiez chaque service ALB avec l' Kubernetes suivante dans les champs Ingress ibm-ingress-deploy-config ConfigMap.

Exemple de paramètre de zone.

httpPort=8080
httpsPort=8443

Personnalisation de l'en-tête de demande

Pour ajouter des informations d'en-tête à une demande client avant de transmettre la demande à votre application de back end, utilisez la zone Kubernetes ibm-k8s-controller-config configmap suivante:

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

Pour les exigences de custom-headers ConfigMap, voir cet exemple.

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

Pour ajouter des informations d'en-tête à une réponse client avant de l'envoyer au client, utilisez l'annotationsuivante.

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

Ajouter des définitions de chemin aux services externes

Pour ajouter des définitions de chemin à des services externes, tels que des services hébergés dans IBM Cloud, configurez un proxy vers des services externes dans un fragment d'emplacement. Ou bien, remplacez le proxy par une redirection permanente vers des services externes.

Redirection des demandes non sécurisées

Par défaut, les requêtes client non sécurisées d' HTTP s sont redirigées vers HTTPS. Pour désactiver ce paramètre, utilisez la zone et l'annotation suivantes.

• ibm-k8s-controller-config Zone ConfigMap

  ssl-redirect: "false"
  

• Annotationde ressource Ingress:

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

Activation et désactivation de l' HTTP Sécurité de transport stricte

Définissez le navigateur pour accéder au domaine uniquement à l'aide de HTTPS. Cette option est activée par défaut.

• Pour ajouter l'âge maximum et la granularité des sous-domaines, voir ce blog NGINX.
• Pour le désactiver, définissez le champ ibm-k8s-controller-config configmap.

  hsts: false
  

Définition d'un nombre maximal de demandes de signal de présence

Pour définir le nombre maximal de demandes pouvant être traitées via une connexion persistante, utilisez la zone Kubernetes ibm-k8s-controller-config configmap suivante.

keep-alive-requests: 100

La valeur par défaut de keep-alive-requests dans Kubernetes Ingress est 100, ce qui est beaucoup moins que la valeur par défaut de 4096 dans IBM Cloud Kubernetes Service Ingress. Si vous avez migré votre configuration Ingress depuis IBM Cloud Kubernetes Service Ingress vers Kubernetes Ingress, il vous faudra peut-être modifier keep-alive-requests pour réussir les tests de performance existants.

Définition d'un délai maximal de demande de signal de présence

Pour définir la durée maximale pendant laquelle une connexion persistante reste ouverte entre le client et le serveur proxy ALB, utilisez la zone Kubernetes ibm-k8s-controller-config configmap suivante.

keep-alive: 60

Définition d'un nombre maximal de mémoires tampon d'en-tête de client de grande taille

Pour définir le nombre maximal et la taille des mémoires tampon qui lisent les en-têtes de demande client volumineux, utilisez la zone Kubernetes ibm-k8s-controller-config configmap suivante.

large-client-header-buffers: 4 8k

Modification de la façon dont l'équilibreur de charge d'application correspond à l'URI de la demande

Pour modifier la façon dont l'équilibreur de charge d'application met en correspondance l'URI de la demande avec le chemin d'application, utilisez l'annotation Kubernetes Ingress resource suivante.

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

Pour plus d'informations, voir ce blogue.

Ajout de configurations de blocs d'emplacement personnalisées

Pour ajouter une configuration de bloc d'emplacement personnalisé pour un service, utilisez l'annotation Kubernetes Ingress resource suivante.

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

Configuration de l'authentification mutuelle

Pour configurer l'authentification mutuelle pour l'équilibreur de charge d'application, utilisez la Kubernetes ressource Ingress annotationssuivante. Notez que l'authentification mutuelle ne peut pas être appliquée aux ports personnalisés et doit être appliquée au port HTTPS.

nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
nginx.ingress.kubernetes.io/auth-tls-error-page: "http://www.mysite.com/error-cert.html"
nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"

Configuration de la taille de mémoire tampon du proxy

Pour configurer la taille de la mémoire tampon de proxy qui lit la première partie de la réponse, utilisez l'annotation Kubernetes Ingress resource suivante.

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

Configuration des numéros de mémoire tampon de proxy

Pour configurer le nombre de mémoires tampon de proxy pour l'équilibreur de charge d'application, utilisez l'annotation Kubernetes Ingress resource suivante.

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

Configuration de la taille de la mémoire tampon du proxy occupée

Pour configurer la taille des mémoires tampon de proxy pouvant être occupées, utilisez un fragment d'emplacement. Pour plus d'informations, voir la documentation de NGINX.

Configuration lorsqu'un équilibreur de charge d'application peut transmettre une demande

Pour définir quand l'équilibreur de charge d'application peut transmettre une demande au prochain serveur en amont, utilisez les zones Kubernetes Ingress suivantes.

• Paramètre global: ibm-k8s-controller-config ConfigMap zones:

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

• Paramètre par ressource: annotationsde ressource Ingress:

  nginx.ingress.kubernetes.io/proxy-next-upstream: http_500
  nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: 50
  nginx.ingress.kubernetes.io/proxy-next-upstream-tries: 3
  

Limitation de débit

Pour limiter le débit de traitement des demandes et le nombre de connexions par clé définie pour les services, utilisez les annotations de limitation de débitde la ressource Ingress.

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

Vous pouvez supprimer les informations d'en-tête qui sont incluses dans la réponse du client à partir de l'application finale back-end avant que la réponse ne soit envoyée au client. Configurez la suppression de l'en-tête de réponse dans un fragment d'emplacementou utilisez la zone proxy_hide_header en tant que fragment de configuration dans ibm-k8s-controller-config ConfigMap.

Réécriture des chemins

Pour acheminer le trafic réseau entrant sur un chemin de domaine ALB vers un autre chemin sur lequel votre application de back end est à l'écoute, utilisez l'annotation Kubernetes Ingress resource suivante.

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

Personnalisation des configurations de bloc serveur

Pour ajouter une configuration de bloc de serveur personnalisé, utilisez l'annotation Kubernetes Ingress resource suivante.

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

Routage du trafic réseau entrant

Pour toujours router le trafic réseau entrant vers le même serveur en amont à l'aide d'un cookie de maintien de routage, utilisez la Kubernetes ressource Ingress annotationssuivante.

nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "cookie_name1"
nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
nginx.ingress.kubernetes.io/configuration-snippet: |
  more_set_headers "Set-Cookie: HttpOnly";

Le contrôleur Kubernetes Ingress ajoute les attributs Secure et HttpOnly aux cookies persistants par défaut qui ne peuvent pas être modifiés.

Autorisation de la prise en charge des services SSL pour chiffrer le trafic

Pour permettre aux services SSL de prendre en charge le chiffrement du trafic vers vos applications en amont qui nécessitent HTTPS, utilisez l'annotation de protocole backend de ressource Kubernetes Ingress et les annotations d'authentification de certificat backend.

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
nginx.ingress.kubernetes.io/proxy-ssl-secret: app1-ssl-secret
nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: 5
nginx.ingress.kubernetes.io/proxy-ssl-name: proxy-ssl-name=mydomain.com
nginx.ingress.kubernetes.io/proxy-ssl-verify: true

Accès aux applications avec des ports TCP non standard

Pour accéder à une application via un port TCP non standard, procédez comme suit.

1. Créez une mappe de configuration (configmap) tcp-services pour spécifier votre port TCP (voir les exemples de port suivants). Pour les exigences du site tcp-services ConfigMap,, voir ce blog.

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

2. Créez la mappe de configuration dans l'espace de noms kube-system.

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

3. Spécifiez la mappe de configuration tcp-services en tant que zone dans la mappe de configuration ibm-ingress-deploy-config.

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

4. Modifiez chaque service d'équilibreur de charge d'application pour ajouter les ports.

Définition d'un nombre maximal de demandes de signal de présence en amont

Pour définir le nombre maximal de demandes pouvant être traitées via une connexion persistante, utilisez la zone Kubernetes ibm-k8s-controller-config ConfigMap suivante.

upstream-keepalive-requests: 32

Définition du délai d'attente maximal de signal de présence en amont

Pour définir la durée maximale pendant laquelle une connexion persistante reste ouverte entre le serveur proxy ALB et le serveur en amont de votre application, utilisez la zone Kubernetes ibm-k8s-controller-config configmap suivante.

upstream-keepalive-timeout: 32

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

Personnalisez le déploiement des équilibreurs de charge d'application qui exécutent l'image Kubernetes Ingress en créant une mappe de configuration ibm-ingress-deploy-config.

1. Récupérez les noms des services qui exposent chaque équilibreur de charge d'application.

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

     kubectl get svc -n kube-system | grep LoadBalancer
     

Personnalisation de la classe Ingress

Une classe Ingress associe un nom de classe à un type de contrôleur Ingress. Utilisez la ressource IngressClass pour personnaliser les classes Ingress.

Ajout de l'authentification App ID à des applications

Renforcez l'authentification de vos applications en configurant Ingress à l'aide de la fonction IBM Cloud App ID.

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 de service ne contient que des caractères alphanumériques 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 peut 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é, l'utilisateur ne sera pas authentifié mais recevra un jeton d'accès 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. Notez que toute les lettres du nom de l'instance de service doivent être spécifiées en minuscules.

   Si vous utilisez la fonction de déconnexion IBM Cloud App ID, vous devez ajouter /sign_out à votre domaine au format https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out et inclure cette URL dans la liste des URL de redirection. Si vous souhaitez utiliser une page de déconnexion personnalisée, vous devez définir whitelist_domains dans l' ConfigMap e de OAuth2-Proxy. Appelez le noeud final 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 votre page de déconnexion personnalisée. Pour plus de détails, voir Déconnexion.

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, ou vous pouvez inclure l'option --key pour utiliser les informations d'identification de la clé de service existante. Veillez à lier l'instance de service à l'espace de noms dans lequel se trouvent les ressources Ingress. Notez que toute les lettres du nom de l'instance de service doivent être spécifiées 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 que le service a été correctement lié à votre cluster, un secret de cluster est créé pour héberger les données d'identification de votre instance de service. Exemple de sortie d'interface de ligne de commande :

   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. Ce module complémentaire crée et gère les ressources Kubernetes suivantes : un déploiement OAuth2-Proxy pour votre instance de service App ID, un secret qui contient la configuration du déploiement OAuth2-Proxy et une ressource Ingress qui configure les équilibreurs de charge d'application de sorte qu'ils acheminent les demandes entrantes vers le déploiement OAuth2-Proxy de votre instance App ID. Le nom de chacune de ces ressources 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.

      ibmcloud ks cluster addon ls --cluster <cluster_name_or_ID>
      

5. Dans les ressources Ingress pour les applications dans lesquelles vous souhaitez ajouter l'authentification App ID, assurez-vous que le nom de la ressource ne dépasse pas 25 caractères. Ajoutez ensuite les annotations suivantes à la section metadata.annotations.

   1. Ajoutez l'annotation auth-url ci-après. Cette annotation spécifie l'URL d'OAuth2-Proxy pour votre instance App ID, qui sert de partie utilisatrice OIDC pour App ID. Notez que toute les lettres du nom de l'instance de service doivent être spécifiées en minuscules.

      ...
      annotations:
         nginx.ingress.kubernetes.io/auth-url: https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth
      ...
      

   2. Parfois, le cookie d'authentification utilisé par OAuth2-Proxy dépasse 4 Ko. Il est donc divisé en deux parties. Le fragment suivant doit être ajouté pour s'assurer que les deux cookies peuvent être correctement mis à jour par OAuth2-Proxy.

      ...
      annotations:
          nginx.ingress.kubernetes.io/configuration-snippet: |
          auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
          access_by_lua_block {
              if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
              ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
              end
          }
      ...
      

   3. Sélectionnez les jetons à envoyer à votre application dans l'en-tête Authorization. Pour plus d'informations sur les jetons d'identification et d'accès, voir la documentation de App ID.

      • Pour envoyer uniquement le site ID Token, ajoutez l'annotation suivante :

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

      • Pour envoyer uniquement le site Access Token, ajoutez les informations suivantes à l'annotation configuration-snippet. (Cela étend le fragment de l'étape 5.2.)

        ...
        annotations:
            nginx.ingress.kubernetes.io/configuration-snippet: |
            auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
            auth_request_set $access_token $upstream_http_x_auth_request_access_token;
            access_by_lua_block {
                if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
                ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
                end
                if ngx.var.access_token ~= "" then
                ngx.req.set_header("Authorization", "Bearer " .. ngx.var.access_token)
                end
            }
        ...
        

      • Pour envoyer le Access Token et le ID Token, ajoutez les informations suivantes à l'annotation configuration-snippet. (Cela étend le fragment de l'étape 5.2.)

        ...
         annotations:
            nginx.ingress.kubernetes.io/configuration-snippet: |
            auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
            auth_request_set $access_token $upstream_http_x_auth_request_access_token;
            auth_request_set $id_token $upstream_http_authorization;
            access_by_lua_block {
                if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
                ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
                end
                if ngx.var.id_token ~= "" and ngx.var.access_token ~= "" then
                ngx.req.set_header("Authorization", "Bearer " .. ngx.var.access_token .. " " .. ngx.var.id_token:match("%s*Bearer%s*(.*)"))
                end
            }
        ...
        

   4. Facultatif : si votre application prend en charge la stratégie d'application Web en plus ou au lieu de la stratégie d'API, ajoutez l'annotation nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2-<App_ID_service_instance_name>/start?rd=$escaped_request_uri. Notez que toutes les lettres du nom de l'instance de service doivent être en minuscules.

      • Si vous spécifiez cette annotation et que l'authentification d'un client échoue, le client est redirigé vers l'URL d'OAuth2-Proxy pour votre instance App ID. Ce proxy OAuth2-Proxy, qui sert de partie utilisatrice OIDC pour App ID, redirige le client vers votre page de connexion App ID à des fins d'authentification.
      • Si vous ne spécifiez pas cette annotation, un client doit s'authentifier avec un jeton bearer valide. Si l'authentification d'un client échoue, la demande du client est rejetée avec le message d'erreur 401 Unauthorized.

6. Réappliquez vos ressources Ingress pour imposer l'authentification App ID. Une fois qu'une ressource Ingress avec les annotations appropriées a été réappliquée, le module complémentaire du proxy OAuth d'équilibreur de charge d'application procède à un déploiement OAuth2-Proxy, crée un service pour le déploiement et crée une ressource Ingress distincte pour configurer le routage des messages de déploiement OAuth2-Proxy. Ne supprimez pas ces ressources complémentaires.

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

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

   • Si vos applications prennent 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és vers une page de connexion d'authentification App ID.
   • Si vos applications prennent en charge la stratégie d'API : spécifiez votre jeton d'accès Bearer dans l'en-tête Authorization des demandes 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 demandes à vos applications sans jeton d'accès dans l'en-tête Authorization ou si App ID n'accepte pas le jeton d'accès, la demande est rejetée.

8. Facultatif : Si vous utilisez des stratégies de réseau ou une autre solution de pare-feu sur votre cluster pour limiter le trafic sortant, vous devez vous assurer d'autoriser l'accès au service public AppID's à partir de votre cluster. Pour obtenir la plage d'adresses IP de ce service, il faut en faire la demande auprès du service d'assistance à la clientèle.

9. 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 backend app via the X-Forwarded-Access-Token header.
        request_logging: <true|false>
        # Log all requests to the backend app.
        request_logging_format:
        # Format for request logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#request-log-format
        scope:
        # Scope of the OAuth authentication. For more info, see https://oauth.net/2/scope/
        set_authorization_header: <true|false>
        # Set the Authorization Bearer response header when the app responds to the Ingress ALB, such when using the NGINX auth_request mode.
        set_xauthrequest: <true|false>
        # Set X-Auth-Request-User, X-Auth-Request-Email, and X-Auth-Request-Preferred-Username response headers when the app responds to the Ingress ALB, such as when using the NGINX auth_request mode.
        standard_logging: <true|false>
        # Log standard runtime information.
        standard_logging_format:
        # Format for standard logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#standard-log-format
        tls_secret_name:
        # The name of a secret that contains the server-side TLS certificate and key to enable TLS between the OAuth2-Proxy and the Ingress ALB. By default, the TLS secret defined in your Ingress resources is used.
        whitelist_domains:
        # Allowed domains for redirection after authentication. Default: "". Example: example.com,*.example2.com For more info, see: https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#command-line-options
        oidc_extra_audiences:
        # Additional audiences which are allowed to pass verification.
        cookie_refresh:
        # Refresh the cookie after this duration. Example: "15m". To use this feature, you must enable "Refresh token" for the AppID instance. For more info, see: /docs/appid?topic=appid-managing-idp&interface=ui#idp-token-lifetime
      

   2. Appliquez la ressource de mappe de configuration (ConfigMap) à votre module complémentaire. Vos modifications sont appliquées automatiquement.

      kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
      

Pour obtenir la liste des modifications apportées à chaque version du module complémentaire ALB OAuth Proxy, consultez le journal des modifications du module complémentaire ALB OAuth Proxy à l'adresse IBM Cloud.

Conservation de l'adresse IP source

Par défaut, les adresses IP source des demandes client ne sont pas conservées par l'équilibreur de charge d'application Ingress. Pour conserver les adresses IP source, vous pouvez activer le protocole PROXY dans les clusters de VPC ou modifier la règle externalTrafficPolicy dans les clusters classiques.

Configuration de protocoles et de chiffrements SSL au niveau HTTP

Activez les protocoles et chiffrements SSL au niveau HTTP global en éditant la ressource configmap ibm-k8s-controller-config.

Par exemple, si vous avez toujours des clients qui nécessitent la prise en charge de TLS 1.0 ou 1.1, vous devez activer manuellement ces versions TLS pour remplacer le paramétrage par défaut uniquement pour TLS 1.2 et TLS 1.3.

Lorsque vous indiquez les protocoles activés pour tous les hôtes, les paramètres TLSv1.1 et TLSv1.2 (1.1.13, 1.0.12) fonctionnent uniquement avec l'utilisation d'OpenSSL 1.0.1 ou version supérieure. Le paramètre TLSv1.3 (1.13.0) fonctionne uniquement avec l'utilisation d'OpenSSL 1.1.1 généré avec le support TLSv1.3.

Pour éditer le fichier configmap pour activer les chiffrements et protocoles SSL :

1. Editez le fichier de configuration correspondant à la ressource configmap ibm-k8s-controller-config.

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

2. Ajoutez les chiffrements et protocoles SSL. Formater les chiffres selon le format de la liste de chiffrement de la bibliothèque OpenSSL.

   apiVersion: v1
   data:
     ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2 TLSv1.3"
     ssl-ciphers: "HIGH:!aNULL:!MD5:!CAMELLIA:!AESCCM:!ECDH+CHACHA20"
   kind: ConfigMap
   metadata:
     name: ibm-k8s-controller-config
     namespace: kube-system
   

3. Sauvegardez le fichier de configuration.

4. Vérifiez que les modifications apportées à configmap ont été appliquées. Les modifications sont automatiquement appliquées à vos équilibreurs de charge d'application.

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

Envoi de votre certificat personnalisé aux clients existants

Si vous disposez déjà d'unités qui ne prennent pas en charge l'indication de nom de serveur (SNI) et que vous utilisez un certificat TLS personnalisé dans vos ressources Ingress, vous devez modifier les paramètres du serveur de l'ALB pour utiliser votre certificat TLS personnalisé et le secret TLS personnalisé.

Lorsque vous créez un cluster classique, un certificat Let's Encrypt est généré pour le secret Ingress par défaut fourni par IBM. Si vous créez un secret personnalisé dans votre cluster et que vous spécifiez ce secret personnalisé pour la terminaisons TLS dans vos ressources Ingress, l'équilibreur de charge d'application Ingress envoie le certificat pour votre secret personnalisé au client au lieu du certificat Let's Encrypt par défaut. Toutefois, si un client ne prend pas en charge SNI, l'équilibreur de charge d'application Ingress prend par défaut le certificat Let's Encrypt car le secret par défaut est répertorié dans les paramètres de serveur par défaut de l'équilibreur de charge d'application. Pour envoyer votre certificat personnalisé à des unités qui ne prennent pas en charge SNI, procédez comme suit pour modifier les paramètres de serveur par défaut de l'ALB sur votre secret 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é.

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é. Exemple :

   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.

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

Amélioration de la gestion des connexions

Les paramètres client-header-timeout, client-body-timeout et keep-alive sont des configurations cruciales qui déterminent la durée pendant laquelle les connexions restent actives entre les clients, le contrôleur Ingress et les serveurs dorsaux. Ces délais jouent un rôle important dans l'optimisation du traitement des demandes, en particulier lorsqu'il s'agit de connexions client de longue durée, de réponses retardées de la part des serveurs dorsaux et de la protection de ressources précieuses contre une occupation inutile.

L'adresse client-header-timeout définit la durée maximale pendant laquelle le serveur attend un en-tête client complet. De même, client-body-timeout indique la durée pendant laquelle le serveur attend que le client envoie le corps de la requête. Ces deux délais doivent être alignés sur le paramètre keep-alive, qui régit la durée pendant laquelle le serveur maintient une connexion ouverte en attendant d'autres demandes. Si ces délais ne correspondent pas au paramètre keep-alive, NGINX mettra fin à la connexion, ce qui pourrait entraîner un comportement inattendu du client ou des échecs de requête.

Vous pouvez définir les paramètres ci-dessus dans l'espace de noms ibm-k8s-controller-config ConfigMap kube-system.

apiVersion: v1
kind: ConfigMap
metadata:
  name: ibm-k8s-controller-config
  namespace: kube-system
data:
  ...
  client-body-timeout: "100"
  client-header-timeout: "100"
  keep-alive: "100"

Pour plus d'informations, voir le site client-header-timeout, client-body-timeout et keep-alive dans la documentation Ingress Nginx.

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

Pour optimiser les performances de vos équilibreurs de charge d'application Ingress, vous pouvez modifier les paramètres par défaut selon vos besoins.