Añadir un puerto de servidor a un encabezado de host

De forma predeterminada, Traefik gestiona el encabezado « Host » de manera que sea compatible con la mayoría de las aplicaciones modernas. No se recomienda modificar el encabezado « Host » para incluir un puerto. Antes de realizar cualquier cambio, revisa cómo gestiona Traefik el encabezado de forma predeterminada y comprueba en qué casos es adecuado sobrescribirlo.

Gestión predeterminada de los encabezados « Host »

Traefik reenvía por defecto el encabezado original « Host » con passHostHeader: true. Añade automáticamente los siguientes encabezados de reenvío independientes, en lugar de incluir el puerto en el encabezado « Host »:

• X-Forwarded-Host

• X-Forwarded-Port

Sobrescribir el encabezado « Host » para aplicaciones heredadas

Si tu aplicación necesita el puerto incluido en el encabezado « Host », utiliza el middleware de encabezados de Traefik para sobrescribirlo.

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

Aplica el middleware a tu recurso Ingress utilizando la anotación «Traefik Ingress». Asegúrate de que el procesamiento de CRD esté activado (es la configuración predeterminada). Para configurar el procesamiento de CRD, consulta la guía « ibm-ingress-deploy-config ConfigMap processTraefikCRDs campo ».

Enrutamiento de las solicitudes entrantes mediante un ALB privado

De forma predeterminada, los ALB públicos procesan recursos de Ingress. Para redirigir las solicitudes entrantes a través de un ALB privado, especifica la clase « private-iks-traefik » en el campo « spec.ingressClassName » de tu recurso Ingress.

spec.ingressClassName: "private-iks-traefik"

Autenticación de aplicaciones con App ID

Configura Traefik Ingress con IBM Cloud App ID para aplicar la autenticación en tus aplicaciones. Para obtener más información, consulta « Cómo añadir la autenticación de App ID a las aplicaciones ».

Configuración del tamaño máximo del cuerpo de la solicitud del cliente

Por defecto, Traefik no impone ningún límite al tamaño del cuerpo de las solicitudes de los clientes. Para establecer un límite máximo, crea un «Buffering Middleware» y aplícalo a tu recurso «Ingress».

Traefik rechaza cualquier solicitud que supere el límite configurado con una respuesta 413 « HTTP ».

1. Crea un recurso de middleware de almacenamiento en búfer de Traefik. Establece « maxRequestBodyBytes » en el número máximo de bytes que el cliente puede enviar. En el siguiente ejemplo se establece un límite de 2 MB (2 097 152 bytes).

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

2. Aplica el middleware a tu recurso Ingress utilizando la anotación «Traefik Ingress».

Habilitación del almacenamiento en búfer de los datos de respuesta de los clientes

Por defecto, Traefik transmite las respuestas directamente sin almacenamiento en búfer. Gracias al middleware de almacenamiento en búfer, Traefik puede almacenar las respuestas en memoria o guardarlas en disco antes de enviarlas al cliente. Utiliza este middleware solo cuando tu aplicación lo requiera, ya que, en la mayoría de los casos, no se recomienda el almacenamiento en búfer de las respuestas.

Para habilitar el almacenamiento en búfer de respuestas, sigue estos pasos:

1. Crea un recurso de middleware de almacenamiento en búfer de Traefik. Establece « maxResponseBodyBytes » en el tamaño máximo de la respuesta en bytes y « memResponseBodyBytes » en el umbral a partir del cual la respuesta se guarda en el disco en lugar de mantenerse en memoria. En el siguiente ejemplo se almacenan en búfer hasta 5 MB en total, de los cuales el primer 1 MB se mantiene en memoria.

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

2. Aplica el middleware a tu recurso Ingress utilizando la anotación «Traefik Ingress».

Ajustar los tiempos de espera

Traefik ofrece dos tipos de controles de tiempo de espera: los tiempos de espera entre el cliente y el ALB, y los tiempos de espera entre el ALB y tu aplicación de back-end. Configúralos por separado en función de dónde se encuentre el cuello de botella.

