Ingress Controller de Citrix ADC

Usar directivas de reescritura y respuesta en Kubernetes

En un entorno de Kubernetes, implementar directivas de capa 7 específicas para gestionar casos como:

  • Redirigir el tráfico HTTP a una URL específica
  • Bloquear un conjunto de direcciones IP para mitigar los ataques DDoS
  • Imponer HTTP a HTTPS

Requiere que agregue las bibliotecas apropiadas dentro de los microservicios y que configure las directivas manualmente. En su lugar, puede usar las funciones de reescritura y respuesta proporcionadas por el dispositivo Citrix ADC de entrada para implementar estas directivas.

Citrix proporciona CustomResourceDefinitions (CRD) de Kubernetes que puede usar con el Citrix Ingress Controller para automatizar las configuraciones y la implementación de estas directivas en los ADC de Citrix que se utilizan como dispositivos de entrada.

La CRD de reescritura y respuesta proporcionada por Citrix está diseñada para exponer un conjunto de herramientas utilizadas en los ADC de Citrix de primera línea. Con estas funcionalidades, puede reescribir el encabezado y la carga útil del tráfico HTTP de entrada y salida, así como responder al tráfico HTTP en nombre de un microservicio.

Una vez que implementas la CRD de reescritura y respuesta en el clúster de Kubernetes. Puede definir directivas extensas de reescritura y respuesta mediante conjuntos de datos, conjuntos de rutas y mapas de cadenas, y también habilitar registros de auditoría para las estadísticas en el dispositivo de entrada. Para obtener más información sobre la función de directiva de reescritura y respuesta proporcionada por Citrix ADC, consulte Directiva de reescritura y Directiva de respuesta.

Nota:

La CRD de reescritura y respuesta no es compatible con las rutas de OpenShift. Puede usar la entrada de OpenShift para usar la CRD de reescritura y respuesta.

Implementar la CRD de reescritura y respuesta de Citrix

El archivo YAML de implementación de Citrix Rewrite and Responder CRD: rewrite-responder-policies-deployment.yaml.

Nota:

Asegúrese de no modificar el archivo YAML de implementación.

Implemente el CRD mediante el siguiente comando:

kubectl create -f rewrite-responder-policies-deployment.yaml

Por ejemplo:

root@master:~# kubectl create -f rewrite-responder-policies-deployment.yaml
customresourcedefinition.apiextensions.k8s.io/rewritepolicies.citrix.com created

Atributos de CRD de reescritura y respuesta

La CRD proporciona atributos para las diversas opciones necesarias para definir las directivas de reescritura y respuesta. Además, proporciona atributos para el conjunto de datos, el conjunto de rutas, el mapa de cadenas y los registros de auditoría para usarlos en las directivas de reescritura y respuesta. Estos atributos de CRD corresponden al comando y al atributo de Citrix ADC, respectivamente.

Directiva de reescritura

En la siguiente tabla se enumeran los atributos de CRD que se pueden utilizar para definir una directiva de reescritura. Además, en la tabla se enumeran los comandos y atributos correspondientes de Citrix ADC.

Atributo de CRD Comando de Citrix ADC Atributo de Citrix ADC
rewrite-criteria Add rewrite policy rule
default-action Add rewrite policy undefAction
operation Add rewrite action type
target Add rewrite action target
modify-expression Add rewrite action stringBuilderExpr
multiple-occurence-modify Add rewrite action Search
additional-multiple-occurence-modify Add rewrite action RefineSearch
Direction Bind lb vserver Tipo

Responder policy

En la siguiente tabla se enumeran los atributos de CRD que puede usar para definir una directiva de respuesta. Además, en la tabla se enumeran los comandos y atributos correspondientes de Citrix ADC.

Atributo de CRD Comando de Citrix ADC Atributo de Citrix ADC
Redirect Add responder action Tipo (el valor del tipo)
url Add responder action Target
redirect-status-code Add responder action responseStatusCode
redirect-reason Add responder action reasonPhrase
Respond-with Add responder action Tipo (el valor del tipo)
http-payload-string Add responder action Target
Noop Add responder policy Acción (el valor de la acción)
Reset Add responder policy Acción (el valor de la acción)
Drop Add responder policy Acción (el valor de la acción)
Respond-criteria Add responder policy Rule
Default-action Add responder policy undefAction

Audit log

