Connectivity Link を使用した Gateway ポリシーの設定およびデプロイ


Red Hat Connectivity Link 1.1

OpenShift での API のセキュリティー、保護、接続

Red Hat Connectivity Link documentation team

概要

このガイドでは、OpenShift 上の Connectivity Link ポリシーを使用して、Kubernetes Gateway API をベースとして Gateway が公開するアプリケーション API を保護および接続する方法を説明します。これには、単一の OpenShift クラスターにデプロイされたゲートウェイと、複数のクラスターに分散された Gateway が含まれます。

はじめに

Red Hat ドキュメントへのフィードバック (英語のみ)

製品ドキュメントに関するご意見をお寄せください。

改善を提案するには、Jira 課題を作成し、変更案を説明してください。ドキュメントチームがご要望に迅速に対応できるよう、できるだけ詳細にご記入ください。

前提条件

  • Red Hat カスタマーポータルのアカウントがある。このアカウントを使用すると、Red Hat Jira Software インスタンスにログインできます。アカウントをお持ちでない場合は、アカウントを作成するように求められます。

手順

  1. Create issue にアクセスします。
  2. Summary テキストボックスに、問題の簡単な説明を入力します。
  3. Description テキストボックスに、次の情報を入力します。

    • 問題が見つかったページの URL。
    • 問題の詳細情報。他のフィールドは、そのままデフォルト値にできます。
  4. Reporter フィールドに Jira ユーザー名を入力します。
  5. Create をクリックして、Jira 課題をドキュメントチームに送信します。

フィードバックをご提供いただきありがとうございました。

第1章 Connectivity Link を使用した OpenShift 上の API のセキュリティー、保護、接続

このガイドでは、OpenShift 上の Connectivity Link を使用して、Kubernetes Gateway API を使用するゲートウェイによって公開される API を保護および接続する方法を説明します。このガイドは、Connectivity Link のプラットフォームエンジニアおよびアプリケーション開発者のユーザーロールを対象とします。

注記

マルチクラスター環境では、特に除外されていない限り、クラスターごとに次のステップを個別に実行する必要があります。

このガイドには次のセクションが含まれています。

注記

第 2 章から第 7 章の手順は、通常、プラットフォームエンジニアユーザーロールによって実行されます。第 8 章の手順は、通常、アプリケーション開発者ユーザーロールによって実行されます。

1.3. デプロイメント管理ツール

このガイドの例では、kubectl コマンドを使用して簡素化します。ただし、複数のクラスターの操作は複雑であるため、複数のクラスターへのリソースのデプロイメントを管理するには、Argo CD に基づく OpenShift GitOps などのツールを使用するのが最適です。

第2章 Connectivity Link のインストールと権限を確認する

このガイドでは、1 つ以上の OpenShift クラスターに Connectivity Link が正常にインストールされ、適切なユーザー権限があることを想定しています。

前提条件

  • OpenShift への Connectivity Link のインストール の説明に従って、1 つ以上のクラスターで Connectivity Link のインストール手順を完了している。
  • kubectl または oc コマンドがインストールされている。
  • このガイドで使用する OpenShift namespace への書き込み権限がある。
  • このガイドのサンプル用に、Amazon Route 53 と DNS ゾーンを備えた AWS アカウントがある。Connectivity Link は、Google Cloud DNS と Microsoft Azure DNS もサポートしている。
  • オプション:

    • マルチクラスター環境での流量制御のために、複数のクラスターに Connectivity Link をインストールし、アクセス可能な Redis ベースのデータストアを共有している。詳細は、OpenShift への Connectivity Link のインストール を参照してください。
    • Observability の場合、Connectivity Link 可観測性ガイド で説明されているように、Thanos などの中央ストレージシステムにリモート書き込みするように、OpenShift ユーザーワークロードの監視を設定する必要があります。

第3章 環境を設定する

このセクションでは、環境変数を設定し、OpenShift クラスターにサンプルの Toystore アプリケーションをデプロイする方法を説明します。