Para configurar los tiempos de espera entre el cliente y el ALB, configura los campos correspondientes de « ibm-ingress-deploy-config » ( ConfigMap ):

• Para configurar el tiempo que una solicitud entrante a HTTP o HTTPS debe esperar a que la instancia de Traefik responda, utiliza los campos « httpReadTimeout » y « httpsReadTimeout ».
• Para configurar el tiempo máximo que puede transcurrir antes de que se agote el tiempo de espera de la respuesta, utiliza los campos « httpWriteTimeout » y « httpsWriteTimeout ».
• Para configurar el tiempo máximo durante el cual una conexión «keepalive» permanece abierta antes de cerrarse, utiliza los campos « httpIdleTimeout » y « httpsIdleTimeout ».

Para configurar el tiempo de espera de conexión y de lectura entre el ALB y tu aplicación back-end, utiliza ServersTransport para configurar el transporte entre Traefik y tus servidores HTTP.

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

En el caso de los clústeres de VPC, también debes modificar el tiempo de espera de conexión inactiva en el servicio de equilibrador de carga que expone tu ALB público. Sustituye CLUSTER_ID por el ID de tu clúster, que puedes obtener ejecutando ibmcloud ks cluster get --cluster CLUSTER_NAME_OR_ID. En el siguiente ejemplo se establece el tiempo de espera en 910 segundos:

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

Traefik admite el valor « 0 » para sus tiempos de espera, lo que desactiva el tiempo de espera.

La anotación « ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout » del equilibrador de carga de VPC no admite el valor cero. Puedes establecer un valor de tiempo de espera comprendido entre 50 segundos y 7200 segundos (2 horas). Si necesitas un plazo superior a 2 horas, abre un ticket de asistencia y explica los motivos operativos.

Si tus clústeres están expuestos a través de IBM Cloud Internet Services (CIS) o Cloudflare con el cortafuegos de aplicaciones web (WAF) o el equilibrio de carga global activados, configura estos tiempos de espera en más de 900 segundos. Para obtener más información, consulta la documentación de Cloudflare.

Una vez creado el recurso « ServersTransport », aplícalo a tu recurso «Service» utilizando la anotación «Traefik Service».

Personalización de las acciones ante errores

Para indicar las acciones personalizadas que el ALB puede llevar a cabo ante errores específicos de HTTP, configura el middleware de errores de Traefik. Una vez creado el middleware, aplícalo a tu recurso Ingress utilizando la anotación «Traefik Ingress».

Cambiar los puertos predeterminados de HTTP y HTTPS

De forma predeterminada, los ALB escuchan en el puerto 80 para HTTP y en el puerto 443 para HTTPS. Si tu clúster requiere puertos no estándar, puedes modificar estos valores para cada ALB utilizando los campos « httpPort » y « httpsPort » en la página « ibm-ingress-deploy-config » ConfigMap.

Personalización del encabezado de la solicitud

Utiliza el middleware de encabezados de Traefik para añadir, sobrescribir o eliminar campos de encabezado de una solicitud del cliente antes de reenviarla a tu aplicación de back-end. Esto resulta útil para introducir información contextual, como nombres de scripts, identificadores de inquilinos u otros metadatos que necesite tu aplicación.

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

Una vez creado el middleware, aplícalo a tu recurso Ingress utilizando la anotación «Traefik Ingress».

Personalización del encabezado de respuesta

Utiliza el middleware de encabezados de Traefik para añadir, sobrescribir o eliminar campos de encabezado de una respuesta antes de enviarla al cliente. Esto resulta útil para aplicar políticas de seguridad, añadir encabezados de « CORS » o eliminar los encabezados internos antes de que lleguen al cliente.

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

Una vez creado el middleware, aplícalo a tu recurso Ingress utilizando la anotación «Traefik Ingress».

Redirección de solicitudes no seguras

