Adición de un puerto de servidor a una cabecera de host

Para añadir un puerto de servidor a la solicitud del cliente antes de que la solicitud se reenvíe a su aplicación back-end, configure un proxy a servicios externos en una anotación de fragmento de servidor o como un campo ibm-k8s-controller-config ConfigMap.

Direccionamiento de solicitudes entrantes con un ALB privado

Para direccionar las solicitudes entrantes a las apps con un ALB privado, especifique la anotación de clase private-iks-k8s-nginx en el recurso de Ingress. Los ALB privados están configurados para utilizar recursos con esta clase.

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

Autenticación de apps con App ID

Configure Ingress con IBM Cloud App ID para reforzar la autenticación de sus aplicaciones cambiando campos específicos de Kubernetes Ingress. Consulte Añadir autenticación App ID a las aplicaciones para obtener más información.

Establecimiento del tamaño máximo de cuerpo de solicitud de cliente

Para establecer el tamaño máximo del cuerpo que el cliente puede enviar como parte de una solicitud, utilice la siguiente anotación de recurso Kubernetes Ingress.

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

Habilitación e inhabilitación del almacenamiento intermedio de datos de respuesta del cliente

Puede desactivar o activar el almacenamiento de datos de respuesta en el ALB mientras los datos se envían al cliente. Este valor está inhabilitado de forma predeterminada. Para habilitarlo, establezca la siguiente anotaciónde recurso de Ingress.

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

Personalización de los tiempos de espera de conexión y lectura

Para establecer la cantidad de tiempo que el ALB espera para conectarse y leer de la app de fondo antes de que la app de fondo se considere no disponible, utilice las anotacionessiguientes.

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

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

Personalización de acciones de error

Para indicar acciones personalizadas que el ALB puede tomar para errores específicos de HTTP, configure el campo custom-http-errors.

Cambiar los puertos predeterminados HTTP y HTTPS

Para cambiar los puertos predeterminados para el tráfico de red HTTP (puerto 80) y HTTPS (puerto 443), modifique cada servicio ALB con los siguientes campos Kubernetes Ingress ibm-ingress-deploy-config ConfigMap.

Valor de campo de ejemplo.

httpPort=8080
httpsPort=8443

Personalización de la cabecera de solicitud

Para añadir información de encabezado a una solicitud de cliente antes de reenviarla a tu aplicación de back-end, utiliza el siguiente campodel mapa de configuración « Kubernetes » ibm-k8s-controller-config

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

Para conocer los requisitos de ConfigMapcustom-headers, consulta este ejemplo.

Personalización de la cabecera de respuesta

Para añadir información de cabecera a una respuesta de cliente antes de enviarla al cliente, utilice la siguiente anotación.

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

Añadir definiciones de rutas a servicios externos

Para añadir definiciones de ruta a servicios externos, como servicios alojados en IBM Cloud, configure un proxy a servicios externos en un fragmento de ubicación. O bien, sustituya el proxy por una redirección permanente a servicios externos.

Redirección de solicitudes no seguras

Por defecto, las peticiones inseguras de los clientes de HTTP redirigen a HTTPS. Para inhabilitar este valor, utilice el campo y la anotación siguientes.

• ibm-k8s-controller-config ConfigMap campo

  ssl-redirect: "false"
  

• Anotaciónde recurso de Ingress:

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

Habilitar y deshabilitar HTTP Seguridad estricta en el transporte

Configure al navegador para acceder al dominio utilizando únicamente HTTPS. Esta opción está habilitada de forma predeterminada.

• Para añadir la antigüedad máxima y la granularidad de los subdominios, consulta esta entrada del blog de NGINX.
• Para desactivarlo, configura el campo configmap ibm-k8s-controller-config.

  hsts: false
  

Establecimiento de un número máximo de solicitudes de estado activo

Para establecer el número máximo de peticiones que se pueden servir a través de una conexión keepalive, utilice el siguiente campo Kubernetes ibm-k8s-controller-config configmap.

keep-alive-requests: 100

El valor por defecto de en keep-alive-requests el Ingress de Kubernetes es 100, que es mucho menor que el valor por defecto de 4096 en el Ingress de IBM Cloud Kubernetes Service. Si ha migrado la configuración de Ingress de Ingress de IBM Cloud Kubernetes Service a Ingress de Kubernetes, es posible que tenga que cambiar keep-alive-requests para pasar las pruebas de rendimiento existentes.