手順

  1. 次の環境変数 (便宜上使用する変数) を設定します。

    export KUADRANT_GATEWAY_NS=api-gateway
    export KUADRANT_GATEWAY_NAME=external
    export KUADRANT_DEVELOPER_NS=toystore
    export KUADRANT_AWS_ACCESS_KEY_ID=xxxx
    export KUADRANT_AWS_SECRET_ACCESS_KEY=xxxx
    export KUADRANT_AWS_DNS_PUBLIC_ZONE_ID=xxxx
    export KUADRANT_ZONE_ROOT_DOMAIN=example.com
    export KUADRANT_CLUSTER_ISSUER_NAME=self-signed
    Copy to Clipboard Toggle word wrap

    これらの環境変数の詳細は、以下のとおりです。

    • KUADRANT_GATEWAY_NS: OpenShift のサンプルゲートウェイの namespace。
    • KUADRANT_GATEWAY_NAME: OpenShift のサンプルゲートウェイの名前。
    • KUADRANT_DEVELOPER_NS: OpenShift のサンプルの Toystore アプリケーションの namespace。
    • KUADRANT_AWS_ACCESS_KEY_ID: DNS ゾーン管理向けのアクセス権を持つ AWS キー ID。
    • KUADRANT_AWS_SECRET_ACCESS_KEY: DNS ゾーンを管理する権限を持つ AWS シークレットアクセスキー。
    • KUADRANT_AWS_DNS_PUBLIC_ZONE_ID: ゲートウェイの AWS Route 53 ゾーン ID。これは、AWS Route 53 コンソールに表示されるホストゾーンの ID です。
    • KUADRANT_ZONE_ROOT_DOMAIN: DNS ゾーン ID に関連付けられた AWS Route 53 のルートドメイン。
    • KUADRANT_CLUSTER_ISSUER_NAME: 認証局または発行者の TLS 証明書の名前。

      注記

      便宜上、このガイドでは環境変数を使用します。または、環境変数の値がわかっている場合は、環境に合わせて必要な .yaml ファイルを設定できます。

  2. 次のようにして、Toystore アプリケーションの namespace を作成します。

    kubectl create ns ${KUADRANT_DEVELOPER_NS}
    Copy to Clipboard Toggle word wrap
  3. Toystore アプリケーションを開発者 namespace にデプロイします。

    kubectl apply -f https://raw.githubusercontent.com/Kuadrant/Kuadrant-operator/main/examples/toystore/toystore.yaml -n ${KUADRANT_DEVELOPER_NS}
    Copy to Clipboard Toggle word wrap

第4章 DNS プロバイダーシークレットを設定する

DNS プロバイダーは、Connectivity Link が DNS 構成設定に使用できる DNS ゾーンにアクセスする認証情報を提供します。これらの認証情報が、Connectivity Link が DNSPolicy を使用して管理する DNS ゾーンにのみアクセスできるようにする必要があります。

注記

各クラスターに次の Secret リソースを適用する必要があります。クラスターを追加する場合は、新しいクラスターに追加します。

前提条件

手順

  1. 次のように、ゲートウェイがデプロイされる namespace を作成します。

    kubectl create ns ${KUADRANT_GATEWAY_NS}
    Copy to Clipboard Toggle word wrap
  2. 次のように、ゲートウェイと同じ namespace にシークレット認証情報を作成します。

    kubectl -n ${KUADRANT_GATEWAY_NS} create secret generic aws-credentials \
      --type=kuadrant.io/aws \
      --from-literal=AWS_ACCESS_KEY_ID=$KUADRANT_AWS_ACCESS_KEY_ID \
      --from-literal=AWS_SECRET_ACCESS_KEY=$KUADRANT_AWS_SECRET_ACCESS_KEY
    Copy to Clipboard Toggle word wrap
  3. TLS 証明書の発行者を追加する前に、次のように cert-manager namespace にシークレットの認証情報を作成します。

    kubectl -n cert-manager create secret generic aws-credentials \
      --type=kuadrant.io/aws \
      --from-literal=AWS_ACCESS_KEY_ID=$KUADRANT_AWS_ACCESS_KEY_ID \
      --from-literal=AWS_SECRET_ACCESS_KEY=$KUADRANT_AWS_SECRET_ACCESS_KEY
    Copy to Clipboard Toggle word wrap

