Contrôleur d'entrée Citrix ADC

Utiliser des stratégies de réécriture et de répondeur dans Kubernetes

Dans un environnement Kubernetes, pour déployer des stratégies de couche 7 spécifiques afin de gérer des scénarios tels que :

  • Redirection du trafic HTTP vers une URL spécifique
  • Blocage d’un ensemble d’adresses IP pour atténuer les attaques DDoS
  • Imposition de HTTP à HTTPS

Nécessite que vous ajoutiez les bibliothèques appropriées dans les microservices et que vous configuriez manuellement les stratégies. Au lieu de cela, vous pouvez utiliser les fonctionnalités de réécriture et de réponse fournies par l’appareil Citrix ADC d’entrée pour déployer ces stratégies.

Citrix fournit des définitions CustomResourceDefinitions (CRD) Kubernetes que vous pouvez utiliser avec le Citrix ingress controller pour automatiser les configurations et le déploiement de ces stratégies sur les Citrix ADC utilisés comme appareils d’entrée.

Le CRD Rewrite and Responder fourni par Citrix est conçu pour exposer un ensemble d’outils utilisés dans les Citrix ADC de première ligne. À l’aide de ces fonctionnalités, vous pouvez réécrire l’en-tête et la charge utile du trafic HTTP entrant et sortant, ainsi que répondre au trafic HTTP pour le compte d’un microservice.

Une fois que vous avez déployé le CRD de réécriture et de répondeur dans le cluster Kubernetes. Vous pouvez définir des stratégies de réécriture et de répondeur étendues à l’aide de jeux de données, de jeux de patchs et de mappages de chaînes, et également activer des journaux d’audit pour les statistiques sur le périphérique d’entrée. Pour plus d’informations sur la fonctionnalité de stratégie de réécriture et de répondeur fournie par Citrix ADC, consultez Stratégie de réécriture et stratégie de répondeur.

Remarque :

Le CRD Rewrite and Responder n’est pas pris en charge pour les itinéraires OpenShift. Vous pouvez utiliser l’entrée OpenShift pour utiliser le CRD de réécriture et de réponse.

Déployer le CRD Citrix Rewrite and Responder

Le fichier YAML de déploiement CRD Citrix Rewrite and Responder : rewrite-responder-policies-deployment.yaml.

Remarque :

Assurez-vous de ne pas modifier le fichier YAML de déploiement.

Déployez le CRD à l’aide de la commande suivante :

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

Par exemple,

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

Attributs CRD de réécriture et de répondeur

Le CRD fournit des attributs pour les différentes options nécessaires pour définir les politiques de réécriture et de répondeur. En outre, il fournit des attributs pour l’ensemble de données, le jeu de patchs, la carte de chaînes et les journaux d’audit à utiliser dans les stratégies de réécriture et de répondeur. Ces attributs CRD correspondent respectivement à la commande et à l’attribut Citrix ADC .

Politique de réécriture

Le tableau suivant répertorie les attributs CRD que vous pouvez utiliser pour définir une stratégie de réécriture. Le tableau répertorie également la commande et les attributs Citrix ADC correspondants.

Attribut CRD Commande Citrix ADC Attribut 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 Type

Responder policy

Le tableau suivant répertorie les attributs CRD que vous pouvez utiliser pour définir une stratégie de répondeur. Le tableau répertorie également la commande et les attributs Citrix ADC correspondants.

Attribut CRD Commande Citrix ADC Attribut Citrix ADC
Redirect Add responder action Type (la valeur du type)
url Add responder action Target
redirect-status-code Add responder action responseStatusCode
redirect-reason Add responder action reasonPhrase
Respond-with Add responder action Type (la valeur du type)
http-payload-string Add responder action Target
Noop Add responder policy Action (la valeur de l’action)
Reset Add responder policy Action (la valeur de l’action)
Drop Add responder policy Action (la valeur de l’action)
Respond-criteria Add responder policy Rule
Default-action Add responder policy undefAction