Establecimiento de un tiempo de espera máximo de solicitud de estado activo

Para establecer el tiempo máximo que una conexión keepalive permanece abierta entre el cliente y el servidor proxy ALB, utilice el siguiente campo Kubernetes ibm-k8s-controller-config configmap.

keep-alive: 60

Establecimiento de un número máximo de almacenamientos intermedios de cabecera de cliente grandes

Para establecer el número y tamaño máximos de los búferes que leen las cabeceras grandes de las peticiones de los clientes, utilice el siguiente campo Kubernetes ibm-k8s-controller-config configmap.

large-client-header-buffers: 4 8k

Modificación del modo en que el ALB coincide con el URI de solicitud

Para modificar la forma en que el ALB compara el URI de la solicitud con la ruta de la aplicación, utilice la siguiente anotación de recurso de entrada Kubernetes.

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

Para obtener más información, consulte este blog.

Adición de configuraciones de bloque de ubicación personalizadas

Para añadir una configuración de bloque de ubicación personalizada para un servicio, utilice la siguiente anotación de recurso Kubernetes Ingress.

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

Configuración de la autenticación mutua

Para configurar la autenticación mutua para el ALB, utilice las siguientes anotaciones de recursos Kubernetes Ingress. Tenga en cuenta que la autenticación mutua no se puede aplicar en los puertos personalizados y se debe aplicar en puerto 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"

Configuración del tamaño del almacenamiento intermedio de proxy

Para configurar el tamaño del búfer del proxy que lee la primera parte de la respuesta, utilice la siguiente anotación de recurso Kubernetes Ingress.

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

Configuración de números de almacenamiento intermedio de proxy

Para configurar el número de búferes proxy para el ALB, utilice la siguiente anotación de recurso Kubernetes Ingress.

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

Configuración del tamaño de almacenamiento intermedio de proxy ocupado

Para configurar el tamaño de los almacenamientos intermedios de proxy que pueden estar ocupados, utilice un fragmento de código de ubicación. Para más información, consulta la documentación de NGINX.

Configuración de cuándo un ALB puede pasar una solicitud

Para establecer cuándo el ALB puede pasar una solicitud al siguiente servidor ascendente, utilice los siguientes campos Kubernetes Ingress.

• Valor global: ibm-k8s-controller-config ConfigMap fields:

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

• Valor por recurso: anotacionesde recurso de 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
  

Limitación de velocidad

Para limitar la velocidad de proceso de solicitudes y el número de conexiones por clave definida para servicios, utilice las anotacionesde recursos de Ingress para limitar la velocidad.

Eliminación de la cabecera de respuesta

Puede eliminar la información de encabezado incluida en la respuesta al cliente desde la aplicación de back-end antes de que la respuesta se envíe al cliente. Configure la eliminación del encabezado de respuesta en un fragmento de ubicación, o utilice el proxy_hide_header campo como un fragmento de configuración en el ibm-k8s-controller-config ConfigMap.

Reescritura de vías de acceso

Para enrutar el tráfico de red entrante en una ruta de dominio ALB a una ruta diferente en la que su aplicación back-end escucha, utilice la siguiente anotación de recurso Kubernetes Ingress.

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

Personalización de configuraciones de bloques de servidor

Para añadir una configuración de bloque de servidor personalizada, utilice la siguiente anotación de recurso Kubernetes Ingress.

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

Direccionamiento del tráfico de red de entrada

Para enrutar siempre el tráfico de red entrante al mismo servidor ascendente utilizando una cookie pegajosa, utilice las siguientes anotaciones de recursos Kubernetes Ingress.

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

El controlador de Ingress de Kubernetes añade los atributos Secure y HttpOnly a las cookies permanentes de forma predeterminada, y este comportamiento no se puede cambiar.

Permitir el soporte de servicios SSL para cifrar el tráfico

Para permitir el soporte de servicios SSL para cifrar el tráfico a sus aplicaciones ascendentes que requieren HTTPS, utilice el recurso Kubernetes Ingress anotación de protocolo backend y el anotaciones de autenticación de certificados 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