第5章 TLS 証明書発行者を追加する

ゲートウェイへの通信をセキュリティーで保護するには、TLS 証明書の発行者として認証局を定義する必要があります。

注記

この例では、Let’s Encrypt TLS 証明書発行者を使用して簡素化していますが、cert-manager でサポートされている任意の証明書発行者を使用することもできます。マルチクラスター環境では、各 OpenShift クラスターに TLS 発行者を追加する必要があります。

前提条件

手順

  1. TLS 証明書の発行者を定義するには、次のコマンドを入力します。

    kubectl apply -f - <<EOF
    apiVersion: cert-manager.io/v1
    kind: ClusterIssuer
    metadata:
      name: ${KUADRANT_CLUSTER_ISSUER_NAME}
    spec:
      selfSigned: {}
    EOF
    Copy to Clipboard Toggle word wrap
  2. ClusterIssuer の準備が完了するまで待ちます。

    kubectl wait clusterissuer/${KUADRANT_CLUSTER_ISSUER_NAME} --for=condition=ready=true
    Copy to Clipboard Toggle word wrap

第6章 ゲートウェイインスタンスを作成する

このセクションでは、OpenShift クラスターにゲートウェイをデプロイする方法を説明します。このタスクは通常、アプリケーション開発者が使用するインフラストラクチャーをセットアップするときにプラットフォームエンジニアによって実行されます。

注記

マルチクラスター環境では、Connectivity Link がクラスター間で DNS を使用してトラフィックを分散させるには、共有ホスト名を持つゲートウェイを定義する必要があります。これは、root ドメインに基づき、ワイルドカードホスト名で HTTPS リスナーを使用して定義できます。前述のように、これらのリソースをすべてのクラスターに適用する必要があります。

前提条件

手順

  1. 以下のコマンドを入力してゲートウェイを作成します。

    kubectl apply -f - <<EOF
    apiVersion: gateway.networking.k8s.io/v1
    kind: Gateway
    metadata:
      name: ${KUADRANT_GATEWAY_NAME}
      namespace: ${KUADRANT_GATEWAY_NS}
      labels:
        kuadrant.io/gateway: "true"
    spec:
        gatewayClassName: istio
        listeners:
        - allowedRoutes:
            namespaces:
              from: All
          hostname: "api.${KUADRANT_ZONE_ROOT_DOMAIN}"
          name: api
          port: 443
          protocol: HTTPS
          tls:
            certificateRefs:
            - group: ""
              kind: Secret
              name: api-${KUADRANT_GATEWAY_NAME}-tls
            mode: Terminate
    EOF
    Copy to Clipboard Toggle word wrap
  2. 次のとおり、ゲートウェイのステータスを確認します。

    kubectl get gateway ${KUADRANT_GATEWAY_NAME} -n ${KUADRANT_GATEWAY_NS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}{"\n"}{.status.conditions[?(@.type=="Programmed")].message}'
    Copy to Clipboard Toggle word wrap

    ゲートウェイは Accepted および Programmed である必要があります。これは、ゲートウェイが有効であり、外部アドレスが割り当てられたことを意味します。

  3. 次のようにして、HTTPS リスナーのステータスを確認します。

    kubectl get gateway ${KUADRANT_GATEWAY_NAME} -n ${KUADRANT_GATEWAY_NS} -o=jsonpath='{.status.listeners[0].conditions[?(@.type=="Programmed")].message}'
    Copy to Clipboard Toggle word wrap

    TLS 設定が不適切なため、HTTPS リスナーがまだプログラムされていないか、トラフィックを受け入れる準備ができていないことがわかります。このような場合も、Connectivity Link は TLSPolicy を使用して有効な手段を提供できます。この点は、次のステップで説明しています。