En la siguiente tabla se enumeran los atributos de CRD que se proporcionan para habilitar el registro de auditoría en las directivas de reescritura o respuesta. Además, en la tabla se enumeran los comandos y atributos correspondientes de Citrix ADC.

Atributo de CRD Comando de Citrix ADC Atributo de Citrix ADC
Logexpression Add audit message action stringBuilderExpr
Loglevel Add audit message action Loglevel

Dataset

En la siguiente tabla se enumeran los atributos de CRD para el conjunto de datos que puede usar en las directivas de reescritura o respuesta. Además, en la tabla se enumeran los comandos y atributos correspondientes de Citrix ADC.

Atributo de CRD Comando de Citrix ADC Atributo de Citrix ADC
Nombre Add policy dataset Nombre
Tipo Add policy dataset Tipo
Valores Bind policy dataset Valor

Patset

Atributo de CRD Comando de Citrix ADC Atributo de Citrix ADC
Nombre Add policy patset Nombre
Valores Bind policy patset string

String map

Atributo de CRD Comando de Citrix ADC Atributo de Citrix ADC
Nombre Add policy stringmap Nombre
Clave Bind policy stringmap Clave
Valor Bind policy stringmap Valor

Goto-priority-expression

En la siguiente tabla se proporciona información sobre el atributo goto-priority-expression, que es un atributo CRD para vincular un grupo de varias directivas consecutivas a los servicios.

Atributo de CRD Comando de Citrix ADC Atributo de Citrix ADC Valores admitidos Valor predeterminado
goto-priorty-expression Bind lb vserver gotoPriorityExpression NEXT y END End

Para obtener más información sobre cómo utilizar el atributo goto-priority-expression, consulte el ejemplo Modificar cadenas y el nombre de host en la URL solicitada.

Cómo escribir una configuración de directivas

Después de implementar la CRD proporcionada por Citrix en el clúster de Kubernetes, puede definir la configuración de la directiva en un.yaml archivo. En el archivo .yaml, use rewritepolicy en el campo kind y, según sus requisitos, agregue cualquiera de las siguientes secciones individuales spec para la configuración de la directiva.

  • rewrite-policy - Definir la configuración de directivas de reescritura.
  • responder-policy - Para definir la configuración de la directiva de respuesta.
  • logpackets - Para habilitar los registros de auditoría.
  • dataset - Utilizar un conjunto de datos para una amplia configuración de directivas.
  • patset - Utilizar un conjunto de palmaditas para una amplia configuración de directivas.
  • stringmaps - Utilizar mapas de cadenas para una amplia configuración de directivas.

En estas secciones, debe utilizar los atributos de CRD proporcionados para la configuración de directiva respectiva (reescritura o respuesta) para definir la directiva.

Además, en la sección spec, debe incluir una sección rewrite-policies para especificar el servicio o los servicios a los que se debe aplicar la directiva. Para obtener más información, consulte Configuraciones de directivas de ejemplo.

Después de implementar el archivo .yaml, el Citrix Ingress Controller aplica la configuración de directivas en el dispositivo Citrix ADC de entrada.

Pautas para la configuración de directivas

  • Si la CRD está asociada a un espacio de nombres, entonces, de forma predeterminada, la directiva se aplica a los servicios asociados con el espacio de nombres. Por ejemplo, si tiene el mismo nombre de servicio asociado a varios espacios de nombres, la directiva se aplica al servicio que pertenece al espacio de nombres asociado a la CRD.

  • Si ha definido varias directivas en un solo archivo .yaml, la primera configuración de directivas definida en el archivo tiene prioridad y las configuraciones de directivas posteriores se aplican según la secuencia. Si tiene varias directivas definidas en archivos diferentes, la primera configuración de directivas definida en el archivo que implementó primero tiene prioridad.

Pautas para el uso de Goto-Priority-expression

  • Las directivas de reescritura y respuesta se pueden combinar como varios grupos con la palabra clave NEXT dentro del campo goto-priority-expression.

  • Cuando el campo goto-priority-expression es NEXT dentro de la directiva actual y si la directiva actual se evalúa como True, se ejecuta la siguiente directiva del grupo y el flujo pasa a las siguientes directivas consecutivas, a menos que el campo goto-priority-expression apunte a END.

  • Cuando la directiva actual se evalúa FALSE, no goto-priority-expression tiene ningún impacto, ya que la ejecución de la directiva se detiene en la directiva actual.

  • El grupo de directivas de reescritura o respuesta dentro de las directivas de reescritura o respuesta comienza con la directiva asignada con goto-priority-expression como SIGUIENTE e incluye todas las directivas consecutivas hasta que se asigna el campo goto-priority-expression a END.

  • Cuando se utilizan directivas de reescritura o respuesta de grupo goto-priority-expression, los nombres de servicio vinculados a las directivas dentro del grupo deben ser los mismos.

  • La última directiva dentro de las directivas de reescritura o las directivas de respuesta siempre debe tener goto-priority-expression como END.

  • Si el campo goto-priority-expression no se especifica para una directiva, se asigna el valor predeterminado de END a goto-priority-expression.