Para garantizar que el acceso se realice únicamente a través de HTTPS y redirigir de forma permanente todas las solicitudes entrantes a HTTP al punto final HTTPS, configura el campo httpsRedirect en el ibm-ingress-deploy-config ConfigMap.

Activar y desactivar la seguridad estricta de transporte ( HTTP )

HTTP La función «Strict Transport Security» ( HSTS ) indica a los navegadores que accedan a un dominio únicamente a través de HTTPS, lo que evita los ataques de degradación de protocolo. Esta función es opcional en Traefik. Actívalo utilizando el middleware «Headers» con los campos « stsSeconds », « stsIncludeSubdomains » y « stsPreload ».

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

Aplica el middleware a tu recurso Ingress utilizando la siguiente anotación de Traefik Ingress.

Modificación de la forma en que el ALB hace coincidir el URI de la solicitud

Por defecto, Traefik utiliza el comparador « PathPrefix » para enrutar las solicitudes. Si tu aplicación requiere una coincidencia exacta de rutas o un enrutamiento basado en expresiones regulares, sobrescribe el comparador utilizando la siguiente anotación de Traefik Ingress.

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

Configuración de la autenticación mutua

El protocolo de autenticación recíproca ( TLS ) ( mTLS ) exige que tanto el servidor como el cliente presenten certificados válidos, lo que proporciona una autenticación más segura que el protocolo estándar ( TLS ). Para exigir la autenticación mediante certificado de cliente en tu ALB, crea un recurso TLSOption que haga referencia al secreto de tu certificado de CA.

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

Una vez creado el recurso « TLSOption », aplícalo a tu recurso Ingress utilizando la anotación «Traefik Ingress».

Configuración del comportamiento de reintentos para las solicitudes de origen

Cuando un servidor back-end no responde, Traefik puede volver a enviar automáticamente la solicitud a otro servidor upstream. Configura el comportamiento de los reintentos utilizando el middleware de reintentos de Traefik. Una vez creado el middleware, aplícalo a tu recurso Ingress utilizando la anotación «Traefik Ingress».

Limitación de velocidad

La limitación de velocidad protege tus aplicaciones de back-end frente a picos de tráfico y usos indebidos, al limitar el número de solicitudes que procesa el ALB en un intervalo de tiempo determinado. Configura la limitación de velocidad utilizando el middleware « RateLimit » de Traefik. Una vez creado el middleware, aplícalo a tu recurso Ingress utilizando la anotación «Traefik Ingress».

Reescritura de rutas

La reescritura de rutas te permite exponer una ruta pública URL que difiere de la ruta en la que escucha tu aplicación de back-end. Por ejemplo, puedes redirigir las solicitudes que llegan a /app a una aplicación de back-end que escucha en /. Utiliza uno de los siguientes recursos de Traefik, dependiendo de si necesitas una sustitución fija o una sustitución basada en patrones:

• El recurso sobre el middleware « ReplacePath » de Traefik
• El recurso sobre el middleware « ReplacePathRegex » de Traefik

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

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

Aplica el middleware a tu recurso Ingress utilizando la siguiente anotación de Traefik Ingress.

Enrutamiento del tráfico con cookies «sticky»

Las sesiones persistentes garantizan que las solicitudes de un cliente se dirijan siempre al mismo servidor de fondo mientras dure la sesión. Esto resulta útil para aplicaciones con estado que almacenan datos de sesión de forma local en el servidor. Activa las sesiones persistentes configurando la anotación de cookie persistente del servicio Traefik en tu recurso Ingress.

Cifrado del tráfico entre tu aplicación y el ALB

Por defecto, Traefik reenvía el tráfico a tu aplicación de back-end a través de HTTP sin cifrar. Si tu aplicación requiere conexiones ascendentes cifradas, utiliza un ServersTransport recurso para configurar TLS entre el ALB y tu aplicación, incluyendo el certificado de la CA y el nombre de servidor esperado.

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

Aplica la anotación « ServersTransport » a tu recurso de servicio utilizando la siguiente anotación de servicio de Traefik.

Personalización del despliegue de ALB