第7章 ゲートウェイポリシーと HTTP ルートを設定する

この時点で、ゲートウェイのデプロイは完了していますが、エンドポイントは公開されておらず、HTTPS リスナーはプログラムされていません。次に、CertificateIssuer を活用して HTTPS リスナー証明書を設定する TLSPolicy を定義し、バックエンドアプリケーション API と通信するためのゲートウェイの HTTPRoute を定義できます。

保護されていないエンドポイントに対してデフォルトの HTTP 403 応答を設定する AuthPolicy と、ゲートウェイによって公開されるエンドポイントをさらに保護するためにデフォルトで人為的に低いグローバル制限を設定する RateLimitPolicy を定義します。また、ゲートウェイの負荷分散ストラテジーを使用して DNSPolicy を定義します。

前提条件

注記

マルチクラスター環境では、特に除外されていない限り、クラスターごとに次のステップを個別に実行する必要があります。

7.1. TLS ポリシーの設定

手順

  1. 次のとおり、ゲートウェイの TLSPolicy を設定します。

    kubectl apply -f - <<EOF
    apiVersion: kuadrant.io/v1
    kind: TLSPolicy
    metadata:
      name: ${KUADRANT_GATEWAY_NAME}-tls
      namespace: ${KUADRANT_GATEWAY_NS}
    spec:
      targetRef:
        name: ${KUADRANT_GATEWAY_NAME}
        group: gateway.networking.k8s.io
        kind: Gateway
      issuerRef:
        group: cert-manager.io
        kind: ClusterIssuer
        name: ${KUADRANT_CLUSTER_ISSUER_NAME}
    EOF
    Copy to Clipboard Toggle word wrap
  2. 次のように、TLS ポリシーのステータスが Accepted and Enforced であることを確認します。

    kubectl get tlspolicy ${KUADRANT_GATEWAY_NAME}-tls -n ${KUADRANT_GATEWAY_NS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}{"\n"}{.status.conditions[?(@.type=="Enforced")].message}'
    Copy to Clipboard Toggle word wrap

    TLS プロバイダー (例: Let’s Encrypt) によっては、数分かかる場合があります。

7.2. アプリケーションの HTTP ルートを作成する

手順

  1. 次のようにして、サンプル Toystore アプリケーションの HTTPRoute を作成します。

    kubectl apply -f - <<EOF
    apiVersion: gateway.networking.k8s.io/v1
    kind: HTTPRoute
    metadata:
      name: toystore
      namespace: ${KUADRANT_DEVELOPER_NS}
      labels:
        deployment: toystore
        service: toystore
    spec:
      parentRefs:
      - name: ${KUADRANT_GATEWAY_NAME}
        namespace: ${KUADRANT_GATEWAY_NS}
      hostnames:
      - "api.${KUADRANT_ZONE_ROOT_DOMAIN}"
      rules:
      - matches:
        - method: GET
          path:
            type: PathPrefix
            value: "/cars"
        - method: GET
          path:
            type: PathPrefix
            value: "/health"
        backendRefs:
        - name: toystore
          port: 80
    EOF
    Copy to Clipboard Toggle word wrap

    ゲートウェイはデプロイされていますが、エンドポイントは現在公開されています。次の手順では、保護されていないエンドポイントに対してデフォルトの HTTP 403 応答を設定する AuthPolicy を定義し、公開されているエンドポイントをさらに保護するために、デフォルトで極めて低いグローバル制限を設定する RateLimitPolicy を定義します。

7.3. デフォルトの AuthPolicy を設定する