Nota:

Para obtener más información sobre cómo utilizar el campo goto-priority-expression, consulte el ejemplo Modificar cadenas y el nombre de host en la URL solicitada.

Crear y verificar una directiva de reescritura y respuesta

Considere un caso en el que quiere definir una directiva en Citrix ADC para reescribir todas las URL entrantes new-url-for-the-application y enviarlas a los microservicios. Cree un archivo .yaml llamado target-url-rewrite.yaml y use los atributos CRD apropiados para definir la directiva de reescritura de la siguiente manera:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: targeturlrewrite
spec:
  rewrite-policies:
    - servicenames:
        - citrix-svc
      logpackets:
        logexpression: "http.req.url"
        loglevel: INFORMATIONAL
      rewrite-policy:
        operation: replace
        target: 'http.req.url'
        modify-expression: '"new-url-for-the-application"'
        comment: 'Target URL Rewrite - rewrite the url of the HTTP request'
        direction: REQUEST
        rewrite-criteria: 'http.req.is_valid'
<!--NeedCopy-->

Una vez que haya definido la configuración de la directiva, implemente el archivo .yaml con el siguiente comando:

kubectl create -f target-url-rewrite.yaml

Después de implementar el archivo .yaml, el Citrix Ingress Controller aplica la configuración de directivas en el dispositivo Citrix ADC de entrada.

En el nodo principal del clúster de Kubernetes, puede verificar el estado de la CRD de la directiva de reescritura aplicada con el siguiente comando:

Kubectl get rewritepolicies.citrix.com targeturlrewrite

Puede ver el estado de la siguiente manera:

kubectl get rewritepolicies.citrix.com targeturlrewrite 
NAME               STATUS    MESSAGE
targeturlrewrite   Success   CRD Activated

Si hay problemas al crear o aplicar la CRD, se puede depurar lo mismo con los registros de citrix-k8s-ingress-controller.

kubectl logs citrixingresscontroller

Además, puede verificar si la configuración se aplica en Citrix ADC mediante los siguientes pasos.

  1. Inicie sesión en la línea de comandos de Citrix ADC.
  2. Use el siguiente comando para verificar si la configuración se aplica a Citrix ADC:

    show run | grep `lb vserver`
    add lb vserver k8s-citrix_default_80_k8s-citrix-svc_default_80_svc HTTP 0.0.0.0 0 -persistenceType NONE -cltTimeout 180
    bind lb vserver k8s-citrix_default_80_k8s-citrix-svc_default_80_svc k8s-citrix_default_80_k8s-citrix-svc_default_80_svc
    bind lb vserver k8s-citrix_default_80_k8s-citrix-svc_default_80_svc -policyName k8s_crd_rewritepolicy_rwpolicy_targeturlrewrite_0_default -priority 100300076 -gotoPriorityExpression END -type REQUEST 
    

    Puede verificar que la directiva k8s_crd_rewritepolicy_rwpolicy_targeturlrewrite_0_default esté vinculada al servidor virtual de equilibrio de carga.

Configuraciones directivas de ejemplo

Configuración de directivas de respuesta

A continuación se muestra un ejemplo de configuración de directiva de respuesta (block-list-urls.yaml)

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: blocklisturls
spec:
  responder-policies:
    - servicenames:
        - citrix-svc
      responder-policy:
        respondwith:
          http-payload-string: '"HTTP/1.1 401 Access denied"'
        respond-criteria: 'http.req.url.equals_any("blocklistUrls")'
        comment: 'Blocklist certain Urls'


  patset:
    - name: blocklistUrls
      values:
        - '/app1'
        - '/app2'
        - '/app3'
<!--NeedCopy-->

En este ejemplo, si Citrix ADC recibe cualquier URL que coincida con las cadenas /app1, /app2 o /app3 definidas en patset, Citrix ADC bloquea la URL.