Acceso a aplicaciones con puertos no estándar TCP

Para acceder a una aplicación a través de un puerto no estándar TCP, sigue estos pasos.

1. Cree un mapa de configuración tcp-services para especificar el puerto TCP, como por ejemplo los puertos de ejemplo siguientes. Para conocer los requisitos del ConfigMap,tcp-services, consulta este blog.

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

2. Cree el mapa de configuración en el espacio de nombres kube-system.

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

3. Especifica el como tcp-servicesConfigMap campo en el ibm-ingress-deploy-config ConfigMap.

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

4. Modifique cada uno de los servicios ALB para añadir los puertos.

Establecimiento de un número máximo de solicitudes de estado activo en sentido ascendente

Para establecer el número máximo de peticiones que se pueden servir a través de una conexión keepalive, utilice el siguiente campo Kubernetes ibm-k8s-controller-config ConfigMap.

upstream-keepalive-requests: 32

Establecimiento del tiempo de espera máximo de estado activo en sentido ascendente

Para establecer el tiempo máximo que una conexión keepalive permanece abierta entre el servidor proxy ALB y el servidor upstream de tu aplicación, utiliza el siguiente campo configmap Kubernetes ibm-k8s-controller-config.

upstream-keepalive-timeout: 32

Personalización del despliegue de ALB

Personalice el despliegue de los ALB que ejecutan la imagen de Ingress de Kubernetes creando un mapa de configuración ibm-ingress-deploy-config.

1. Obtenga los nombres de los servicios que exponen cada ALB.

   • Clústeres clásicos:

       kubectl get svc -n kube-system | grep alb
       ```
   * Clústeres de VPC: en la salida, busque un nombre de servicio con un formato como, por ejemplo, `public-crc204dl7w0qf6n6sp7tug`.
   
   ```sh {: pre}
       kubectl get svc -n kube-system | grep LoadBalancer
       ```
   

Personalización de la clase de Ingress

Una clase de Ingress asocia un nombre de clase con un tipo de controlador de Ingress. Utilice el recurso IngressClass para personalizar las clases de Ingress.

Adición de autenticación de App ID a apps

Aplica la autenticación en tus aplicaciones configurando Ingress con IBM Cloud App ID.

1. Elija una existente o cree una nueva instancia de App ID.

   Una instancia de App ID se puede utilizar sólo en un espacio de nombres del clúster. Si desea configurar App ID para recursos de Ingress en varios espacios de nombres, repita los pasos de esta sección para especificar una instancia de App ID exclusiva para los recursos de Ingress en cada espacio de nombres.

   • Para utilizar una instancia existente, asegúrese de que el nombre de instancia de servicio contenga sólo minúsculas caracteres alfanuméricos y su longitud no supere los 25 caracteres. Para cambiar el nombre, seleccione Renombrar servicio en el menú Más opciones de la página de detalles de la instancia de servicio.
   • Para suministrar una nueva instancia de App ID:
     1. Sustituya el nombre del servicio por su propio nombre exclusivo para la instancia de servicio. El nombre de la instancia de servicio debe contener solo caracteres alfanuméricos en minúsculas y no puede tener más de 25 caracteres.
     2. Elija la región en la que se ha desplegado el clúster.
     3. Pulse Crear.

2. Añada los URL de redirección para la app. Un URL de redirección es el punto final de devolución de llamada de la app. Para evitar ataques de suplantación, IBM Cloud App ID valida el URL de solicitud comparándolo con la lista blanca de los URL de redirección.

   1. En la consola de gestión de App ID, vaya a Gestionar autenticación.
   2. En el separador Proveedores de identidades, asegúrese de tener seleccionado un proveedor de identidades. Si no se selecciona ningún proveedor de identidad, el usuario no será autenticado, pero se le asignará un token de acceso para acceder de forma anónima a la aplicación.
   3. En el separador Valores de autenticación, añada los URL de redirección para la aplicación en el formato https://<hostname>/oauth2-<App_ID_service_instance_name>/callback. Tenga en cuenta que todas las letras del nombre de la instancia de servicio deben especificarse en minúsculas.

   Si utiliza la función de cierre de sesión de IBM Cloud App ID, debe añadir /sign_out al dominio en el formato https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out e incluir este URL en la lista de URL de redirección. Si desea utilizar una página de cierre de sesión personalizada, debe configurar whitelist_domains en ConfigMap para OAuth2-Proxy. Llame al punto final https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out con el parámetro de consulta rd o establezca la cabecera X-Auth-Request-Redirect con la página de cierre de sesión personalizada. Para obtener más detalles, consulte Cerrar sesión.

3. Enlace la instancia de servicio de App ID al clúster. El comando crea una clave de servicio para la instancia del servicio; también puede incluir la opción --key para utilizar las credenciales de la clave de servicio ya existentes. Asegúrese de vincular la instancia de servicio con el mismo espacio de nombres en el que existen los recursos de Ingress. Tenga en cuenta que todas las letras del nombre de la instancia de servicio deben especificarse en minúsculas.

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

   Cuando el servicio se ha vinculado correctamente al clúster, se crea un secreto de clúster que contiene las credenciales de la instancia de servicio. Ejemplo de salida de CLI:

   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. Habilite el complemento ALB OAuth Proxy en el clúster. Este complemento crea y gestiona los siguientes recursos de Kubernetes: un despliegue de OAuth2-Proxy para su instancia de servicio de App ID, un secreto que contiene la configuración del despliegue de OAuth2-Proxy y un recurso de Ingress que configura los ALB para que direccionen solicitudes entrantes al despliegue de OAuth2-Proxy para la instancia de App ID. El nombre de cada uno de estos recursos empieza por oauth2-.

   1. Habilite el complemento alb-oauth-proxy.

       ibmcloud ks cluster addon enable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID
       ```
   2. Verifique que el complemento ALB OAuth Proxy tenga un estado `Addon Ready`.
   ```sh {: pre}
       ibmcloud ks cluster addon ls --cluster CLUSTER_NAME_OR_ID
       ```
   