手順

  1. 次のように、ゲートウェイに対して deny-all 設定のデフォルトの AuthPolicy を設定します。

    kubectl apply -f - <<EOF
    apiVersion: kuadrant.io/v1
    kind: AuthPolicy
    metadata:
      name: ${KUADRANT_GATEWAY_NAME}-auth
      namespace: ${KUADRANT_GATEWAY_NS}
    spec:
      targetRef:
        group: gateway.networking.k8s.io
        kind: Gateway
        name: ${KUADRANT_GATEWAY_NAME}
      defaults:
       when:
         - predicate: "request.path != '/health'"
       rules:
        authorization:
          deny-all:
            opa:
              rego: "allow = false"
        response:
          unauthorized:
            headers:
              "content-type":
                value: application/json
            body:
              value: |
                {
                  "error": "Forbidden",
                  "message": "Access denied by default by the gateway operator. If you are the administrator of the service, create a specific auth policy for the route."
                }
    EOF
    Copy to Clipboard Toggle word wrap
  2. 次のように、AuthPolicy のステータスが Accepted かつ Enforced になっていることを確認します。

    kubectl get authpolicy ${KUADRANT_GATEWAY_NAME}-auth -n ${KUADRANT_GATEWAY_NS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}{"\n"}{.status.conditions[?(@.type=="Enforced")].message}'
    Copy to Clipboard Toggle word wrap

7.4. デフォルトの RateLimitPolicy を設定する

手順

  1. 次のように、ゲートウェイの low-limit 設定でデフォルトの RateLimitPolicy を設定します。

    kubectl apply -f  - <<EOF
    apiVersion: kuadrant.io/v1
    kind: RateLimitPolicy
    metadata:
      name: ${KUADRANT_GATEWAY_NAME}-rlp
      namespace: ${KUADRANT_GATEWAY_NS}
    spec:
      targetRef:
        group: gateway.networking.k8s.io
        kind: Gateway
        name: ${KUADRANT_GATEWAY_NAME}
      defaults:
        limits:
          "low-limit":
            rates:
            - limit: 1
              window: 10s
    EOF
    Copy to Clipboard Toggle word wrap
    注記

    クラスターによっては、RateLimitPolicy が適用されるまでに数分間がかかる場合があります。この例では、制限が機能していることを示すために意図的に低く設定されています。

  2. 次のように、RateLimitPolicy のステータスが Accepted および Enforced になっていることを確認します。

    kubectl get ratelimitpolicy ${KUADRANT_GATEWAY_NAME}-rlp -n ${KUADRANT_GATEWAY_NS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}{"\n"}{.status.conditions[?(@.type=="Enforced")].message}'
    Copy to Clipboard Toggle word wrap

7.5. DNS ポリシーの設定

手順

  1. 次のとおり、ゲートウェイの DNSPolicy を設定します。

    kubectl apply -f - <<EOF
    apiVersion: kuadrant.io/v1
    kind: DNSPolicy
    metadata:
      name: ${KUADRANT_GATEWAY_NAME}-dnspolicy
      namespace: ${KUADRANT_GATEWAY_NS}
    spec:
      healthCheck:
        failureThreshold: 3
        interval: 1m
        path: /health
      loadBalancing:
        defaultGeo: true
        geo: GEO-NA
        weight: 120
      targetRef:
        name: ${KUADRANT_GATEWAY_NAME}
        group: gateway.networking.k8s.io
        kind: Gateway
      providerRefs:
      - name: aws-credentials # Secret created earlier
    EOF
    Copy to Clipboard Toggle word wrap
    注記

    DNSPolicy は、これまでの手順で定義した DNS プロバイダー Secret を使用します。この例の geoGEO-NA ですが、要件に合わせて変更できます。

  2. 次のように、DNSPolicy のステータスが Accepted および Enforced になっていることを確認します。

    kubectl get dnspolicy ${KUADRANT_GATEWAY_NAME}-dnspolicy -n ${KUADRANT_GATEWAY_NS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}{"\n"}{.status.conditions[?(@.type=="Enforced")].message}'
    Copy to Clipboard Toggle word wrap

    これには数分かかる場合があります。

  3. 次のように、DNSPolicy で有効になっている DNS ヘルスチェックのステータスを確認します。

    kubectl get dnspolicy ${KUADRANT_GATEWAY_NAME}-dnspolicy -n ${KUADRANT_GATEWAY_NS} -
    Copy to Clipboard Toggle word wrap

    これらのヘルスチェックは、定義された設定に基づいて、公開されたエンドポイントを正常または異常としてフラグ付けします。正常でない場合、エンドポイントは DNS プロバイダーにまだ公開されていない場合は公開されません。エンドポイントは、複数値の A レコードの一部である場合にのみ非公開となり、いずれの場合も DNSPolicy ステータスで確認できます。