Audit log

Le tableau suivant répertorie les attributs CRD fournis pour activer le journal d’audit dans les stratégies de réécriture ou de répondeur. Le tableau répertorie également la commande et les attributs Citrix ADC correspondants.

Attribut CRD Commande Citrix ADC Attribut Citrix ADC
Logexpression Add audit message action stringBuilderExpr
Loglevel Add audit message action Loglevel

Dataset

Le tableau suivant répertorie les attributs CRD pour l’ensemble de données que vous pouvez utiliser dans les stratégies de réécriture ou de répondeur. Le tableau répertorie également la commande et les attributs Citrix ADC correspondants.

Attribut CRD Commande Citrix ADC Attribut Citrix ADC
Name Add policy dataset Name
Type Add policy dataset Type
Values Bind policy dataset Value

Patset

Attribut CRD Commande Citrix ADC Attribut Citrix ADC
Name Add policy patset Name
Values Bind policy patset string

String map

Attribut CRD Commande Citrix ADC Attribut Citrix ADC
Name Add policy stringmap Name
Key Bind policy stringmap Key
Value Bind policy stringmap Value

Goto-priority-expression

Le tableau suivant fournit des informations sur l’attribut goto-priority-expression, qui est un attribut CRD permettant de lier un groupe de plusieurs stratégies consécutives à des services.

Attribut CRD Commande Citrix ADC Attribut Citrix ADC Valeurs supportées Valeur par défaut
goto-priroty-expression Bind lb vserver gotoPriorityExpression NEXT and END End

Pour plus d’informations sur l’utilisation de l’attribut goto-priority-expression, consultez l’exemple Modifier les chaînes et le nom d’hôte dans l’URL demandée

Comment écrire une configuration de stratégie

Après avoir déployé le CRD fourni par Citrix dans le cluster Kubernetes, vous pouvez définir la configuration de la stratégie dans un fichier.yaml. Dans le fichier .yaml, utilisez rewritepolicy dans le champ kind et, en fonction de vos besoins, ajoutez l’une des sections individuelles suivantes dans spec pour la configuration de la stratégie.

  • rewrite-policy - Pour définir la configuration de la stratégie de réécriture.
  • responder-policy - Pour définir la configuration de la stratégie du répondeur.
  • logpackets - Pour activer les journaux d’audit.
  • dataset - Pour utiliser un ensemble de données pour une configuration de stratégie étendue.
  • patset - Pour utiliser un jeu de patères pour une configuration de stratégie étendue.
  • stringmaps - Pour utiliser des mappages de chaînes pour une configuration étendue des stratégies.

Dans ces sections, vous devez utiliser les attributs CRD fournis pour la configuration de stratégie respective (réécriture ou répondeur) pour définir la stratégie.

Vous devez également inclure une section rewrite-policies dans la section spec pour spécifier le ou les services auxquels la stratégie doit être appliquée. Pour plus d’informations, consultez la section Exemples de configurations de stratégie.

Après avoir déployé le fichier .yaml, le Citrix ingress controller applique la configuration de stratégie sur l’appareil Citrix ADC d’entrée.

Instructions relatives à la configuration de la stratégie

  • Si le CRD est associé à un espace de noms, la stratégie est appliquée par défaut aux services associés à l’espace de noms. Par exemple, si le même nom de service est associé à plusieurs espaces de noms, la stratégie est appliquée au service qui appartient à l’espace de noms associé au CRD.

  • Si vous avez défini plusieurs stratégies dans un seul fichier .yaml, la première configuration de stratégie définie dans le fichier est prioritaire et les configurations de stratégie suivantes sont appliquées conformément à la séquence. Si plusieurs stratégies sont définies dans différents fichiers, la première configuration de stratégie définie dans le fichier que vous avez déployé en premier est prioritaire.

Instructions relatives à l’utilisation de l’expression GoToPriority

  • Les stratégies de réécriture et de réponse peuvent être combinées en plusieurs groupes à l’aide du mot-clé NEXT dans le champ goto-priority-expression.

  • Lorsque le champ goto-priority-expression est NEXT dans la stratégie actuelle et si la stratégie actuelle correspond à True, la stratégie suivante du groupe est exécutée et le flux passe aux stratégies consécutives suivantes, sauf si le champ goto-priority-expression pointe vers END.

  • Lorsque la stratégie actuelle correspond à FALSE, goto-priority-expression n’a aucun impact, car l’exécution de la stratégie s’arrête à la stratégie actuelle.

  • Le groupe de stratégies de réécriture ou de répondeur au sein des stratégies de réécriture ou de répondeur commence par la stratégie affectée avec goto-priority-expression comme NEXT et inclut toutes les stratégies consécutives jusqu’à ce que le champ goto-priority-expression soit affecté à END.

  • Lorsque vous regroupez des stratégies de réécriture ou de répondeur à l’aide de goto-priority-expression, les noms de service liés aux stratégies au sein du groupe doivent être identiques.

  • La dernière stratégie des stratégies de réécriture ou des stratégies de répondeur doit toujours avoir goto-priority-expression comme END.

  • Si le champ goto-priority-expression n’est pas spécifié pour une stratégie, la valeur par défaut de END est affectée à goto-priority-expression.

Remarque :

Pour plus d’informations sur l’utilisation du champ goto-priority-expression, consultez l’exemple Modifier les chaînes et le nom d’hôte dans l’URL demandée.

Créer et vérifier une stratégie de réécriture et de répondeur

Imaginez un scénario dans lequel vous souhaitez définir une stratégie dans Citrix ADC pour réécrire toutes les URL entrantes vers new-url-for-the-application et les envoyer aux microservices. Créez un fichier .yaml appelé target-url-rewrite.yaml et utilisez les attributs CRD appropriés pour définir la stratégie de réécriture comme suit :

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

Après avoir défini la configuration de la stratégie, déployez le fichier .yaml à l’aide de la commande suivante :

kubectl create -f target-url-rewrite.yaml

Après avoir déployé le fichier .yaml, le Citrix ingress controller applique la configuration de stratégie sur l’appareil Citrix ADC d’entrée.

Sur le nœud maître du cluster Kubernetes, vous pouvez vérifier l’état de la stratégie de réécriture CRD appliquée à l’aide de la commande suivante :

Kubectl get rewritepolicies.citrix.com targeturlrewrite

Vous pouvez afficher l’état comme suit :

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

S’il y a des problèmes lors de la création ou de l’application du CRD, celui-ci peut être débogué à l’aide des journaux du contrôleur d’entrée citrix-k8s-ingress-controller.

kubectl logs citrixingresscontroller

Vous pouvez également vérifier si la configuration est appliquée sur Citrix ADC en procédant comme suit.

  1. Ouvrez une session sur la ligne de commande Citrix ADC.
  2. Utilisez la commande suivante pour vérifier si la configuration est appliquée à 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 
    

    Vous pouvez vérifier que la stratégie k8s_crd_rewritepolicy_rwpolicy_targeturlrewrite_0_default est liée au serveur virtuel d’équilibrage de charge.

Exemples de configurations de stratégie

Configuration de la stratégie du répondeur