5. En los recursos de Ingress para las apps en las que desea añadir la autenticación de App ID, asegúrese de que el nombre de recurso no supere los 25 caracteres de longitud. A continuación, añada las anotaciones siguientes a la sección metadata.annotations.

   1. Añada la siguiente anotación auth-url. Esta anotación especifica el URL de OAuth2-Proxy para la instancia de App ID, que actúa como OIDC Relying Party (RP) para App ID. Tenga en cuenta que todas las letras del nombre de la instancia de servicio deben especificarse en minúsculas.

       ...
       annotations:
          nginx.ingress.kubernetes.io/auth-url: https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth
       ...
       ```
   2. A veces, la cookie de autenticación utilizada por `OAuth2-Proxy` supera los 4 KB. Por lo tanto, se divide en dos partes. Se debe añadir el siguiente fragmento de código para asegurarse de que `OAuth2-Proxy` pueda actualizar correctamente ambas cookies.
   ```yaml {: codeblock}
       ...
       annotations:
           nginx.ingress.kubernetes.io/configuration-snippet: |
           auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
           access_by_lua_block {
               if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
               ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
               end
           }
       ...
       ```
   
   3. Elija qué señales enviar en la cabecera `Authorization` a la app. Para obtener más información sobre los tokens de identificación y de acceso, consulta la [documentación de App ID.](/docs/appid?topic=appid-tokens){: external}
       * Para enviar solo el `ID Token`, añade la siguiente anotación:
   
           ```yaml {: codeblock}
           ...
           annotations:
               nginx.ingress.kubernetes.io/auth-response-headers: Authorization
           ...
           ```
       * Para enviar solo el `Access Token`, añade la siguiente información a la anotación `configuration-snippet`. (Esto amplía el fragmento de código del paso 5.2.)
   
           ```yaml {: codeblock}
           ...
           annotations:
               nginx.ingress.kubernetes.io/configuration-snippet: |
               auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
               auth_request_set $access_token $upstream_http_x_auth_request_access_token;
               access_by_lua_block {
                   if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
                   ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
                   end
                   if ngx.var.access_token ~= "" then
                   ngx.req.set_header("Authorization", "Bearer " .. ngx.var.access_token)
                   end
               }
           ...
           ```
       * Para enviar el y `Access Token` el `ID Token`, añade la siguiente información a la anotación `configuration-snippet` del. (Esto amplía el fragmento de código del paso 5.2.)
           ```yaml {: codeblock}
           ...
            annotations:
               nginx.ingress.kubernetes.io/configuration-snippet: |
               auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
               auth_request_set $access_token $upstream_http_x_auth_request_access_token;
               auth_request_set $id_token $upstream_http_authorization;
               access_by_lua_block {
                   if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
                   ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
                   end
                   if ngx.var.id_token ~= "" and ngx.var.access_token ~= "" then
                   ngx.req.set_header("Authorization", "Bearer " .. ngx.var.access_token .. " " .. ngx.var.id_token:match("%s*Bearer%s*(.*)"))
                   end
               }
           ...
           ```
   4. Opcional: si la aplicación admite la [estrategia de aplicación web](/docs/appid?topic=appid-key-concepts#term-web-strategy), además de la [estrategia de API](/docs/appid?topic=appid-key-concepts#term-api-strategy) (o en su lugar), añada la anotación `nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2-<App_ID_service_instance_name>/start?rd=$escaped_request_uri`. Ten en cuenta que todas las letras del nombre de la instancia del servicio deben estar en minúsculas.
       * Si especifica esta anotación, y la autenticación para un cliente falla, el cliente se redirige al URL del proxy OAuth2 para la instancia de App ID. Este OAuth2-Proxy, que actúa como parte de OIDC Relying Party (RP) para App ID, redirige al cliente a su página de inicio de sesión de App ID para la autenticación.
       * Si no especifica esta anotación, un cliente debe autenticarse con una señal portadora válida. Si la autenticación para un cliente falla, la solicitud del cliente se rechaza con un mensaje de error `401 Unauthorized`.
   
   

6. Vuelva a aplicar los recursos de Ingress para aplicar la autenticación de App ID. Después de volver a aplicar un recurso de Ingress con las anotaciones adecuadas, el complemento ALB OAuth Proxy implementa un despliegue OAuth2-Proxy, crea un servicio para el despliegue y crea un recurso de Ingress independiente para configurar el direccionamiento para los mensajes de despliegue de OAuth2-Proxy. No suprima estos recursos del complemento.

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

7. Verifique que la autenticación de App ID se aplica para sus apps.

   • Si sus apps dan soporte a la estrategia de app web: acceda al URL de la app en un navegador web. Si App ID se aplica correctamente, se le redirige a una página de inicio de sesión de autenticación de App ID.
   • Si las apps dan soporte a la estrategia de API: especifique la señal de acceso Bearer en la cabecera Authorization de solicitudes a las apps. Para obtener la señal de acceso, consulte la documentación de App ID. Si App ID se aplica correctamente, la solicitud se autentica correctamente y se direcciona a la app. Si envía solicitudes a las apps sin una señal de acceso en la cabecera Authorization, o si App ID no acepta la señal de acceso, la solicitud se rechaza.

8. Opcional: si usa políticas de red u otra solución de firewall en su clúster para limitar el tráfico saliente, debe asegurarse de permitir el acceso al servicio público AppID's desde su clúster. Para obtener el rango de direcciones IP para este servicio, envíe una solicitud a través del servicio de atención al cliente.

9. Opcional: puede personalizar el comportamiento predeterminado de OAuth2-Proxy creando un mapa de configuración de Kubernetes.

   1. Cree un archivo YAML del mapa de configuración que especifique valores para los valores de OAuth2-Proxy que desee cambiar.

       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. Aplique el recurso de mapa de configuración al complemento. Los cambios se aplican automáticamente.
   ```sh {: pre}
       kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
       ```
   

Para consultar la lista de cambios de cada versión del complemento ALB OAuth Proxy, véase el registro de cambios del complemento IBM Cloud ALB OAuth Proxy.

Conservación de la dirección IP de origen

De forma predeterminada, las direcciones IP de origen de las solicitudes de cliente no se conservan mediante el ALB de Ingress. Para conservar las direcciones IP de origen, puede habilitar el protocolo PROXY en clústeres de VPC o cambiar la externalTrafficPolicy en clústeres clásicos.

Configuración de protocolos SSL y cifrados SSL a nivel HTTP

Habilite los cifrados y protocolos SSL en el nivel de HTTP global editando el mapa de configuración ibm-k8s-controller-config.

Por ejemplo, si aún tiene clientes anteriores que necesitan soporte de TLS 1.0 o 1.1, debe habilitar manualmente las versiones de TLS para modificar el valor predeterminado solo de TLS 1.2 y TLS 1.3.

Cuando se especifican los protocolos habilitados para todos los hosts, los parámetros TLSv1.1 y TLSv1.2 (1.1.13, 1.0.12) solo funcionan cuando se utiliza OpenSSL 1.0.1 o superior. El parámetro TLSv1.3 (1.13.0) sólo funciona cuando se utiliza OpenSSL 1.1.1 creado con soporte de TLSv1.3.

Para editar el mapa de configuración para habilitar los cifrados y los protocolos SSL:

1. Edite el archivo de configuración del recurso del mapa de configuración ibm-k8s-controller-config.

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

2. Añada los cifrados y los protocolos SSL. Formatear los cifrados según el formato de la lista de cifrados de la biblioteca 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. Guarde el archivo de configuración.

4. Verifique que se hayan aplicado los cambios del mapa de configuración. Los cambios se aplican automáticamente a los ALB.

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

Envío de un certificado personalizado a clientes anteriores

Si tiene dispositivos ya existentes que no admiten la indicación de nombre de servidor (SNI) y utiliza un certificado TLS personalizado en sus recursos de Ingress, debe editar los valores del servidor de ALB para utilizar el certificado TLS personalizado y el secreto TLS personalizado.

Cuando se crea un clúster clásico, se genera un certificado de Let's Encrypt para el secreto de Ingress predeterminado que proporciona IBM. Si crea un secreto personalizado en el clúster y especifica este secreto personalizado para la terminación de TLS en los recursos de Ingress, el ALB de Ingress envía al cliente el certificado correspondiente al secreto personalizado en lugar del certificado de Let's Encrypt predeterminado. Sin embargo, si un cliente no da soporte a SNI, el ALB de Ingress toma de forma predeterminada el certificado de Let's Encrypt porque el secreto predeterminado aparece listado en los valores predeterminados del servidor de ALB. Para enviar el certificado personalizado a dispositivos que no admiten SNI, realice los pasos siguientes para cambiar los valores de servidor predeterminados de ALB a su secreto personalizado.

Los certificados de Let's Encrypt que se generan de forma predeterminada no están pensados para el uso de producción. Para cargas de trabajo de producción, traiga su propio certificado personalizado.

1. Edite el recurso de Ingress alb-default-server.

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

2. En la sección spec.tls, cambie el valor de hosts.secretName por el nombre del secreto personalizado que contiene el certificado personalizado. Ejemplo:

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

3. Guarde el archivo de recursos.

4. Verifique que ahora el recurso apunta a su nombre secreto personalizado. Los cambios se aplican automáticamente a los ALB.

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

Ajuste de la gestión de las conexiones

Los ajustes client-header-timeout, client-body-timeout, y keep-alive son configuraciones cruciales que dictan cuánto tiempo permanecen activas las conexiones entre los clientes, el controlador Ingress y los servidores backend. Estos tiempos de espera desempeñan un papel importante en la optimización de la gestión de las solicitudes, sobre todo cuando se trata de conexiones de clientes de larga duración, respuestas retrasadas de los servidores backend y la salvaguarda de recursos valiosos de ser ocupados innecesariamente.

La dirección client-header-timeout define el tiempo máximo que el servidor espera una cabecera de cliente completa. Del mismo modo, client-body-timeout indica el tiempo que el servidor espera a que el cliente envíe el cuerpo de la solicitud. Ambos tiempos de espera deben coincidir con el parámetro keep-alive, que regula el tiempo que el servidor mantiene abierta una conexión a la espera de nuevas peticiones. Si estos tiempos de espera no coinciden con la configuración keep-alive, NGINX terminará la conexión, lo que podría provocar un comportamiento inesperado del cliente o fallos en las peticiones.

Puedes configurar estos parámetros en el ConfigMapibm-k8s-controller-config dentro del espacio kube-system de nombres.

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"

Para más información, consulte la página client-header-timeout, client-body-timeout y keep-alive en la documentación de Ingress Nginx.

Ajuste del rendimiento de ALB

Para optimizar el rendimiento de los ALB de Ingress, puede cambiar los valores predeterminados de acuerdo con sus necesidades.