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

Para añadir un puerto de servidor a la solicitud de cliente antes de que la solicitud se reenvíe a la app de fondo, configure un proxy a servicios externos en una anotación de fragmento de código 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 aplicar la autenticación para sus apps cambiando campos de Ingress de Kubernetes específicos. Consulte Adición de la autenticación de App ID a las apps 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 Kubernetes Ingress resource de Kubernetes.

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 se envían los datos 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 realizar para errores de HTTP específicos, 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 la siguiente Kubernetes Ingress ibm-ingress-deploy-config ConfigMap campos.

Valor de campo de ejemplo.

httpPort=8080
httpsPort=8443

Personalización de la cabecera de solicitud

Para añadir información de cabecera a una solicitud de cliente antes de reenviar la solicitud a la app de fondo, utilice el siguiente campo Kubernetes ibm-k8s-controller-config

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

Para conocer los requisitos de custom-headers ConfigMap, consulte 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 ruta a servicios externos

Para añadir definiciones de vía de acceso a servicios externos, como por ejemplo servicios alojados en IBM Cloud, configure un proxy para servicios externos en un fragmento de código de ubicación. O bien, sustituya el proxy por una redirección permanente a servicios externos.

Redirección de solicitudes no seguras

De forma predeterminada, las solicitudes de cliente de HTTP no seguras se 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 granularidad de edad máxima y subdominio, consulte este blog de NGINX.
• Para desactivarlo, configure el campo ibm-k8s-controller-config configmap.

  hsts: false
  

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

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

keep-alive-requests: 100

El valor por defecto de keep-alive-requests en Kubernetes Ingress es 100, que es mucho menor que el valor por defecto de 4096 en IBM Cloud Kubernetes Service Ingress. 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 de estado activo permanece abierta entre el cliente y el servidor proxy ALB, utilice el siguiente ibm-k8s-controller-config configmap campode Kubernetes.

keep-alive: 60

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

Para establecer el número máximo y el tamaño de los almacenamientos intermedios que leen cabeceras de solicitud de cliente grandes, utilice el siguiente ibm-k8s-controller-config campo de mapa de configuración Kubernetes.

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 solicitud con la vía de acceso de la app, utilice la siguiente anotaciónde recurso de Ingress de 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ónde recurso de Ingress de Kubernetes.

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 anotacionesde recurso de Ingress de Kubernetes. 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 almacenamiento intermedio de proxy que lee la primera parte de la respuesta, utilice el siguiente Kubernetes recurso de Ingress anotación.

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

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

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

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, consulte 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 en sentido ascendente, utilice los siguientes campos de Ingress de Kubernetes.

• 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 cabecera que se incluye en la respuesta del cliente desde la aplicación final back-end antes de que la respuesta se envíe al cliente. Configure la eliminación de la cabecera de respuesta en un fragmento de código de ubicación, o utilice el campo proxy_hide_header como fragmento de código de configuración en ibm-k8s-controller-config ConfigMap.

Reescritura de vías de acceso

Para direccionar el tráfico de red de entrada en una vía de acceso de dominio ALB a una vía de acceso diferente en la que escucha la app de fondo, utilice la siguiente Kubernetes de Kubernetes .

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 personalizado, utilice la siguiente anotaciónde recurso de Ingress de Kubernetes.

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 direccionar siempre el tráfico de red de entrada al mismo servidor en sentido ascendente utilizando una cookie adhesiva, utilice las siguientes anotacionesde recurso de Ingress de Kubernetes.

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 que el soporte de servicios SSL cifre el tráfico a sus aplicaciones ascendentes que requieren HTTPS, utilice la anotación de protocolo de backend de recursos de entrada ( Kubernetes ) y las anotaciones de autenticación de certificados de 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 apps con puertos TCP no estándar

Para acceder a una app a través de un puerto TCP no estándar, siga 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 de tcp-services ConfigMap,, consulte 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. Especifique el tcp-services ConfigMap como un 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 solicitudes que se pueden servir a través de una conexión de estado activo, 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 de estado activo permanece abierta entre el servidor proxy ALB y el servidor en sentido ascendente de la app, utilice el siguiente ibm-k8s-controller-config campo de mapa de configuraciónde Kubernetes.

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.

     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

Refuerce la autenticación de sus 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 se autenticará, sino que se le emitirá un token de acceso para que pueda 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 establecer whitelist_domains en el archivo 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 de servicio, o puede incluir la opción --key para utilizar las credenciales de clave de servicio 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.

      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.

      ...
      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 más información sobre ID y tokens de acceso, consulte la documentación de App ID.

      • Para enviar sólo el ID Token, añada la siguiente anotación:

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

      • Para enviar sólo el Access Token, añada la siguiente información a la anotación configuration-snippet. (Esto amplía el fragmento de código del paso 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
            }
        ...
        

      • Para enviar el Access Token y el ID Token, añada la siguiente información a la anotación configuration-snippet. (Esto amplía el fragmento de código del paso 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. Opcional: si la aplicación admite la estrategia de aplicación web, además de la estrategia de API (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. Tenga en cuenta que todas las letras del nombre de la instancia de 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.

      kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
      

Para obtener la lista de cambios para cada versión del complemento ALB OAuth Proxy, consulte el registro de cambios del complemento ALB OAuth Proxy IBM Cloud.

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

Puede configurar los parámetros anteriores en el espacio de nombres ibm-k8s-controller-config ConfigMap en 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"

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.