Citrix ADC Ingress Controller

Verwenden von Rewrite- und Responder-Richtlinien in Kubernetes

In einer Kubernetes-Umgebung, um bestimmte Layer-7-Richtlinien bereitzustellen, um Szenarien wie:

  • Umleiten des HTTP-Datenverkehrs zu einer bestimmten URL
  • Blockieren einer Reihe von IP-Adressen zur Abwehr von DDoS-Angriffen
  • Imposantes HTTP zu HTTPS

Erfordert, dass Sie innerhalb der Microservices geeignete Bibliotheken hinzufügen und die Richtlinien manuell konfigurieren. Stattdessen können Sie die Rewrite- und Responder-Funktionen verwenden, die vom Citrix ADC-Gerät von Ingress bereitgestellt werden, um diese Richtlinien bereitzustellen.

Citrix bietet Kubernetes CustomResourceDefinitions (CRDs), die Sie mit dem Citrix Ingress Controller verwenden können, um die Konfiguration und Bereitstellung dieser Richtlinien auf den Citrix ADCs zu automatisieren, die als Ingress-Geräte verwendet werden.

Die von Citrix bereitgestellte Rewrite- und Responder-CRD wurde entwickelt, um eine Reihe von Tools bereitzustellen, die in Citrix ADCs an vorderster Front verwendet werden. Mit diesen Funktionen können Sie den Header und die Nutzlast von ein- und ausgehendem HTTP-Verkehr umschreiben und im Namen eines Microservices auf HTTP-Verkehr reagieren.

Sobald Sie die Rewrite- und Responder-CRD im Kubernetes-Cluster bereitgestellt haben. Sie können umfangreiche Rewrite- und Responder-Richtlinien mit Datasets, Pfadsätzen und Zeichenfolgenzuordnungen definieren und außerdem Auditprotokolle für Statistiken auf dem Eingangsgerät aktivieren. Weitere Informationen zur von Citrix ADC bereitgestellten Rewrite- und Responder-Richtlinienfunktion finden Sie unter Rewrite-Richtlinie und Responder-Richtlinie.

Hinweis:

Das Rewrite and Responder-CRD wird für OpenShift-Routen nicht unterstützt. Sie können OpenShift-Ingress verwenden, um Rewrite- und Responder-CRD zu verwenden.

Bereitstellen der Citrix Rewrite- und Responder-CRD

Die YAML-Datei für die Citrix Rewrite- und Responder-CRD-Bereitstellung: rewrite-responder-policies-deployment.yaml.

Hinweis:

Stellen Sie sicher, dass Sie die YAML-Bereitstellungsdatei nicht ändern.

Stellen Sie die CRD mithilfe des folgenden Befehls bereit:

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

Zum Beispiel:

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

Rewrite- und Responder-CRD-Attribute

Das CRD bietet Attribute für die verschiedenen Optionen, die zum Definieren der Rewrite- und Responder-Richtlinien erforderlich sind. Außerdem bietet es Attribute für Datensätze, Pfadsätze, Zeichenfolgenzuordnungen und Auditprotokolle, die in den Rewrite- und Responder-Richtlinien verwendet werden können. Diese CRD-Attribute entsprechen dem Citrix ADC-Befehl bzw. -Attribut.

Rewrite-Richtlinie

In der folgenden Tabelle sind die CRD-Attribute aufgeführt, mit denen Sie eine Rewrite-Richtlinie definieren können. In der Tabelle sind außerdem die entsprechenden Citrix ADC-Befehle und -Attribute aufgeführt.

CRD-Attribut Citrix ADC-Befehl Citrix ADC-Attribut
rewrite-criteria Hinzufügen einer Rewrite-Richtlinie Regel
default-action Hinzufügen einer Rewrite-Richtlinie undefAction
Betrieb Rewrite-Aktion hinzufügen type
target Rewrite-Aktion hinzufügen target
modify-expression Rewrite-Aktion hinzufügen stringBuilderExpr
multiple-occurence-modify Rewrite-Aktion hinzufügen Suchen
additional-multiple-occurence-modify Rewrite-Aktion hinzufügen RefineSearch
Richtung Bind lb vserver Typ