Voici un exemple de configuration de stratégie de répondeur (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-->

Dans cet exemple, si Citrix ADC reçoit une URL correspondant aux chaînes /app1, /app2 ou /app3 définies dans patset, Citrix ADC bloque l’URL.

Stratégie avec les journaux d’audit activés

Voici un exemple de stratégie avec les journaux d’audit activés (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-->

Configurations de stratégie

Vous pouvez ajouter plusieurs configurations de stratégie dans un seul fichier .yaml et appliquer les stratégies à l’appareil Citrix ADC. Vous devez ajouter des sections distinctes pour chaque configuration de stratégie (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-->

L’exemple contient deux stratégies de répondeur et une stratégie de réécriture, sur la base de ces stratégies, l’appareil Citrix ADC effectue les opérations suivantes :

  • Toute demande client à des adresses IP définies dans l’ensemble de données redirectIP, c’est-à-dire, 1.1.1.1 ou 2.2.2.2 respectivement, vers laquelle la demande est redirigée www.citrix.com.

  • Toute URL entrante avec des chaînes fournies dans le mappage de chaînes modifyurls est modifiée en fonction de la valeur fournie dans le mappage de chaînes. Par exemple, si l’URL entrante contient la chaîne /app1/ est modifiée en /internal-app1/

  • Ajoute un ID de session en tant que nouvel en-tête dans la réponse au client.

Exemples de cas d’utilisation

Ajouter un en-tête de réponse

Lorsque l’URL demandée par le client contient /citrix-app/, vous pouvez ajouter les en-têtes suivants dans la réponse HTTP des microservices au client à l’aide d’une stratégie de réécriture :

  • Port source du client vers l’en-tête
  • Adresse IP de destination du serveur
  • en-tête HTTP aléatoire

L’exemple de définition de stratégie de réécriture suivant ajoute ces en-têtes à la réponse HTTP des microservices vers le client :

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

Créez un fichier YAML (add_response_headers.yaml) avec la définition de stratégie de réécriture et déployez le fichier YAML à l’aide de la commande suivante :

kubectl create -f add_response_headers.yaml

Vous pouvez vérifier l’en-tête HTTP ajouté à la réponse comme suit :

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

Ajouter un en-tête personnalisé au paquet de réponse HTTP

À l’aide d’une stratégie de réécriture, vous pouvez ajouter des en-têtes personnalisés dans la réponse HTTP des microservices vers le client.

L’exemple de définition de stratégie de réécriture suivant ajoute un en-tête personnalisé à la réponse HTTP des microservices vers le client :

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

Créez un fichier YAML (add_custom_headers.yaml) avec la définition de stratégie de réécriture et déployez le fichier YAML à l’aide de la commande suivante :

kubectl create -f add_custom_headers.yaml

Vous pouvez vérifier l’en-tête HTTP personnalisé ajouté à la réponse comme suit :

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

Remplacer le nom d’hôte dans la demande

Vous pouvez définir une stratégie de réécriture comme indiqué dans l’exemple suivant YAML (http_request_modify_prefixasprefix.yaml) pour remplacer le nom d’hôte dans une requête HTTP selon vos besoins :

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

Créez un fichier YAML (http_request_modify_prefixasprefix.yaml) avec la définition de stratégie de réécriture et déployez le fichier YAML à l’aide de la commande suivante :

kubectl create -f http_request_modify_prefixasprefix.yaml

Vous pouvez vérifier la définition de stratégie à l’aide de la commande curl. Le nom d’hôte de la demande est remplacé par le nom d’hôte défini.

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

Sortie : Remplacer le nom d'hôte

Modifier la racine de l’application

Vous pouvez définir une stratégie de réécriture pour modifier la racine de l’application si la racine d’application existante est /.

L’exemple de stratégie de réécriture suivant est remplacé / par /citrix-approot/ dans l’URL de demande :

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

Créez un fichier YAML (http_approot_request_modify.yaml) avec la définition de stratégie de réécriture et déployez le fichier YAML à l’aide de la commande suivante :

kubectl crée -f http_approot_request_modify.yaml

À l’aide de la commande curl, vous pouvez vérifier si la racine de l’application est modifiée selon vos besoins :

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

Sortie :

Modifier la racine de l'application

Modifiez les chaînes de l’URL demandée

Vous pouvez définir une stratégie de réécriture pour modifier les chaînes de l’URL demandée selon vos besoins.

L’exemple de stratégie de réécriture suivant remplace les chaînes something par simple dans l’URL demandée :

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

Créez un fichier YAML (http_url_replace_string.yaml) avec la définition de stratégie de réécriture et déployez le fichier YAML à l’aide de la commande suivante :

kubectl create -f http_url_replace_string.yaml

Vous pouvez vérifier la définition de stratégie à l’aide d’une curl demande contenant la chaîne something. La chaîne something est remplacée par la chaîne simple comme indiqué dans les exemples suivants :

Exemple 1 :

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

Sortie :

Remplacer la chaîne

Exemple 2 :

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

Ou

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

Sortie :

Remplacer la chaîne

Ajouter l’en-tête X-Forwarded-For dans une requête HTTP

Vous pouvez définir une stratégie de réécriture comme indiqué dans l’exemple suivant YAML (http_x_forwarded_for_insert.yaml) pour ajouter l’en-tête X-Forwarded-For dans une requête 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-->

Créez un fichier YAML (http_x_forwarded_for_insert.yaml) avec la définition de stratégie de réécriture et déployez le fichier YAML à l’aide de la commande suivante :

kubectl create -f http_x_forwarded_for_insert.yaml

À l’aide de la commande curl, vous pouvez vérifier le paquet HTTP avec et sans l’en-tête X-Forwarded-For.

Exemple : Sortie du paquet de requête HTTP sans en-tête X-Forwarded-For:

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

Sortie :

Curl-output

Exemple : sortie du paquet de requête HTTP avec en-tête X-Forwarded-For:

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

Sortie :

Curl-output

Rediriger la demande HTTP vers la demande HTTPS à l’aide d’une stratégie de

Vous pouvez définir une définition de stratégie de répondeur comme indiqué dans l’exemple suivant YAML (http_to_https_redirect.yaml) pour rediriger les demandes HTTP vers la requête 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-->

Créez un fichier YAML (http_to_https_redirect.yaml) avec la définition de stratégie de répondeur et déployez le fichier YAML à l’aide de la commande suivante :

kubectl create -f http_to_https_redirect.yaml

Vous pouvez vérifier si la demande HTTP est redirigée vers HTTPS comme suit :

Exemple 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

Exemple 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

Modifier les chaînes et le nom d’hôte dans l’URL demandée

Cet exemple montre l’utilisation de l’attribut goto-priority-expression. Les instructions relatives à l’utilisation du champ goto-priority-expression se trouvent à l’adresse [Comment écrire une configuration de stratégie. Cet exemple montre comment modifier l’URL http://www.citrite.org/something/simple/citrix en http://app.cic-citrix.org/simple/citrix.

Deux stratégies de réécriture sont écrites pour modifier l’URL :

  • Stratégie de réécriture 1 : Cette stratégie est utilisée pour modifier le nom d’hôte www.citrite.org en app.cic-citrix.org.
  • Stratégie de réécriture 2 : Cette stratégie est utilisée pour modifier l’URL /something/simple/citrix vers /simple/citrix

Vous pouvez lier les deux stratégies à l’aide de l’attribut goto-priority-expression, comme indiqué dans le YAML suivant :

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

Vérification

Vous pouvez vérifier si la demande curl suivante http://www.citrite.org/something/simple/citrix est modifiée en http://app.cic-citrix.org/simple/citrix.

Exemple : Modification de l’URL demandée

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

Le nom d’hôte et l’URL modifiés pour l’URL demandée sont présents dans l’image affichée comme suit :

Sortie Curl

Légende HTTP

Une légende HTTP permet à Citrix ADC de générer et d’envoyer une demande HTTP ou HTTPS à un serveur externe dans le cadre de l’évaluation de la stratégie et de prendre les mesures appropriées en fonction de la réponse obtenue du serveur externe. Vous pouvez utiliser le CRD de réécriture et de réponse pour initier des demandes d’appel HTTP à partir de Citrix ADC. Pour plus d’informations, consultez la documentation relative aux légendes HTTP.

Articles connexes

Utiliser des stratégies de réécriture et de répondeur dans Kubernetes