7.6. デフォルトの流量制御と認証ポリシーをテストする

curl コマンドを使用して、ゲートウェイのデフォルトの low-limit および deny-all ポリシーをテストできます。

手順

  • 次の curl コマンドを入力します。

    while :; do curl -k --write-out '%{http_code}\n' --silent --output /dev/null  "https://api.$KUADRANT_ZONE_ROOT_DOMAIN/cars" | grep -E --color "\b(429)\b|$"; sleep 1; done
    Copy to Clipboard Toggle word wrap

    HTTP 403 応答が表示されます。

第8章 認証と流量制御のゲートウェイポリシーをオーバーライドする

アプリケーション開発者は、既存のゲートウェイレベルのポリシーをオーバーライドして、アプリケーションレベルの認証と流量制御の要件を設定できます。

前提条件

8.1. ゲートウェイの deny-all AuthPolicy を上書きする

前のセクションで作成した HTTPRoute リソースを対象とする新しい AuthPolicy を定義することで、Toystore API への認証済みアクセスを許可できます。

注記

新しい HTTPRoutes は、ゲートウェイレベルの既存ポリシーの影響を受けます。ユーザーがこの API にアクセスできるようにするためには、該当するゲートウェイポリシーをオーバーライドする必要があります。シンプルに API キーを使用してリクエストを認証できますが、OpenID Connect などの他のオプションも利用できます。

手順

  1. Connectivity Link システムの namespace が次のように正しく設定されていることを確認します。

    export KUADRANT_SYSTEM_NS=$(kubectl get kuadrant -A -o jsonpath="{.items[0].metadata.namespace}")
    Copy to Clipboard Toggle word wrap
  2. 次のとおり、ユーザーである bob および alice の API キーを定義します。

    kubectl apply -f - <<EOF
    apiVersion: v1
    kind: Secret
    metadata:
      name: bob-key
      namespace: ${KUADRANT_SYSTEM_NS}
      labels:
        authorino.kuadrant.io/managed-by: authorino
        app: toystore
      annotations:
        secret.kuadrant.io/user-id: bob
    stringData:
      api_key: IAMBOB
    type: Opaque
    ---
    apiVersion: v1
    kind: Secret
    metadata:
      name: alice-key
      namespace: ${KUADRANT_SYSTEM_NS}
      labels:
        authorino.kuadrant.io/managed-by: authorino
        app: toystore
      annotations:
        secret.kuadrant.io/user-id: alice
    stringData:
      api_key: IAMALICE
    type: Opaque
    EOF
    Copy to Clipboard Toggle word wrap
  3. 先ほど作成した deny-all ポリシーをオーバーライドし、次のように API キーを受け入れる新しい AuthPolicy を別の namespace に作成します。

    kubectl apply -f - <<EOF
    apiVersion: kuadrant.io/v1
    kind: AuthPolicy
    metadata:
      name: toystore-auth
      namespace: ${KUADRANT_DEVELOPER_NS}
    spec:
      targetRef:
        group: gateway.networking.k8s.io
        kind: HTTPRoute
        name: toystore
      defaults:
       when:
         - predicate: "request.path != '/health'"
       rules:
        authentication:
          "api-key-users":
            apiKey:
              selector:
                matchLabels:
                  app: toystore
            credentials:
              authorizationHeader:
                prefix: APIKEY
        response:
          success:
            filters:
              "identity":
                json:
                  properties:
                    "userid":
                      selector: auth.identity.metadata.annotations.secret\.kuadrant\.io/user-id
    EOF
    Copy to Clipboard Toggle word wrap