Responder-Richtlinie

In der folgenden Tabelle sind die CRD-Attribute aufgeführt, die Sie zum Definieren einer Responder-Richtlinie verwenden können. In der Tabelle sind außerdem die entsprechenden Citrix ADC-Befehle und -Attribute aufgeführt.

CRD-Attribut Citrix ADC-Befehl Citrix ADC-Attribut
Umleiten Responderaktion hinzufügen Type (der Wert von type)
url Responderaktion hinzufügen Ziel
redirect-status-code Responderaktion hinzufügen responseStatusCode
redirect-reason Responderaktion hinzufügen reasonPhrase
Respond-with Responderaktion hinzufügen Type (der Wert von type)
http-payload-string Responderaktion hinzufügen Ziel
Noop Responder-Richtlinie hinzufügen Action (der Wert von Action)
Reset Responder-Richtlinie hinzufügen Action (der Wert von Action)
Drop Responder-Richtlinie hinzufügen Action (der Wert von Action)
Respond-criteria Responder-Richtlinie hinzufügen Regel
Default-action Responder-Richtlinie hinzufügen undefAction

Protokoll der Prüfung

In der folgenden Tabelle sind die CRD-Attribute aufgeführt, die das Auditprotokoll innerhalb der Rewrite- oder Responder-Richtlinien ermöglichen In der Tabelle sind außerdem die entsprechenden Citrix ADC-Befehle und -Attribute aufgeführt.

CRD-Attribut Citrix ADC-Befehl Citrix ADC-Attribut
Logexpression Aktion “Auditnachricht hinzufügen” stringBuilderExpr
Loglevel Aktion “Auditnachricht hinzufügen” Loglevel

Dataset

In der folgenden Tabelle sind die CRD-Attribute für Datensätze aufgeführt, die Sie innerhalb der Rewrite- oder Responder-Richtlinien verwenden können. In der Tabelle sind außerdem die entsprechenden Citrix ADC-Befehle und -Attribute aufgeführt.

CRD-Attribut Citrix ADC-Befehl Citrix ADC-Attribut
Name Richtliniendataset hinzufügen Name
Typ Richtliniendataset hinzufügen Typ
Werte Richtliniendataset binden Wert

Patset

CRD-Attribut Citrix ADC-Befehl Citrix ADC-Attribut
Name Richtlinien-Patset hinzufügen Name
Werte Richtlinien-Patset binden string

String-Map

CRD-Attribut Citrix ADC-Befehl Citrix ADC-Attribut
Name Richtlinienzeichenfolgenzuordnung hinzufügen Name
Schlüssel Stringmap der Richtlinie binden Schlüssel
Wert Stringmap der Richtlinie binden Wert

Goto-priority-expression

Die folgende Tabelle enthält Informationen über das goto-priority-expression Attribut, bei dem es sich um ein CRD-Attribut zum Binden einer Gruppe mehrerer aufeinanderfolgender Richtlinien an Dienste handelt.

CRD-Attribut Citrix ADC-Befehl Citrix ADC-Attribut Unterstützte Werte Standardwert
goto-priroty-expression Bind lb vserver gotoPriorityExpression NEXT und END Ende

Weitere Informationen zur Verwendung des goto-priority-expression Attributs finden Sie im Beispiel Ändern von Zeichenfolgen und Hostnamen in der angeforderten URL

So schreiben Sie eine Richtlinienkonfiguration