Directiva con registros de auditoría habilitados

A continuación se presenta un ejemplo de directiva con registros de auditoría habilitados (block-list-urls-audit-log.yaml).

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: blocklisturls
spec:
  responder-policies:
    - servicenames:
        - citrix-svc
      logpackets:
        logexpression: "http.req.url"
        loglevel: INFORMATIONAL
      responder-policy:
        respondwith:
          http-payload-string: '"HTTP/1.1 401 Access denied"'
        respond-criteria: 'http.req.url.equals_any("blocklistUrls")'
        comment: 'Blocklist certain Urls'


  patset:
    - name: blocklistUrls
      values:
        - '/app1'
        - '/app2'
        - '/app3'
<!--NeedCopy-->

Configuraciones de directivas múltiples

Puede agregar varias configuraciones de directivas en un solo archivo .yaml y aplicar las directivas al dispositivo Citrix ADC. Debe agregar secciones separadas para cada configuración de directivas (multi-policy-config.yaml).

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: multipolicy
spec:
  responder-policies:
    - servicenames:
        - citrix-svc
      responder-policy:
        redirect:
          url: '"www.citrix.com"'
        respond-criteria: 'client.ip.src.TYPECAST_text_t.equals_any("redirectIPs")'
        comment: 'Redirect IPs to citrix.com'
    - servicenames:
        - citrix-svc
      responder-policy:
        redirect:
          url: 'HTTP.REQ.HOSTNAME+http.req.url.MAP_STRING_DEFAULT_TO_KEY("modifyurls")'
        respond-criteria: 'http.req.is_valid'
        comment: 'modify specific URLs'

  rewrite-policies:
    - servicenames:
        - citrix-svc
      rewrite-policy:
        operation: insert_http_header
        target: 'sessionID'
        modify-expression: '"48592th42gl24456284536tgt2"'
        comment: 'insert SessionID in header'
        direction: RESPONSE
        rewrite-criteria: 'http.res.is_valid'



  dataset:
    - name: redirectIPs
      type: ipv4
      values:
        - 1.1.1.1
        - 2.2.2.2

  stringmap:
    - name: modifyurls
      comment: Urls to be modified string
      values:
        - key: '"/app1/"'
          value: '"/internal-app1/"'
        - key: '"/app2/"'
          value: '"/internal-app2/"'
<!--NeedCopy-->

El ejemplo contiene dos directivas de respuesta y una directiva de reescritura, en función de estas directivas, el dispositivo Citrix ADC realiza lo siguiente:

  • Cualquier solicitud de cliente a las direcciones IP definidas en el conjunto de datos redirectIP, es decir, 1.1.1.1 o 2.2.2.2 respectivamente, a la que se redirige la solicitud www.citrix.com.

  • Cualquier URL entrante con cadenas proporcionadas en el mapa de cadenas modifyurls se modifica al valor proporcionado en el mapa de cadenas. Por ejemplo, si la URL entrante tiene la cadena /app1/ se modifica a /internal-app1/.

  • Agrega un identificador de sesión como encabezado nuevo en la respuesta al cliente.

Ejemplo de casos de uso

Agregar encabezados de respuesta

Cuando la URL solicitada del cliente contiene /citrix-app/, puede agregar los siguientes encabezados en la respuesta HTTP de los microservicios al cliente mediante una directiva de reescritura:

  • Puerto de origen del cliente a la cabecera
  • Dirección IP de destino del servidor
  • encabezado HTTP aleatorio

La siguiente definición de directiva de reescritura de ejemplo agrega estos encabezados a la respuesta HTTP de los microservicios al cliente:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
name: addresponseheaders
spec:
rewrite-policies:
  - servicenames:
      - frontend
    rewrite-policy:
      operation: insert_before_all
      target: http.res.full_header
      modify-expression: '"\r\nx-port: "+client.tcp.srcport+"\r\nx-ip:"+client.ip.dst+"\r\nx-new-dummy-header: Sending_a_gift"'
      multiple-occurence-modify: 'text("\r\n\r\n")'
      comment: 'Response header rewrite'
      direction: RESPONSE
      rewrite-criteria: 'http.req.url.contains("/citrix-app/")'
<!--NeedCopy-->

Cree un archivo YAML (add_response_headers.yaml) con la definición de directiva de reescritura e implemente el archivo YAML con el siguiente comando:

kubectl create -f add_response_headers.yaml

Puede verificar el encabezado HTTP agregado a la respuesta de la siguiente manera:

$ curl -vvv http://app.cic-citrix.org/citrix-app/
*   Trying 10.102.33.176...
* TCP_NODELAY set
* Connected to app.cic-citrix.org (10.102.33.176) port 80 (#0)
> GET /citrix-app/ HTTP/1.1
> Host: app.cic-citrix.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.8.1
< Date: Fri, 29 Mar 2019 11:14:04 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Powered-By: PHP/5.5.9-1ubuntu4.14
< x-port: 22481 ==================> NEW RESPONSE HEADER
< x-ip:10.102.33.176 ==================> NEW RESPONSE HEADER
< x-new-dummy-header: Sending_a_gift ==================> NEW RESPONSE HEADER
<
<html>
<head>
<title> Front End App - v1 </title>


TRIMMED
.......

Agregar encabezado personalizado al paquete de respuesta HTTP

Con una directiva de reescritura, puede agregar encabezados personalizados en la respuesta HTTP de los microservicios al cliente.

El siguiente ejemplo de definición de directiva de reescritura agrega un encabezado personalizado a la respuesta HTTP de los microservicios al cliente:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: addcustomheaders
spec:
  rewrite-policies:
    - servicenames:
        - frontend
      rewrite-policy:
        operation: insert_before_all
        target: http.res.full_header
        modify-expression: '"\r\nx-request-time:"+sys.time+"\r\nx-using-citrix-ingress-controller: true"'
        multiple-occurence-modify: 'text("\r\n\r\n")'
        comment: 'Adding custom headers'
        direction: RESPONSE
        rewrite-criteria: 'http.req.is_valid'

<!--NeedCopy-->

Cree un archivo YAML (add_custom_headers.yaml) con la definición de directiva de reescritura e implemente el archivo YAML con el siguiente comando:

kubectl create -f add_custom_headers.yaml

Puede verificar el encabezado HTTP personalizado agregado a la respuesta de la siguiente manera:

$ curl -vvv http://app.cic-citrix.org/
* Trying 10.102.33.176...
* TCP_NODELAY set
* Connected to app.cic-citrix.org (10.102.33.176) port 80 (#0)
> GET / HTTP/1.1
> Host: app.cic-citrix.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.8.1
< Date: Fri, 29 Mar 2019 12:15:09 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Powered-By: PHP/5.5.9-1ubuntu4.14
< x-request-time:Fri, 29 Mar 2019 13:27:40 GMT =============> NEW HEADER ADDED
< x-using-citrix-ingress-controller: true  ===============> NEW HEADER ADDED
<
<html>
<head>
<title> Front End App - v1 </title>
<style>

TRIMMED
........

Reemplazar el nombre de host en la solicitud

Puede definir una directiva de reescritura como se muestra en el siguiente ejemplo YAML (http_request_modify_prefixasprefix.yaml) para reemplazar el nombre de host en una solicitud HTTP según sus requisitos:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: httpheadermodifyretainprefix
spec:
  rewrite-policies:
    - servicenames:
        - frontend
      rewrite-policy:
        operation: replace_all
        target: 'http.req.header("host")'
        modify-expression: '"citrix-service-app"'
        multiple-occurence-modify: 'text("app.cic-citrix.org")'
        comment: 'HTTP header rewrite of hostname'
        direction: REQUEST
        rewrite-criteria: 'http.req.is_valid'
<!--NeedCopy-->

Cree un archivo YAML (http_request_modify_prefixasprefix.yaml) con la definición de directiva de reescritura e implemente el archivo YAML con el siguiente comando:

kubectl create -f http_request_modify_prefixasprefix.yaml

Puede verificar la definición de la directiva mediante el comando curl. El nombre de host en la solicitud se reemplaza por el nombre de host definido.

curl http://app.cic-citrix.org/prefix/foo/bar

Salida: reemplazar el nombre de host

Modificar la raíz de la aplicación

Puede definir una directiva de reescritura para modificar la raíz de la aplicación si la raíz de la aplicación existente es /.

La siguiente directiva de reescritura de ejemplo modifica / en /citrix-approot/ en la URL de la solicitud:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
 name: httpapprootrequestmodify
spec:
 rewrite-policies:
   - servicenames:
       - frontend
     rewrite-policy:
       operation: replace
       target: http.req.url
       modify-expression: '"/citrix-approot/"'
       comment: 'HTTP app root request modify'
       direction: REQUEST
       rewrite-criteria: http.req.url.eq("/")
<!--NeedCopy-->

Cree un archivo YAML (http_approot_request_modify.yaml) con la definición de directiva de reescritura e implemente el archivo YAML con el siguiente comando:

kubectl crea -f http_approot_request_modify.yaml

Con el comando curl, puede verificar si la raíz de la aplicación se modifica según sus requisitos:

curl -vvv http://app.cic-citrix.org/

Salida:

Modificar app-root

Modificar las cadenas en la URL solicitada

Puede definir una directiva de reescritura para modificar las cadenas en la URL solicitada según sus requisitos.

La siguiente directiva de reescritura de ejemplo reemplaza las cadenas something por simple en la URL solicitada:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
name: httpurlreplacestring
spec:
rewrite-policies:
 - servicenames:
     - frontend
   rewrite-policy:
     operation: replace_all
     target: http.req.url
     modify-expression: '"/"'
     multiple-occurence-modify: 'regex(re~((^(/something/))|(^/something$))~)'
     comment: 'HTTP url replace string'
     direction: REQUEST
     rewrite-criteria: http.req.is_valid
<!--NeedCopy-->

Cree un archivo YAML (http_url_replace_string.yaml) con la definición de directiva de reescritura e implemente YAML con el siguiente comando:

kubectl create -f http_url_replace_string.yaml

Puede verificar la definición de la directiva mediante una solicitud curl con la cadena something. La cadena something se reemplaza por la cadena simple como se muestra en los siguientes ejemplos:

Ejemplo 1:

curl http://app.cic-citrix.org/something/simple/citrix

Salida:

Reemplazar cadena

Ejemplo 2:

curl http://app.cic-citrix.org/something

o

curl http://app.cic-citrix.org/something/

Salida:

Reemplazar cadena

Agregar el encabezado X-Forwarded-For dentro de una solicitud HTTP

Puede definir una directiva de reescritura como se muestra en el siguiente ejemplo YAML (http_x_forwarded_for_insert.yaml) para agregar el encabezado X-Forwarded-For dentro de una solicitud HTTP:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: httpxforwardedforaddition
spec:
  rewrite-policies:
    - servicenames:
        - frontend
      rewrite-policy:
        operation: insert_http_header
        target: X-Forwarded-For
        modify-expression: client.ip.src
        comment: 'HTTP Initial X-Forwarded-For header add'
        direction: REQUEST
        rewrite-criteria: 'HTTP.REQ.HEADER("X-Forwarded-For").EXISTS.NOT'

    - servicenames:
        - frontend
      rewrite-policy:
        operation: replace
        target: HTTP.REQ.HEADER("X-Forwarded-For")
        modify-expression: 'HTTP.REQ.HEADER("X-Forwarded-For").APPEND(",").APPEND(CLIENT.IP.SRC)'
        comment: 'HTTP Append X-Forwarded-For IPs'
        direction: REQUEST
        rewrite-criteria: 'HTTP.REQ.HEADER("X-Forwarded-For").EXISTS'
<!--NeedCopy-->

Cree un archivo YAML (http_x_forwarded_for_insert.yaml) con la definición de directiva de reescritura e implemente el archivo YAML con el siguiente comando:

kubectl create -f http_x_forwarded_for_insert.yaml

Con el comando curl, puede verificar el paquete HTTP con y sin encabezado X-Forwarded-For.

Ejemplo: Salida del paquete de solicitud HTTP sin encabezado X-Forwarded-For:

curl http://app.cic-citrix.org/

Salida:

Curl-output

Ejemplo: Salida del paquete de solicitud HTTP con encabezado X-Forwarded-For:

curl  curl --header "X-Forwarded-For: 1.1.1.1" http://app.cic-citrix.org/

Salida:

Salida CURL

Redirigir la solicitud HTTP a la solicitud HTTPS mediante la directiva de respuesta

Puede definir una definición de directiva de respuesta como se muestra en el siguiente ejemplo YAML (http_to_https_redirect.yaml) para redirigir las solicitudes HTTP a la solicitud HTTPS:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: httptohttps
spec:
  responder-policies:
    - servicenames:
        - frontend
      responder-policy:
        redirect:
          url: '"https://" +http.req.HOSTNAME.SERVER+":"+"443"+http.req.url'
        respond-criteria: 'http.req.is_valid'
        comment: 'http to https'

<!--NeedCopy-->

Cree un archivo YAML (http_to_https_redirect.yaml) con la definición de la directiva de respuesta e implemente el archivo YAML con el siguiente comando:

kubectl create -f http_to_https_redirect.yaml

Puede verificar si la solicitud HTTP se redirige a HTTPS de la siguiente manera:

Ejemplo 1:

$ curl -vvv  http://app.cic-citrix.org
* Rebuilt URL to: http://app.cic-citrix.org/
*   Trying 10.102.33.176...
* TCP_NODELAY set
* Connected to app.cic-citrix.org (10.102.33.176) port 80 (#0)
> GET / HTTP/1.1
> Host: app.cic-citrix.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 302 Found : Moved Temporarily
< Location: https://app.cic-citrix.org:443/   =======> Redirected to HTTPS
< Connection: close
< Cache-Control: no-cache
< Pragma: no-cache
<
* Closing connection 0

Ejemplo 2:

$ curl -vvv  http://app.cic-citrix.org/simple
*   Trying 10.102.33.176...
* TCP_NODELAY set
* Connected to app.cic-citrix.org (10.102.33.176) port 80 (#0)
> GET /simple HTTP/1.1
> Host: app.cic-citrix.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 302 Found : Moved Temporarily
< Location: https://app.cic-citrix.org:443/simple     ========> Redirected to HTTPS
< Connection: close
< Cache-Control: no-cache
< Pragma: no-cache
<
* Closing connection 0

Modificar las cadenas y el nombre de host en la URL solicitada

En este ejemplo se muestra el uso del atributo goto-priority-expression. Las pautas para el uso del campo goto-priority-expression se pueden encontrar en [Cómo escribir una configuración de directivas. En este ejemplo se modifica la URL http://www.citrite.org/something/simple/citrix a http://app.cic-citrix.org/simple/citrix.

Se escriben dos directivas de reescritura para modificar la URL:

  • Directiva de reescritura 1: Esta directiva se utiliza para modificar el nombre de host www.citrite.org a app.cic-citrix.org.
  • Directiva de reescritura 2: esta directiva se utiliza para modificar la URL /something/simple/citrix a /simple/citrix

Puede vincular las dos directivas mediante el atributo goto-priority-expression, como se muestra en el siguiente YAML:

  apiVersion: citrix.com/v1
  kind: rewritepolicy
  metadata:
    name: hostnameurlrewrite
  spec:
    rewrite-policies:
      - servicenames:
          - citrix-svc
        goto-priority-expression: NEXT
        rewrite-policy:
          operation: replace_all
          target: 'http.req.header("host")'
          modify-expression: '"app.cic-citrix.org"'
          multiple-occurence-modify: 'text("www.citrite.org")'
          comment: 'HTTP header rewrite of hostname'
          direction: REQUEST
          rewrite-criteria: 'http.req.is_valid.and(HTTP.REQ.HOSTNAME.EQ("www.citrite.org"))'
      - servicenames:
          - citrix-svc
        goto-priority-expression: END
        rewrite-policy:
          operation: replace_all
          target: http.req.url
          modify-expression: '"/"'
          multiple-occurence-modify: 'regex(re~((^(/something/))|(^/something$))~)'
          comment: 'HTTP url replace string'
          direction: REQUEST
          rewrite-criteria: 'http.req.is_valid.and(HTTP.REQ.HOSTNAME.EQ("www.citrite.org"))'`
<!--NeedCopy-->

Verificación

Puede verificar si la siguiente solicitud curl http://www.citrite.org/something/simple/citrix se ha modificado a http://app.cic-citrix.org/simple/citrix.

Ejemplo: modificación de la URL solicitada

curl http://www.citrite.org/something/simple/citrix

El nombre de host y la URL modificados para la URL solicitada están presentes en la imagen que se muestra a continuación:

Salida de curl

Llamada HTTP

Una llamada HTTP permite que Citrix ADC genere y envíe una solicitud HTTP o HTTPS a un servidor externo como parte de la evaluación de directivas y tome las medidas adecuadas en función de la respuesta obtenida del servidor externo. Puede usar la CRD de reescritura y respuesta para iniciar solicitudes de llamada HTTP desde Citrix ADC. Para obtener más información, consulte la documentación de llamadas HTTP.

Artículos relacionados

Usar directivas de reescritura y respuesta en Kubernetes