El archivo « ibm-ingress-deploy-config » ( ConfigMap ) controla los parámetros a nivel de ALB, como el número de réplicas, los puertos, el nivel de registro, los valores de tiempo de espera y el proveedor de Ingress. Utiliza este « ConfigMap » para aplicar cambios de configuración a uno o varios ALB de tu clúster sin modificar los recursos de Ingress individuales.

1. Obtenga los nombres de los servicios que exponen cada ALB. Anota los nombres de los servicios, ya que los necesitarás en los siguientes pasos.

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

2. Cree un archivo YAML para un mapa de configuración ibm-ingress-deploy-config. Para cada ID de ALB, puede especificar uno o varios de los siguientes valores opcionales. Solo tienes que incluir los ajustes que quieras configurar.

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

   replicas

   Por defecto, cada ALB tiene dos réplicas. Para mejorar las prestaciones de proceso de ALB, aumente el número de pods de ALB. Para obtener más información, consulte Aumento del número de réplicas de pod de ALB.

   ingressClass

   Si has especificado una clase distinta de « public-iks-traefik » o « private-iks-traefik » en tu recurso de Ingress, introduce aquí el nombre de la clase.

   httpPort, httpsPort

   Exponga los puertos no predeterminados para el ALB de Ingress añadiendo los puertos HTTP o HTTPS que desea abrir.

   Valores predeterminados: 80/443.

   logLevel

   Especifica el nivel de registro. Elige entre: TRACE, DEBUG, INFO, WARN, ERROR, FATAL, PANIC.

   Valor predeterminado: INFO.

   ingressProvider

   Especifica qué proveedor de Traefik Ingress se va a utilizar para este ALB. Valores válidos:

   ingress: Utiliza el controlador de entrada propio de Traefik. Procesa las anotaciones específicas de Traefik en los recursos de Ingress.

   ingress-nginx: Utiliza un archivo temporal Capa de compatibilidad para Ingress(NGINX)en Traefik. Procesa las anotaciones creadas para Ingress ( NGINX ) e imita el comportamiento de Ingress ( NGINX ) siempre que sea posible. Utiliza este valor para facilitar la migración de Ingress ( NGINX ) a Traefik.

   Valor predeterminado: ingress.

   processTraefikCRDs

   Cuando se configura en « true », Traefik procesa sus propios recursos CRD además de los recursos de Ingress. Los CRD compatibles son IngressRoute, Middleware y TLSOption. Para consultar la lista completa, véase la documentación de Traefik sobre los CRD. Por : defecto: true.

   traefikIngressNginxAllowExternalNameServices

   Habilita la compatibilidad con los servicios de ExternalName para los objetos de Ingress que procesa el proveedor ingress-nginx. Esta opción solo se aplica cuando la opción « ingressProvider » está configurada en « ingress-nginx ». Por : defecto: true.

   traefikCRDAllowCrossNamespace

   Permite que los recursos de « IngressRoute » (CRD de Traefik) hagan referencia a recursos de otros espacios de nombres. Por : defecto: false.

   traefikCRDAllowExternalNameServices

   Permite que los recursos de IngressRoute (CRD de Traefik) hagan referencia a los servicios de ExternalName. Por : defecto: false.

   httpReadTimeout, httpsReadTimeout

   Configura el tiempo de espera de lectura de HTTP / HTTPS entre el ALB y el cliente. El valor debe ser un número entero de segundos; si se establece en cero, se desactiva el tiempo de espera.

   Para obtener más información, consulta la documentación de Traefik.

   httpWriteTimeout, httpsWriteTimeout

   Configura el tiempo de espera de escritura de HTTP / HTTPS entre el ALB y el cliente. El valor debe ser un número entero de segundos; si se establece en cero, se desactiva el tiempo de espera.

   Para obtener más información, consulta la documentación de Traefik.

   httpIdleTimeout, httpsIdleTimeout

   Configura el tiempo de espera de inactividad (keepalive) de HTTP / HTTPS entre el ALB y el cliente. El valor debe ser un número entero de segundos; si se establece en cero, se desactiva el tiempo de espera.

   Para obtener más información, consulta la documentación de Traefik.

   Si utilizas IBM Cloud Internet Services (CIS) o Cloudflare con el cortafuegos de aplicaciones web (WAF) o el equilibrio de carga global, configura este valor en más de 900 segundos. Para obtener más información, consulta « Ajustar los tiempos de espera ».

   httpsRedirect

   Activa una redirección permanente de todas las solicitudes entrantes a HTTP hacia el punto final HTTPS. Por : defecto: false.

   customEntryPoints

   Especifica puntos de entrada personalizados adicionales para Traefik. El nombre del punto de entrada será la clave del objeto. Los siguientes nombres de puntos de entrada están reservados y no se pueden utilizar: web, websecure, traefik, hc, y http https.

   En caso de que la configuración del punto de entrada sea incorrecta, ¡no se procesará ninguno de los puntos de entrada personalizados!

   customEntryPoints.<name>.port

   Puerto del punto de entrada que se debe utilizar. Este campo es obligatorio. Asegúrate de que no entre en conflicto con otros puertos.

   El puerto y el protocolo definidos aquí deben configurarse manualmente en el equilibrador de carga; consulta las instrucciones a continuación.

   customEntryPoints.<name>.protocol

   Protocolo del punto de entrada que se debe utilizar. Este campo es obligatorio. Los valores válidos son TCP y UDP.

   customEntryPoints.<name>.readTimeout

   Configura el tiempo de espera de lectura del punto de entrada, entre el ALB y el cliente. El valor debe ser un número entero de segundos; si se establece en cero, se desactiva el tiempo de espera.

   Para obtener más información, consulta la documentación de Traefik.

   customEntryPoints.<name>.writeTimeout

   Configura el tiempo de espera de escritura del punto de entrada entre el ALB y el cliente. El valor debe ser un número entero de segundos; si se establece en cero, se desactiva el tiempo de espera.

   Para obtener más información, consulta la documentación de Traefik.

   customEntryPoints.<name>.idleTimeout

   Configura el tiempo de espera de inactividad (keepalive) del punto de entrada entre el ALB y el cliente. El valor debe ser un número entero de segundos; si se establece en cero, se desactiva el tiempo de espera.

   Para obtener más información, consulta la documentación de Traefik.

   customEntryPoints.<name>.udpTimeout

   Configura el tiempo de espera de inactividad del punto de entrada para el listener UDP. Este campo solo se tiene en cuenta para los puntos finales que utilizan el protocolo UDP. El valor debe ser un número entero de segundos y mayor que cero.

   Para obtener más información, consulta la documentación de Traefik.

   tolerations

   Especifica tolerancias personalizadas adicionales para los pods de ALB. Para obtener más información, consulta Taints y tolerancias.