Nachdem Sie die von Citrix bereitgestellte CRD im Kubernetes-Cluster bereitgestellt haben, können Sie die Richtlinienkonfiguration in einer.yaml Datei definieren. Verwenden Sie rewritepolicy in der .yaml Datei vor kind Ort und fügen Sie auf der Grundlage Ihrer Anforderung einen der folgenden einzelnen Abschnitte in spec für die Richtlinienkonfiguration hinzu.

  • rewrite-policy - Um die Rewrite-Richtlinienkonfiguration zu definieren.
  • responder-policy - Zum Definieren der Konfiguration der Responder-Richtlinie.
  • logpackets - Um Überwachungsprotokolle zu aktivieren.
  • dataset - Verwendung eines Datensatzes für eine umfangreiche Richtlinienkonfiguration.
  • patset - Verwendung eines Pfadsatzes für eine umfangreiche Richtlinienkonfiguration.
  • stringmaps - Verwendung von Zeichenfolgenzuordnungen für eine umfangreiche Richtlinienkonfiguration.

In diesen Abschnitten müssen Sie die CRD-Attribute verwenden, die für die jeweilige Richtlinienkonfiguration (Rewrite oder Responder) bereitgestellt werden, um die Richtlinie zu definieren.

In diesem Abschnitt müssen Sie außerdem einen specrewrite-policies Abschnitt einschließen, in dem Sie den Dienst oder die Dienste angeben, auf die die Richtlinie angewendet werden muss. Weitere Informationen finden Sie unter Beispiel für Richtlinienkonfigurationen.

Nachdem Sie die .yaml-Datei bereitgestellt haben, wendet der Citrix Ingress Controller die Richtlinienkonfiguration auf dem Ingress Citrix ADC-Gerät an.

Richtlinien für die Richtlinienkonfiguration

  • Wenn die CRD mit einem Namespace verknüpft ist, wird die Richtlinie standardmäßig auf die mit dem Namespace verknüpften Dienste angewendet. Wenn Sie beispielsweise denselben Dienstnamen mit mehreren Namespaces verknüpft haben, wird die Richtlinie auf den Dienst angewendet, der zu dem mit der CRD verknüpften Namespace gehört.

  • Wenn Sie mehrere Richtlinien in einer einzigen .yaml Datei definiert haben, hat die erste in der Datei definierte Richtlinienkonfiguration Vorrang, und die nachfolgenden Richtlinienkonfigurationen werden gemäß der Reihenfolge angewendet. Wenn Sie mehrere Richtlinien in verschiedenen Dateien definiert haben, hat die erste Richtlinienkonfiguration, die in der Datei definiert ist, die Sie zuerst bereitgestellt haben, Vorrang.

Richtlinien für die Verwendung von GoTo-Priority-Expression

  • Die Rewrite- und Responder-Richtlinien können mit dem Schlüsselwort NEXTinnerhalb des Feldes goto-priority-expression als mehrere Gruppen kombiniert werden.

  • Wenn sich das goto-priority-expression Feld NEXT in der aktuellen Richtlinie befindet und wenn die aktuelle Richtlinie zu ausgewertet wird True, wird die nächste Richtlinie in der Gruppe ausgeführt, und der Fluss wechselt zu den nächsten aufeinanderfolgenden Richtlinien, sofern das goto-priority-expression Feld nicht auf zeigt END.

  • Wenn die aktuelle Richtlinie zu ausgewertet wird FALSE, goto-priority-expression hat der keine Auswirkungen, da die Richtlinienausführung bei der aktuellen Richtlinie endet.

  • Die Rewrite- oder Responder-Richtliniengruppe innerhalb der Rewrite- oder Responder-Richtlinien beginnt mit der Richtlinie, die goto-priority-expression als NEXT zugewiesen wurde, und umfasst alle aufeinanderfolgenden Richtlinien, bis das goto-priority-expression Feld zugewiesen ist END.

  • Wenn Sie Rewrite- oder Responder-Richtlinien mit goto-priority-expression gruppieren, sollten die Dienstnamen, die an die Richtlinien innerhalb der Gruppe gebunden sind, identisch sein.

  • Die letzte Richtlinie innerhalb der Rewrite-Richtlinien oder Responder-Richtlinien sollte immer die goto-priority-expression als haben END.

  • Wenn das goto-priority-expression Feld nicht für eine Richtlinie angegeben ist, wird der Standardwert von END zugewiesen goto-priority-expression.

Hinweis:

Weitere Informationen zur Verwendung des goto-priority-expression Feldes finden Sie im Beispiel Ändern von Zeichenfolgen und Hostnamen in der angeforderten URL.

Erstellen und überprüfen Sie eine Rewrite- und Responder-Richtlinie

Stellen Sie sich ein Szenario vor, in dem Sie eine Richtlinie in Citrix ADC definieren möchten, um alle eingehenden URLs an die Microservices neu zu schreiben new-url-for-the-application und an die Microservices zu senden. Erstellen Sie eine .yaml Datei mit dem Namen target-url-rewrite.yaml und verwenden Sie die entsprechenden CRD-Attribute, um die Rewrite-Richtlinie wie folgt zu definieren:

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

Nachdem Sie die Richtlinienkonfiguration definiert haben, stellen Sie die .yaml-Datei mit dem folgenden Befehl bereit:

kubectl create -f target-url-rewrite.yaml

Nachdem Sie die .yaml-Datei bereitgestellt haben, wendet der Citrix Ingress Controller die Richtlinienkonfiguration auf dem Ingress Citrix ADC-Gerät an.

Auf dem Masterknoten im Kubernetes-Cluster können Sie den Status der angewendeten CRD für die Rewrite-Richtlinie mit dem folgenden Befehl überprüfen:

Kubectl get rewritepolicies.citrix.com targeturlrewrite

Sie können den Status wie folgt anzeigen:

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

Wenn beim Erstellen oder Anwenden der CRD Probleme auftreten, kann dasselbe mithilfe der citrix-k8s-ingress-Controller-Protokolle debuggt werden.

kubectl logs citrixingresscontroller

Sie können auch überprüfen, ob die Konfiguration auf dem Citrix ADC angewendet wird, indem Sie die folgenden Schritte ausführen.

  1. Melden Sie sich bei der Citrix ADC-Befehlszeile an.
  2. Verwenden Sie den folgenden Befehl, um zu überprüfen, ob die Konfiguration auf den Citrix ADC angewendet wird:

    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 
    

    Sie können überprüfen, ob die Richtlinie an den virtuellen Lastausgleichsserver gebunden k8s_crd_rewritepolicy_rwpolicy_targeturlrewrite_0_default ist.

Beispiel für Richtlinienkonfigurationen

Konfiguration der Responderrichtlinie

Es folgt ein Beispiel für eine Responder-Richtlinienkonfiguration (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-->

In diesem Beispiel blockiert Citrix ADC die URL /app1, /app2wenn Citrix ADC eine URL erhält patset, die den in oder definierten /app3 Zeichenfolgen entspricht.

Richtlinie mit aktivierten Überwachungsprotokollen

Es folgt ein Beispiel für eine Richtlinie mit aktivierten Überwachungsprotokollen (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-->

Mehrere Richtlinienkonfigurationen

Sie können mehrere Richtlinienkonfigurationen in einer einzigen .yaml Datei hinzufügen und die Richtlinien auf das Citrix ADC-Gerät anwenden. Sie müssen für jede Richtlinienkonfiguration separate Abschnitte hinzufügen (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-->

Das Beispiel enthält zwei Responder-Richtlinien und eine Rewrite-Richtlinie. Basierend auf diesen Richtlinien führt das Citrix ADC-Gerät Folgendes aus:

  • Jede Clientanfrage an IP-Adressen, die in der redirectIP Datenmenge definiert sind, 1.1.1.12.2.2.2 d. h. die Anfrage wird umgeleitet www.citrix.com.

  • Jede eingehende URL mit in der modifyurls Stringmap bereitgestellten Zeichenfolgen wird auf den in der Stringmap bereitgestellten Wert geändert. Wenn die eingehende URL beispielsweise hat, /app1/ wird die Zeichenfolge geändert zu /internal-app1/

  • Fügt eine Sitzungs-ID als neuen Header in der Antwort an den Client hinzu.

Anwendungsfälle

Response-Header hinzufügen

Wenn die vom Client angeforderte URL enthält /citrix-app/, können Sie mit einer Rewrite-Richtlinie die folgenden Header in der HTTP-Antwort von den Microservices zum Client hinzufügen:

  • Clientquellport zum Header
  • Ziel-IP-Adresse des Servers
  • zufälliger HTTP Header

Das folgende Beispiel für eine Rewrite-Richtliniendefinition fügt diese Header zur HTTP-Antwort von den Microservices an den Client hinzu:

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

Erstellen Sie eine YAML-Datei (add_response_headers.yaml) mit der Rewrite-Richtliniendefinition und stellen Sie die YAML-Datei mit dem folgenden Befehl bereit:

kubectl create -f add_response_headers.yaml

Sie können den zur Antwort hinzugefügten HTTP-Header wie folgt überprüfen:

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

Benutzerdefinierten Header zum HTTP-Antwortpaket hinzufügen

Mithilfe einer Rewrite-Richtlinie können Sie benutzerdefinierte Header in der HTTP-Antwort von den Microservices zum Client hinzufügen.

Das folgende Beispiel für eine Rewrite-Richtliniendefinition fügt der HTTP-Antwort von den Microservices zum Client einen benutzerdefinierten Header hinzu:

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

Erstellen Sie eine YAML-Datei (add_custom_headers.yaml) mit der Rewrite-Richtliniendefinition und stellen Sie die YAML-Datei mit dem folgenden Befehl bereit:

kubectl create -f add_custom_headers.yaml

Sie können den zur Antwort hinzugefügten benutzerdefinierten HTTP-Header wie folgt überprüfen:

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

Ersetzen Sie den Hostnamen in der Anfrage

Sie können eine Rewrite-Richtlinie definieren, wie im folgenden Beispiel gezeigt YAML (http_request_modify_prefixasprefix.yaml), um den Hostnamen in einer HTTP-Anforderung gemäß Ihren Anforderungen zu ersetzen:

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

Erstellen Sie eine YAML-Datei (http_request_modify_prefixasprefix.yaml) mit der Rewrite-Richtliniendefinition und stellen Sie die YAML-Datei mit dem folgenden Befehl bereit:

kubectl create -f http_request_modify_prefixasprefix.yaml

Sie können die Richtliniendefinition mit dem curl Befehl überprüfen. Der Hostname in der Anforderung wird durch den definierten Hostnamen ersetzt.

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

Ausgabe: Host-Namen ersetzen

Ändern des Anwendungsstamms

Sie können eine Rewrite-Richtlinie definieren, um den Anwendungsstamm zu ändern, falls der vorhandene Anwendungsstamm / ist.

Im folgenden Beispiel für eine Rewrite-Richtlinie wird / zu /citrix-approot/ in der Anforderungs-URL geändert:

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

Erstellen Sie eine YAML-Datei (http_approot_request_modify.yaml) mit der Rewrite-Richtliniendefinition und stellen Sie die YAML-Datei mit dem folgenden Befehl bereit:

kubectl create -f http_approot_request_modify.yaml

Mit dem curl Befehl können Sie überprüfen, ob der Anwendungsstamm gemäß Ihren Anforderungen geändert wurde:

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

Ausgang:

App-root ändern

Ändern Sie die Zeichenfolgen in der angeforderten URL

Sie können eine Rewrite-Richtlinie definieren, um die Zeichenfolgen in der angeforderten URL gemäß Ihren Anforderungen zu ändern.

Das folgende Beispiel für eine Rewrite-Richtlinie ersetzt die Zeichenfolgen something mit simple in der angeforderten URL:

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

Erstellen Sie eine YAML-Datei (http_url_replace_string.yaml) mit der Rewrite-Richtliniendefinition und stellen Sie die YAML mit dem folgenden Befehl bereit:

kubectl create -f http_url_replace_string.yaml

Sie können die Richtliniendefinition mithilfe einer curl Anforderung mit der Zeichenfolge überprüfen something. Die Zeichenfolge something wird durch die Zeichenfolge ersetzt, simple wie in den folgenden Beispielen gezeigt:

Beispiel 1:

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

Ausgang:

Zeichenkette ersetzen

Beispiel 2:

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

Oder

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

Ausgang:

Zeichenkette ersetzen

Fügen Sie den X-Forwarded-For Header innerhalb einer HTTP-Anfrage hinzu

Sie können eine Rewrite-Richtlinie definieren, wie im folgenden Beispiel gezeigt YAML (http_x_forwarded_for_insert.yaml), um den X-Forwarded-For Header innerhalb einer HTTP-Anforderung hinzuzufügen:

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

Erstellen Sie eine YAML-Datei (http_x_forwarded_for_insert.yaml) mit der Rewrite-Richtliniendefinition und stellen Sie die YAML-Datei mit dem folgenden Befehl bereit:

kubectl create -f http_x_forwarded_for_insert.yaml

Mit dem curl Befehl können Sie das HTTP-Paket mit und ohne X-Forwarded-For Header überprüfen.

Beispiel: Ausgabe des HTTP-Request-Pakets ohne X-Forwarded-For Header:

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

Ausgang:

Curl-output

Beispiel: Ausgabe des HTTP-Request-Pakets mit X-Forwarded-For Header:

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

Ausgang:

Curl-Ausgang

Leiten Sie die HTTP-Anfrage mit der Responder-Richtlinie an eine HTTPS-Anfrage um

Sie können eine Responder-Richtliniendefinition definieren, wie im folgenden Beispiel gezeigt YAML (http_to_https_redirect.yaml), um HTTP-Anforderungen an die HTTPS-Anforderung umzuleiten:

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

Erstellen Sie eine YAML-Datei (http_to_https_redirect.yaml) mit Responder-Richtlinie Responder-Richtliniendefinition und stellen Sie die YAML-Datei mit dem folgenden Befehl bereit:

kubectl create -f http_to_https_redirect.yaml

Sie können wie folgt überprüfen, ob die HTTP-Anforderung an HTTPS umgeleitet wurde:

Beispiel 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

Beispiel 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

Ändern Sie Zeichenfolgen und den Hostnamen in der angeforderten URL

Dieses Beispiel zeigt die Verwendung des goto-priority-expression Attributs. Die Richtlinien für die Verwendung des goto-priority-expression Feldes finden Sie unter [So schreiben Sie eine Richtlinienkonfiguration. In diesem Beispiel wird die URL http://www.citrite.org/something/simple/citrix zu geändert http://app.cic-citrix.org/simple/citrix.

Zwei Rewrite-Richtlinien werden geschrieben, um die URL zu ändern:

  • Rewrite-Richtlinie 1: Diese Richtlinie wird verwendet, um den Hostnamen in www.citrite.org zu ändern app.cic-citrix.org.
  • Rewrite-Richtlinie 2: Diese Richtlinie wird verwendet, um die URL /something/simple/citrix zu ändern /simple/citrix

Sie können die beiden Richtlinien mit dem Attribut goto-priority-expression binden, wie in der folgenden YAML gezeigt:

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

Überprüfung

Sie können überprüfen, ob die folgende Curl-Anforderung http://www.citrite.org/something/simple/citrix in http://app.cic-citrix.org/simple/citrix geändert wurde.

Beispiel: Änderung der angeforderten URL

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

Der geänderte Hostname und die URL für die angeforderte URL sind in der Abbildung wie folgt enthalten:

Curl-Ausgabe

HTTP-Callout

Ein HTTP-Callout ermöglicht es Citrix ADC, im Rahmen der Richtlinienbewertung eine HTTP- oder HTTPS-Anforderung an einen externen Server zu generieren und zu senden und auf der Grundlage der vom externen Server erhaltenen Antwort geeignete Maßnahmen zu ergreifen. Sie können die Rewrite- und Responder-CRD verwenden, um HTTP-Callout-Anforderungen vom Citrix ADC zu initiieren. Weitere Informationen finden Sie in der Dokumentation zu HTTP-Zusatzinformationen.

Verwandte Artikel

Verwenden von Rewrite- und Responder-Richtlinien in Kubernetes