8.2. 特定のユーザーに対してゲートウェイの low-limit RateLimitPolicy を上書きする

設定されたゲートウェイ制限は、一般的なケースに適した制限セットとして使用できます。ただし、Toystore API の開発者は、特定ユーザーのリクエストには具体的な数の制限を、その他のユーザーに対しては汎用の制限を適用することが必要になる場合もあります。

手順

  1. 別の名前空間に新しい RateLimitPolicy を作成し、以前に作成したデフォルトの low-limit ポリシーを上書きして、次のように特定のユーザーの流量制御を設定します。

    kubectl apply -f - <<EOF
    apiVersion: kuadrant.io/v1
    kind: RateLimitPolicy
    metadata:
      name: toystore-rlp
      namespace: ${KUADRANT_DEVELOPER_NS}
    spec:
      targetRef:
        group: gateway.networking.k8s.io
        kind: HTTPRoute
        name: toystore
      limits:
        "general-user":
          rates:
    
          - limit: 5
            window: 10s
          counters:
          - expression: auth.identity.userid
          when:
          - predicate: "auth.identity.userid != 'bob'"
        "bob-limit":
          rates:
          - limit: 2
            window: 10s
          when:
          - predicate: "auth.identity.userid == 'bob'"
    EOF
    Copy to Clipboard Toggle word wrap
    注記

    クラスターによっては、RateLimitPolicy が適用されるまでに数分間がかかる場合があります。

  2. 次のように、RateLimitPolicy のステータスが Accepted および Enforced になっていることを確認します。

    kubectl get ratelimitpolicy -n ${KUADRANT_DEVELOPER_NS} toystore-rlp -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}{"\n"}{.status.conditions[?(@.type=="Enforced")].message}'
    Copy to Clipboard Toggle word wrap
  3. HTTPRoute のステータスが同じ namespace 内の RateLimitPolicy の影響を受けるようになったことを確認します。

    kubectl get httproute toystore -n ${KUADRANT_DEVELOPER_NS} -o=jsonpath='{.status.parents[0].conditions[?(@.type=="kuadrant.io/RateLimitPolicyAffected")].message}'
    Copy to Clipboard Toggle word wrap

8.3. 新しい流量制御と認証ポリシーをテストする

  1. 次のようにユーザー alice としてリクエストを送信します。

    while :; do curl -k --write-out '%{http_code}\n' --silent --output /dev/null -H 'Authorization: APIKEY IAMALICE' "https://api.$KUADRANT_ZONE_ROOT_DOMAIN/cars" | grep -E --color "\b(429)\b|$"; sleep 1; done
    Copy to Clipboard Toggle word wrap

    毎秒 HTTP ステータス 200 が 5 秒間、表示され、その後の 5 秒間、毎秒 HTTP ステータス 429 が表示されます。

  2. 次のようにユーザー bob としてリクエストを送信します。

    while :; do curl -k --write-out '%{http_code}\n' --silent --output /dev/null -H 'Authorization: APIKEY IAMBOB' "https://api.$KUADRANT_ZONE_ROOT_DOMAIN/cars" | grep -E --color "\b(429)\b|$"; sleep 1; done
    Copy to Clipboard Toggle word wrap

    毎秒 HTTP ステータス 200 が 2 秒間、表示され、その後 8 秒間、毎秒 HTTP ステータス 429 が表示されます。

付録A Red Hat サブスクリプションの使用

Red Hat Connectivity Link は、ソフトウェアサブスクリプションを通じて提供されます。サブスクリプションを管理するには、Red Hat カスタマーポータルでアカウントにアクセスします。

サブスクリプションの管理

  1. access.redhat.com に移動します。
  2. アカウントがない場合は作成します。
  3. アカウントにログインします。
  4. メニューバーで Subscriptions をクリックし、サブスクリプションを表示および管理します。

改訂日時: 2025-07-11

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat