Citrix ADC ingress controller

Kubernetes で書き換えポリシーとレスポンダーポリシーを使用する

Kubernetes 環境で、特定のレイヤー 7 ポリシーをデプロイして、次のようなシナリオを処理します。

  • HTTP トラフィックを特定の URL にリダイレクトする
  • 一連の IP アドレスをブロックして DDoS 攻撃を軽減
  • HTTPS に HTTP をインポーズする

マイクロサービス内に適切なライブラリを追加し、ポリシーを手動で構成する必要があります。代わりに、Ingress Citrix ADC デバイスが提供する書き換え機能とレスポンダー機能を使用して、これらのポリシーを展開できます。

Citrix は、Citrix イングレスコントローラーで使用できる Kubernetes CustomResourceDefinition (CRD)を提供しており、Ingress デバイスとして使用されるCitrix ADCでのこれらのポリシーの構成と展開を自動化できます。

Citrix が提供する Rewrite and Responder CRD は、最前線の Citrix ADC で使用される一連のツールを公開するように設計されています。これらの機能を使用すると、マイクロサービスに代わって HTTP トラフィックに応答するだけでなく、イングレスおよびイーグレス HTTP トラフィックのヘッダーとペイロードを書き換えることができます。

書き換えとレスポンダー CRD を Kubernetes クラスターにデプロイしたら。データセット、PAT セット、および文字列マップを使用して、広範な書き換えポリシーとレスポンダポリシーを定義できます。また、入力デバイスの統計情報の監査ログを有効にすることもできます。Citrix ADCが提供する書き換えおよびレスポンダーポリシー機能について詳しくは、「 書き換えポリシー 」と「 レスポンダーポリシー」を参照してください。

注:

書き換えとレスポンダー CRD は OpenShift ルートではサポートされていません。OpenShift Ingress を使用して、書き換えとレスポンダー CRD を使用できます。

Citrix リライトおよびレスポンダー CRD を展開する

Citrix リライトおよびレスポンダー CRD 展開 YAML ファイル: リライトレスポンダーポリシー deployment.yaml

注:

デプロイメント YAML ファイルは変更しないでください。

次のコマンドを使用して CRD を展開します。

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

たとえば、

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

書き換えとレスポンダ CRD 属性

CRD には、書き換えポリシーとレスポンダーポリシーの定義に必要なさまざまなオプションの属性が用意されています。また、書き換えポリシーとレスポンダーポリシー内で使用するデータセット、PAT セット、文字列マップ、および監査ログの属性も提供します。これらのCRD属性は、 それぞれCitrix ADCコマンドと属性に対応しています

書き換えポリシー

次の表に、書き換えポリシーの定義に使用できる CRD 属性を示します。また、この表には、対応するCitrix ADCコマンドと属性もリストされています。

CRD 属性 Citrix ADC コマンド Citrix ADC 属性
rewrite-criteria 書き換えポリシーを追加する rule
default-action 書き換えポリシーを追加する undefAction
operation 書き換えアクションを追加 type
target 書き換えアクションを追加 target
modify-expression 書き換えアクションを追加 stringBuilderExpr
multiple-occurence-modify 書き換えアクションを追加 検索
additional-multiple-occurence-modify 書き換えアクションを追加 RefineSearch
Direction Bind lb vserver 種類

Responder policy

次の表に、レスポンダーポリシーの定義に使用できる CRD 属性を示します。また、この表には、対応するCitrix ADCコマンドと属性もリストされています。

CRD 属性 Citrix ADC コマンド Citrix ADC 属性
リダイレクト 応答側アクションの追加 Type (型の値)
url 応答側アクションの追加 ターゲット
redirect-status-code 応答側アクションの追加 responseStatusCode
redirect-reason 応答側アクションの追加 reasonPhrase
Respond-with 応答側アクションの追加 Type (型の値)
http-payload-string 応答側アクションの追加 ターゲット
Noop レスポンダーポリシーの追加 アクション (アクションの価値)
リセット レスポンダーポリシーの追加 アクション (アクションの価値)
Drop レスポンダーポリシーの追加 アクション (アクションの価値)
Respond-criteria レスポンダーポリシーの追加 規則
Default-action レスポンダーポリシーの追加 undefAction

監査ログ

次の表に、書き換えポリシーまたはレスポンダーポリシー内で監査ログを有効にするために提供される CRD 属性を示します。また、この表には、対応するCitrix ADCコマンドと属性もリストされています。

CRD 属性 Citrix ADC コマンド Citrix ADC 属性
対数式 監査メッセージアクションを追加 stringBuilderExpr
ログレベル 監査メッセージアクションを追加 ログレベル

データセット

次の表に、書き換えポリシーまたはレスポンダーポリシー内で使用できるデータセットの CRD 属性を示します。また、この表には、対応するCitrix ADCコマンドと属性もリストされています。

CRD 属性 Citrix ADC コマンド Citrix ADC 属性
名前 ポリシーデータセットの追加 名前
種類 ポリシーデータセットの追加 種類
バインドポリシーデータセット

Patset

CRD 属性 Citrix ADC コマンド Citrix ADC 属性
名前 ポリシーパットセットの追加 名前
バインドポリシー patset string

文字列マップ

CRD 属性 Citrix ADC コマンド Citrix ADC 属性
名前 ポリシーストリングマップを追加する 名前
キー バインドポリシー stringmap キー
バインドポリシー stringmap

優先度式に移行

次の表に、複数の連続するポリシーのグループをサービスにバインドするための CRD 属性であるgoto-priority-expression属性に関する情報を示します。

CRD 属性 Citrix ADC コマンド Citrix ADC 属性 サポートされる値 デフォルト値
goto-priroty-expression Bind lb vserver gotoPriorityExpression NEXTとEND End

goto-priority-expression 属性の使用方法の詳細については、 リクエストされた URL の文字列とホスト名を変更する例を参照してください

ポリシー設定の書き方

Citrix が提供する CRD を Kubernetes クラスターに展開したら、.yaml ファイルでポリシー構成を定義できます。.yamlファイルで、kindフィールドでrewritepolicyを使用し、要件に応じて、ポリシー設定用にspecの次の各セクションのいずれかを追加します。

  • rewrite-policy -書き換えポリシーの設定を定義します。
  • responder-policy -レスポンダーポリシーの設定を定義します。
  • logpackets -監査ログを有効にする。
  • dataset -データセットを広範なポリシー設定に使用する。
  • patset -広範なポリシー設定に PAT セットを使用する。
  • stringmaps -広範なポリシー設定にストリングマップを使用する。

これらのセクションでは、各ポリシー設定(書き換えまたはレスポンダ)に用意されている CRD 属性を使用して 、ポリシーを定義する必要があります。

また、 spec セクションには、ポリシーを適用する必要がある 1つまたは複数のサービスを指定するrewrite-policiesセクションを含める必要があります。詳しくは、「 ポリシー設定の例」を参照してください。

.yamlファイルを展開すると、Citrix イングレスコントローラーは Ingress Citrix ADC デバイスにポリシー構成を適用します。

ポリシー設定のガイドライン

  • CRD が名前空間に関連付けられている場合 、デフォルトでは、その名前空間に関連付けられたサービスにポリシーが適用されます。たとえば、同じサービス名が複数の名前空間に関連付けられている場合、CRD に関連付けられた名前空間に属するサービスにポリシーが適用されます。

  • 1つの.yamlファイルに複数のポリシーを定義した場合は、そのファイルに定義されている最初のポリシー設定が優先され、後続のポリシー設定が順序に従って適用されます。異なるファイルに複数のポリシーが定義されている場合は、最初に展開したファイルで定義されている最初のポリシー設定が優先されます。

goto-priority 式の使用に関するガイドライン

  • goto-priority-expressionフィールド内のNEXTキーワードを使用すると、書き換えポリシーとレスポンダーポリシーを複数のグループとして組み合わせることができます。

  • goto-priority-expressionフィールドが現在のポリシー内のNEXTで、現在のポリシーがTrueと評価されると 、グループ内の次のポリシーが実行され、 goto-priority-expressionフィールドがENDを指していない限り、フローは次の連続するポリシーに移動します 。

  • 現在のポリシーがFALSEと評価されると 、 ポリシーの実行は現在のポリシーで停止するため、goto-priority-expressionは影響を与えません。

  • 書き換えポリシーまたはレスポンダーポリシー内の書き換えポリシーグループまたはレスポンダーポリシーグループは、goto-priority-expressionがNEXTとして割り当てられたポリシーから始まり、goto-priority-expressionフィールドがENDに割り当てられるまで、すべての連続するポリシーが含まれます 。

  • goto-priority-expressionを使用して書き換えポリシーまたはレスポンダーポリシーをグループ化する場合、グループ内のポリシーにバインドされたサービス名は同じである必要があります。

  • 書き換えポリシーまたはレスポンダポリシー内の最後のポリシーには、常にgoto-priority-expressionENDとして指定する必要があります。

  • ポリシーに対してgoto-priority-expressionフィールドが指定されていない場合は、デフォルト値の END がgoto-priority-expressionに割り当てられます。

注:

goto-priority-expression フィールドの使用方法の詳細については、 リクエストされた URL の文字列とホスト名を変更する例を参照してください

書き換えポリシーとレスポンダーポリシーを作成して検証する

すべての受信URLをnew-url-for-the-applicationに書き換えてマイクロサービスに送信するポリシーをCitrix ADCで定義するシナリオを考えてみましょう。target-url-rewrite.yamlという.yamlファイルを作成し、適切な CRD 属性を使用して 、次のように書き換えポリシーを定義します。

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

ポリシー設定を定義したら、以下のコマンドを使用して.yamlファイルを展開します。

kubectl create -f target-url-rewrite.yaml

.yaml ファイルを展開すると、Citrix イングレスコントローラーは Ingress Citrix ADC デバイスにポリシー構成を適用します。

Kubernetes クラスターのマスターノードでは、以下のコマンドを使用して、適用された書き換えポリシー CRD のステータスを確認できます。

Kubectl get rewritepolicies.citrix.com targeturlrewrite

ステータスは次のように表示できます。

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

CRD の作成または適用中に問題が発生した場合は、citrix-k8s-Ingress-Controller ログを使用して同じ問題をデバッグできます。

kubectl logs citrixingresscontroller

また、次の手順を使用して、構成がCitrix ADCに適用されているかどうかを確認できます。

  1. Citrix ADC コマンドラインにログオンします。
  2. 次のコマンドを使用して、構成が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 
    

    ポリシーk8s_crd_rewritepolicy_rwpolicy_targeturlrewrite_0_defaultが負荷分散仮想サーバーにバインドされていることを確認できます。

ポリシー設定の例

レスポンダーポリシー構成

レスポンダーポリシーの設定例を次に示します (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-->

この例では、patsetで定義されている/app1/app2または/app3の文字列に一致するURLをCitrix ADCが受信すると 、Citrix ADCはそのURLをブロックします。

監査ログが有効なポリシー

監査ログを有効にしたサンプルポリシーを次に示します (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-->

複数のポリシー設定

複数のポリシー構成を1つの.yamlファイルに追加し、そのポリシーをCitrix ADCデバイスに適用できます。ポリシー設定 (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-->

この例には、2つのレスポンダーポリシーと1つの書き換えポリシーが含まれています。これらのポリシーに基づいて、Citrix ADCデバイスは次のことを実行します。

  • redirectIP データセットに定義されている IP アドレスに対するクライアントリクエスト、つまり、 それぞれ1.1.1.1または2.2.2.2www.citrix.comにリダイレクトされます 。

  • modifyurls stringmap で指定された文字列を含むすべての受信 URL は、stringmap で指定された値に変更されます。たとえば、着信 URL に次の文字列がある場合、 /app1/ は次のように変更されます。 /internal-app1/

  • クライアントへのレスポンスに、セッション ID を新しいヘッダーとして追加します。

ユースケースの例

レスポンスヘッダーの追加

クライアントから要求された URL に/citrix-app/が含まれている場合 、書き換えポリシーを使用して、マイクロサービスからクライアントへの HTTP 応答に次のヘッダーを追加できます。

  • クライアントの送信元ポートからヘッダーへ
  • サーバの宛先 IP アドレス
  • random HTTP header

次の書き換えポリシー定義の例は、マイクロサービスからクライアントへの HTTP 応答にこれらのヘッダーを追加します。

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

書き換えポリシー定義を含む YAML ファイル (add_response_headers.yaml) を作成し、次のコマンドを使用して YAML ファイルをデプロイします。

kubectl create -f add_response_headers.yaml

レスポンスに追加された HTTP ヘッダーは、次のようにして確認できます。

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

HTTP 応答パケットにカスタムヘッダーを追加する

書き換えポリシーを使用すると、マイクロサービスからクライアントへの HTTP 応答にカスタムヘッダーを追加できます。

次の書き換えポリシー定義の例では、マイクロサービスからクライアントへの HTTP 応答にカスタムヘッダーを追加します。

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

書き換えポリシー定義を含む YAML ファイル (add_custom_headers.yaml) を作成し、次のコマンドを使用して YAML ファイルをデプロイします。

kubectl create -f add_custom_headers.yaml

レスポンスに追加されたカスタム HTTP ヘッダーは、次のようにして確認できます。

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

リクエスト内のホスト名を置換する

次の YAML (http_request_modify_prefixasprefix.yaml) の例に示すように書き換えポリシーを定義し、要件に応じて HTTP リクエスト内のホスト名を置き換えることができます。

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

書き換えポリシー定義を含む YAML ファイル (http_request_modify_prefixasprefix.yaml) を作成し、次のコマンドを使用して YAML ファイルをデプロイします。

kubectl create -f http_request_modify_prefixasprefix.yaml

ポリシー定義は、 curl コマンドを使用して確認できます。リクエスト内のホスト名は、定義済みのホスト名に置き換えられます。

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

出力: ホスト名を置換

アプリケーションルートの変更

既存のアプリケーションルートが/である場合は、書き換えポリシーを定義してアプリケーションルートを変更できます。

次のサンプル書き換えポリシーは、リクエスト URL で//citrix-approot/に変更します。

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

書き換えポリシー定義を含む YAML ファイル (http_approot_request_modify.yaml) を作成し、次のコマンドを使用して YAML ファイルをデプロイします。

kubectl create -f http_approot_request_modify.yaml

curl コマンドを使用すると、アプリケーションルートが要件に従って変更されているかどうかを確認できます。

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

出力:

app-root の変更

要求された URL の文字列を変更します

書き換えポリシーを定義して、要求された URL の文字列を要件に応じて変更できます。

次の書き換えポリシーの例では、要求されたURLの文字列somethingsimpleに置き換えます。

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

書き換えポリシー定義を含む YAML ファイル (http_url_replace_string.yaml) を作成し、次のコマンドを使用して YAML をデプロイします。

kubectl create -f http_url_replace_string.yaml

ポリシー定義を検証するには、somethingという文字列を含むcurlリクエストを使用します 。文字列somethingは、 次の例に示すように文字列simpleに置き換えられます。

例 1:

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

出力:

文字列を置換

例 2:

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

または

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

出力:

文字列を置換

HTTP リクエスト内にX-Forwarded-Forヘッダーを追加する

次の YAML (http_x_forwarded_for_insert.yaml) の例に示すように、書き換えポリシーを定義して HTTP X-Forwarded-For リクエスト内にヘッダーを追加できます。

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

書き換えポリシー定義を含む YAML ファイル (http_x_forwarded_for_insert.yaml) を作成し、次のコマンドを使用して YAML ファイルをデプロイします。

kubectl create -f http_x_forwarded_for_insert.yaml

curlコマンドを使用すると、 X-Forwarded-For ヘッダーの有無にかかわらず HTTP パケットを検証できます。

例: X-Forwarded-For ヘッダーなしの HTTP 要求パケットの出力:

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

出力:

Curl-output

例: X-Forwarded-For ヘッダー付きの HTTP 要求パケットの出力

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

出力:

カール出力

レスポンダーポリシーを使用して HTTP リクエストを HTTPS リクエストにリダイレクトする

次の YAML (http_to_https_redirect.yaml) の例に示すように、レスポンダーポリシー定義を定義して HTTP リクエストを 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-->

レスポンダーポリシー定義を含む YAML ファイル (http_to_https_redirect.yaml) を作成し、次のコマンドを使用して YAML ファイルをデプロイします。

kubectl create -f http_to_https_redirect.yaml

HTTP リクエストが HTTPS にリダイレクトされるかどうかは、次のようにして確認できます。

例 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

例 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

要求された URL の文字列とホスト名を変更する

この例は、 goto-priority-expression 属性の使用方法を示しています。goto-priority-expressionフィールドの使用に関するガイドラインは、[ポリシー設定の書き方] にあります。この例では、URLhttp://www.citrite.org/something/simple/citrixhttp://app.cic-citrix.org/simple/citrixに変更します。

URL を変更するために、次の 2 つの書き換えポリシーが記述されています。

  • 書き換えポリシー 1: このポリシーは、ホスト名www.citrite.orgapp.cic-citrix.orgに変更するために使用されます。
  • 書き換えポリシー 2: このポリシーは、URL /something/simple/citrix/simple/citrixに変更します。

次の YAML に示すように、 goto-priority-expression 属性を使用して 2 つのポリシーをバインドできます。

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

確認

次の curl リクエストhttp://www.citrite.org/something/simple/citrixhttp://app.cic-citrix.org/simple/citrixに変更されたかどうかを確認できます。

例:リクエストされた URL の変更

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

要求された URL の変更されたホスト名と URL は、次の図に示されています。

カール出力

HTTP コールアウト

HTTPコールアウトを使用すると、Citrix ADCはポリシー評価の一環としてHTTPまたはHTTPS要求を生成して外部サーバーに送信し、外部サーバーから取得した応答に基づいて適切なアクションを実行できます。リライトおよびレスポンダーCRDを使用して、Citrix ADCからHTTPコールアウト要求を開始できます。詳細については、 HTTP コールアウトのドキュメントを参照してください

関連トピック

Kubernetes で書き換えポリシーとレスポンダーポリシーを使用する