3. Cree el mapa de configuración ibm-ingress-deploy-config en el clúster.

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

4. Actualiza tus ALB para aplicar los cambios. Los cambios pueden tardar hasta cinco minutos en surtir efecto. Si el comando finaliza sin mostrar ningún resultado, significa que la actualización se ha enviado correctamente.

   ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID
   

5. Si ha especificado puertos no estándar HTTP, HTTPS o ha creado puntos de entrada adicionales, debe abrir los puertos en cada servicio ALB.

   1. Para cada servicio ALB que haya encontrado en el paso 1, edite el archivo YAML.

       kubectl edit svc -n kube-system <alb_svc_name>
       ```
   2. En la sección `spec.ports`, añada los puertos que desee abrir. De forma predeterminada, los puertos 80 y 443 están abiertos. Si desea mantener abiertos 80 y 443, no los elimine de este archivo. Los puertos que no se especifiquen, permanecerán cerrados. No especifique un `nodePort`. Después de añadir el puerto y aplicar los cambios, se asigna automáticamente un `nodePort`.
   
   ```sh {: codeblock}
       ...
       ports:
       - name: port-80
         port: 80
         protocol: TCP
         targetPort: 80
       - name: port-443
         port: 443
         protocol: TCP
         targetPort: 443
       - name: <new_port>
         port: <port>
         protocol: TCP
         targetPort: <port>
       ...
       ```
   3. Guarde y cierre el archivo. Los cambios se aplican automáticamente.
   
   

Personalización de la clase de Ingress

Una clase de Ingress asocia un nombre de clase a un tipo de controlador de Ingress, lo que permite que coexistan varios controladores en el mismo clúster. Utiliza el IngressClass recurso para definir una clase personalizada para tus ALB.

Traefik solo procesa las clases de Ingress en las que « .spec.controller » esté establecido en « traefik.io/ingress-controller ».

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

Protege tus aplicaciones contra el acceso no autenticado integrando IBM Cloud App ID con tu Ingress ALB. Cuando se configura la autenticación, el ALB reenvía las solicitudes a través de un servidor de autenticación ( OAuth2-Proxy ) que valida las credenciales con App ID antes de pasar el tráfico a tu aplicación.

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úrate de que el nombre de la instancia del servicio contenga únicamente caracteres alfanuméricos en minúsculas y que 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 del servicio debe contener únicamente caracteres alfanuméricos en minúsculas y no puede superar los 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, no se te autenticará, pero se te 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. Todas las letras del nombre de la instancia del servicio deben estar en minúsculas.

   Si utiliza la función de cierre de sesión IBM Cloud App ID, agregue /sign_out a su dominio en el formato https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out e incluya esta URL en la lista de URL de redireccionamiento. Para utilizar una página de cierre de sesión personalizada, configura « whitelist_domains » en OAuth2-Proxy ConfigMap. Llama al punto final https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out con el parámetro de consulta rd o configura el encabezado X-Auth-Request-Redirect con tu página de cierre de sesión personalizada URL. Para obtener más información, consulta « 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, o bien puede incluir la opción --key para utilizar las credenciales de la clave de servicio ya existentes. Asigna la instancia del servicio al mismo espacio de nombres en el que se encuentran tus recursos de Ingress. Todas las letras del nombre de la instancia del servicio deben estar 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 vincula correctamente a su clúster, se crea un secreto de clúster que contiene las credenciales de su instancia de servicio. El ejemplo siguiente muestra la salida:

   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: una implementación de OAuth2-Proxy para tu instancia del servicio App ID, un secreto que contiene la configuración de OAuth2-Proxy y un recurso Ingress que redirige las solicitudes entrantes a la implementación de OAuth2-Proxy. El nombre de cada recurso comienza 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`. Espera unos minutos y vuelve a ejecutar el comando si el estado indica « `Enabling` ».
   ```sh {: pre}
       ibmcloud ks cluster addon ls --cluster CLUSTER_NAME_OR_ID
       ```
   

5. En los recursos de Ingress para las aplicaciones en las que desees añadir la autenticación « App ID », asegúrate de que el nombre del recurso no supere los 25 caracteres. A continuación, configura el middleware « ForwardAuth »:

   1. Crea un recurso de middleware « ForwardAuth » de Traefik. El especifica address el URL del OAuth2-Proxy para tu instancia de App ID, que actúa como parte de confianza (RP) de OIDC. Todas las letras del nombre de la instancia del servicio deben estar en minúsculas.

       apiVersion: traefik.io/v1alpha1
       kind: Middleware
       metadata:
         name: oauth-verify
         namespace: default
       spec:
         forwardAuth:
           address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
           tls:
             insecureSkipVerify: true
       ```
       De forma predeterminada, Traefik valida los nombres alternativos de sujeto (SAN) de IP del tipo TLS. IBM-Es probable que los certificados proporcionados no superen esta validación, por lo que se recomienda utilizar la opción « `insecureSkipVerify: true` ». Esta configuración garantiza que la instancia de Traefik, o el ALB, pueda comunicarse con las instancias de implementación de `oauth2-proxy`.
       {: note}
   
   2. 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)
       * Para enviar únicamente el « `ID Token` », añade la opción « `authResponseHeaders` » a tu middleware « ForwardAuth »:
   
           ```yaml {: codeblock}
           apiVersion: traefik.io/v1alpha1
           kind: Middleware
           metadata:
             name: oauth-verify
             namespace: default
           spec:
             forwardAuth:
               address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
               authResponseHeaders:
                 - Authorization
               tls:
                 insecureSkipVerify: true
           ```
       * Para enviar únicamente el « `Access Token` », añade la opción « `authResponseHeaders` » a tu middleware « ForwardAuth »:
   
           ```yaml {: codeblock}
           apiVersion: traefik.io/v1alpha1
           kind: Middleware
           metadata:
             name: oauth-verify
             namespace: default
           spec:
             forwardAuth:
               address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
               authResponseHeaders:
                 - X-Auth-Request-Access-Token
               tls:
                 insecureSkipVerify: true
           ```
       * Para enviar tanto el archivo « `Access Token` » como el « `ID Token` », añade la opción « `authResponseHeaders` » a tu middleware « ForwardAuth »:
   
           ```yaml {: codeblock}
           apiVersion: traefik.io/v1alpha1
           kind: Middleware
           metadata:
             name: oauth-verify
             namespace: default
           spec:
             forwardAuth:
               address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
               authResponseHeaders:
                 - X-Auth-Request-Access-Token
                 - Authorization
               tls:
                 insecureSkipVerify: true
           ```
   3. Opcional: Si tu aplicación es compatible con 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 lugar de ella, añade el controlador « `authSigninURL` » a tu middleware « ForwardAuth ». Todas las letras del nombre de la instancia del servicio deben estar en minúsculas.
   
   ```yaml {: codeblock}
       apiVersion: traefik.io/v1alpha1
       kind: Middleware
       metadata:
         name: oauth-verify
         namespace: default
       spec:
         forwardAuth:
           address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
           authResponseHeaders:
             - X-Auth-Request-Access-Token
             - Authorization
           authSigninURL: /oauth2-<App_ID_service_instance_name>/sign_in?rd={url}
           tls:
             insecureSkipVerify: true
       ```
       * Si se especifica `authSigninURL` y falla la autenticación del cliente, este es redirigido a OAuth2-Proxy, que a su vez lo redirige a la página de inicio de sesión App ID.
       * Si no se especifica `authSigninURL`, el cliente debe autenticarse con un token de portador válido. Si falla la autenticación, la solicitud se rechaza con un error de « `401 Unauthorized` ».
   
   

6. Opcional: si tu configuración lo requiere, crea un recurso Traefik ServersTransport para omitir la verificació TLS e de las solicitudes reenviadas al recurso «Service» de tu aplicación.

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

   Aplica la anotación « ServersTransport » a tu recurso de servicio utilizando la anotación «Traefik Service».

7. Edita tus recursos de Ingress para forzar la autenticación de App ID aplicando el middleware ForwardAuth que has creado. Utiliza la siguiente anotación de Traefik Ingress.

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

   Una vez que se vuelve a aplicar un recurso Ingress con las anotaciones adecuadas, el complemento ALB OAuth Proxy implementa una implementación oauth2-proxy, crea un servicio para dicha implementación y crea un recurso Ingress independiente para configurar el enrutamiento de la implementación oauth2-proxy. No suprima estos recursos del complemento.

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

   • Si tu aplicación es compatible con la estrategia de aplicaciones web: accede a URL desde 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 tu aplicación es compatible con la estrategia de API: especifica tu token de acceso Bearer en el encabezado Authorization de las solicitudes enviadas a las aplicaciones. 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ías solicitudes a tus aplicaciones sin un token de acceso en el encabezado Authorization, o si App ID no acepta el token de acceso, la solicitud será rechazada.

9. Opcional: Si utilizas políticas de red u otra solución de cortafuegos en tu clúster para limitar el tráfico saliente, asegúrate de que tu clúster pueda acceder al servicio público App ID. Para obtener el rango de direcciones IP de este servicio, envía una solicitud al servicio de atención al cliente.

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

Actualización del complemento ALB OAuth Proxy

Para actualizar el complemento «ALB OAuth Proxy» a una versión más reciente, desactiva la instalación actual y vuelve a activarla con la versión que desees. Las instancias de « oauth2-proxy » que ya tienes no se verán interrumpidas durante la actualización.

El proceso de actualización no provoca interrupciones, ya que las instancias oauth2-proxy supervisadas permanecen en el clúster incluso cuando el complemento está desactivado.

1. Inhabilite el complemento.

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

2. Enumera las versiones de complementos disponibles e indica la versión que deseas utilizar. El resultado muestra las versiones disponibles y cuál es la versión predeterminada.

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

3. Habilite el complemento y especifique la opción --version. Si no especifica una versión, se habilita la versión predeterminada.

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

Conservación de la dirección IP de origen

De forma predeterminada, el ALB de Ingress no conserva la dirección IP de origen original de las solicitudes de los clientes. Esto puede impedir que el control de acceso basado en direcciones IP, el registro de actividades y las políticas de seguridad funcionen correctamente. Elige el método que corresponda a tu tipo de clúster para habilitar la conservación de la IP de origen.

Configuración de los protocolos y algoritmos de cifrado de « TLS »

Utiliza un recurso TLSOption para exigir versiones mínimas de TLS, restringir los conjuntos de cifrado y configurar otros parámetros de conexión de TLS para el tráfico que llega a tu ALB. Una vez creado el recurso « TLSOption », aplícalo a tu recurso Ingress utilizando la anotación «Traefik Ingress».

Envío de un certificado personalizado a clientes anteriores

Los dispositivos antiguos que no admiten la indicación del nombre del servidor (SNI) no pueden negociar qué certificado de TLS deben utilizar, por lo que reciben el certificado predeterminado de Let's Encrypt del ALB en lugar de tu certificado personalizado. Para garantizar que estos dispositivos reciban tu certificado personalizado, actualiza la configuración predeterminada del servidor ALB para que apunte a tu secreto personalizado de « TLS ».

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.

Al crear un clúster clásico, IBM proporciona un certificado de Let's Encrypt para el secreto de Ingress predeterminado. Si creas un secreto personalizado y lo especificas para la terminación de TLS en tus recursos de Ingress, el ALB envía tu certificado personalizado a los clientes en lugar del certificado de Let's Encrypt. Sin embargo, si un cliente no es compatible con SNI, el ALB utiliza por defecto el certificado de Let's Encrypt, ya que el secreto predeterminado figura en la configuración predeterminada del servidor del ALB. Para enviar tu certificado personalizado a dispositivos que no sean SNI, sigue estos pasos.

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.

   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. En la salida, comprueba que « spec.tls[].secretName » coincida con el nombre de tu secreto personalizado.

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

Ajuste del rendimiento de ALB

Los nodos de trabajo se aprovisionan automáticamente con una configuración optimizada del núcleo que se adapta a la mayoría de las cargas de trabajo. Si tu clúster tiene requisitos específicos de alto rendimiento o baja latencia, puedes ajustar los parámetros del núcleo « Linux » sysctl en los nodos de trabajo para optimizar aún más el rendimiento de ALB. Modifica estos ajustes solo cuando tengas una necesidad clara de optimizar el rendimiento, ya que unos valores incorrectos pueden desestabilizar el nodo.

Próximos pasos

• Gestiona tus ALB de Ingress para escalar, actualizar o desactivar los ALB de tu clúster.
• Configura Ingress para dar visibilidad a tus aplicaciones mediante el servicio gestionado de Ingress.
• Depuración de Ingress para diagnosticar y resolver los problemas más habituales de Ingress.

Enlaces relacionados

• Documentación de Traefik
• Referencia de Traefik Middleware
• Referencia de CRD de Traefik
• Documentación de IBM Cloud App ID