2.11. 3scale Istio アダプターの使用

警告

こちらは、サポートされなくなった Red Hat OpenShift Service Mesh リリースのドキュメントです。

Service Mesh バージョン 1.0 および 1.1 コントロールプレーンはサポートされなくなりました。Service Mesh コントロールプレーンのアップグレードについては、Service Mesh の アップグレード を参照してください。

特定の Red Hat Service Mesh リリースのサポートステータスは、製品ライフサイクルページ を参照してください。

3scale Istio アダプターはオプションのアダプターであり、これを使用すると、Red Hat OpenShift Service Mesh 内で実行中のサービスにラベルを付け、そのサービスを 3scale API Management ソリューションと統合できます。これは Red Hat OpenShift Service Mesh には必要ありません。

2.11.1. 3scale アダプターと Red Hat OpenShift Service Mesh の統合

これらの例を使用して、3scale Istio アダプターを使用してサービスに対する要求を設定できます。

前提条件:

  • Red Hat OpenShift Service Mesh バージョン 1.x
  • 稼働している 3scale アカウント (SaaS または 3scale 2.5 On-Premises)
  • バックエンドキャッシュを有効にするには 3scale 2.9 以上が必要です。
  • Red Hat OpenShift Service Mesh の前提条件
注記

3scale Istio アダプターを設定するために、アダプターパラメーターをカスタムリソースファイルに追加する手順は、Red Hat OpenShift Service Mesh カスタムリソースを参照してください。

注記

kind: handler リソースにとくに注意してください。これを 3scale アカウントの認証情報を使用して更新する必要があります。オプションで service_id をハンドラーに追加できますが、この設定は 3scale アカウントの 1 つのサービスに対してのみ有効で、後方互換性を確保するためにだけ維持されています。service_id をハンドラーに追加し、他のサービスに対して 3scale を有効にする必要がある場合は、別の service_ids で追加のハンドラーを作成する必要があります。

以下の手順に従って、3scale アカウントごとに単一のハンドラーを使用します。

手順

  1. 3scale アカウントのハンドラーを作成し、アカウントの認証情報を指定します。サービス識別子を省略します。 

      apiVersion: "config.istio.io/v1alpha2"
  kind: handler
  metadata:
   name: threescale
  spec:
   adapter: threescale
   params:
     system_url: "https://<organization>-admin.3scale.net/"
     access_token: "<ACCESS_TOKEN>"
   connection:
     address: "threescale-istio-adapter:3333"

    オプションで、params セクション内の backend_url フィールドを指定して、3scale 設定によって提供される URL を上書きできます。これは、アダプターが 3scale のオンプレミスインスタンスと同じクラスターで実行され、内部クラスター DNS を利用する必要がある場合に役立ちます。

  2. 3scale アカウントに属するサービスの Deployment リソースを編集するか、パッチを適用します。

    1. 有効な service_id に対応する値を使用して "service-mesh.3scale.net/service-id" ラベルを追加します。
    2. 手順 1 の ハンドラーリソースの名前 の値を使用して "service-mesh.3scale.net/credentials" ラベルを追加します。
  3. 他のサービスを追加する場合は、手順 2 を実行して、3scale アカウントの認証情報とそのサービス識別子にリンクします。

  4. 3scale 設定でルールの設定を変更し、ルールを 3scale ハンドラーにディスパッチします。

    ルール設定の例

      apiVersion: "config.istio.io/v1alpha2"
  kind: rule
  metadata:
    name: threescale
  spec:
    match: destination.labels["service-mesh.3scale.net"] == "true"
    actions:
      - handler: threescale.handler
        instances:
          - threescale-authorization.instance

2.11.1.1. 3scale カスタムリソースの生成

アダプターには、handler、instance、および rule カスタムリソースの生成を可能にするツールが含まれます。

表2.16 使用法

オプション説明必須デフォルト値

-h, --help

利用可能なオプションのヘルプ出力を生成します

いいえ

 

--name

この URL の一意の名前、トークンのペア

はい

 

-n, --namespace

テンプレートを生成する namespace

いいえ

istio-system

-t, --token

3scale アクセストークン

はい

 

-u, --url

3scale 管理ポータル URL

はい

 

--backend-url

3scale バックエンド URL。これが設定されている場合は、システム設定から読み込まれる値がオーバーライドされます。

いいえ

 

-s, --service

3scale API/サービス ID

いいえ

 

--auth

指定する 3scale 認証パターン (1=API Key, 2=App Id/App Key, 3=OIDC)

いいえ

ハイブリッド

-o, --output

生成されたマニフェストを保存するファイル

いいえ

標準出力

--version

CLI バージョンを出力し、即座に終了する

いいえ

 
2.11.1.1.1. URL サンプルからのテンプレートの生成
注記
  • デプロイされたアダプターからのマニフェストの生成 で、3scale アダプターコンテナーイメージからの oc exec を使用して以下のコマンドを実行します。
  • 3scale-config-gen コマンドを使用すると、YAML 構文とインデントエラーを回避するのに役立ちます。
  • このアノテーションを使用する場合は --service を省略できます。
  • このコマンドは、oc exec を使用してコンテナーイメージ内から起動する必要があります。

手順

  • 3scale-config-gen コマンドを使用して、トークンと URL のペアを 1 つのハンドラーとして複数のサービスで共有できるようにテンプレートを自動生成します。 

    $ 3scale-config-gen --name=admin-credentials --url="https://<organization>-admin.3scale.net:443" --token="[redacted]"

  • 以下の例では、ハンドラーに埋め込まれたサービス ID を使用してテンプレートを生成します。 

    $ 3scale-config-gen --url="https://<organization>-admin.3scale.net" --name="my-unique-id" --service="123456789" --token="[redacted]"

関連情報

2.11.1.2. デプロイされたアダプターからのマニフェストの生成

注記
  • NAME は、3scale で管理するサービスの識別に使用する識別子です。
  • CREDENTIALS_NAME 参照は、ルール設定の match セクションに対応する識別子です。CLI ツールを使用している場合は、NAME 識別子に自動設定されます。
  • この値は具体的なものでなくても構いませんが、ラベル値はルールの内容と一致させる必要があります。詳細は、アダプター経由でのサービストラフィックのルーティング を参照してください。

  1. このコマンドを実行して、istio-system namespace でデプロイされたアダプターからマニフェストを生成します。 

    $ export NS="istio-system" URL="https://replaceme-admin.3scale.net:443" NAME="name" TOKEN="token"
oc exec -n ${NS} $(oc get po -n ${NS} -o jsonpath='{.items[?(@.metadata.labels.app=="3scale-istio-adapter")].metadata.name}') \
-it -- ./3scale-config-gen \
--url ${URL} --name ${NAME} --token ${TOKEN} -n ${NS}
  2. これでターミナルにサンプル出力が生成されます。必要に応じて、これらのサンプルを編集し、oc create コマンドを使用してオブジェクトを作成します。

  3. 要求がアダプターに到達すると、アダプターはサービスが 3scale の API にどのようにマッピングされるかを認識している必要があります。この情報は、以下のいずれかの方法で提供できます。

    1. ワークロードにラベルを付ける (推奨)
    2. ハンドラーを service_id としてハードコーディングする

  4. 必要なアノテーションでワークロードを更新します。

    注記

    ハンドラーにまだ組み込まれていない場合は、このサンプルで提供されたサービス ID のみを更新する必要があります。ハンドラーの設定が優先されます。 

    $ export CREDENTIALS_NAME="replace-me"
export SERVICE_ID="replace-me"
export DEPLOYMENT="replace-me"
patch="$(oc get deployment "${DEPLOYMENT}"
patch="$(oc get deployment "${DEPLOYMENT}" --template='{"spec":{"template":{"metadata":{"labels":{ {{ range $k,$v := .spec.template.metadata.labels }}"{{ $k }}":"{{ $v }}",{{ end }}"service-mesh.3scale.net/service-id":"'"${SERVICE_ID}"'","service-mesh.3scale.net/credentials":"'"${CREDENTIALS_NAME}"'"}}}}}' )"
oc patch deployment "${DEPLOYMENT}" --patch ''"${patch}"''

2.11.1.3. アダプター経由でのサービストラフィックのルーティング

以下の手順に従って、3scale アダプターを使用してサービスのトラフィックを処理します。

前提条件

  • 3scale 管理者から受け取る認証情報とサービス ID

手順

  1. kind: rule リソース内で、以前に設定で作成した destination.labels["service-mesh.3scale.net/credentials"] == "threescale" ルールと一致させます。
  2. 上記のラベルを、ターゲットワークロードのデプロイメントで PodTemplateSpec に追加し、サービスを統合します。値 threescale は生成されたハンドラーの名前を参照します。このハンドラーは、3scale を呼び出すのに必要なアクセストークンを保存します。
  3. destination.labels["service-mesh.3scale.net/service-id"] == "replace-me" ラベルをワークロードに追加し、要求時にサービス ID をインスタンス経由でアダプターに渡します。

2.11.2. 3scale での統合設定

以下の手順に従って、3scale の統合設定を行います。

注記

3scale SaaS を使用している場合は、Red Hat OpenShift Service Mesh は Early Access プログラムの一部として有効になっています。

手順

  1. [your_API_name] → Integration の順に移動します。
  2. Settings をクリックします。

  3. Deployment で Istio オプションを選択します。

    • デフォルトでは Authentication の API Key (user_key) オプションが選択されます。
  4. Update Product をクリックして選択内容を保存します。
  5. Configuration をクリックします。
  6. 設定の更新 をクリックします。

2.11.3. キャッシング動作

3scale System API からの応答は、アダプター内でデフォルトでキャッシュされます。cacheTTLSeconds 値よりも古いと、エントリーはキャッシュから消去されます。また、デフォルトでキャッシュされたエントリーの自動更新は、cacheRefreshSeconds 値に基づいて、期限が切れる前に数秒間試行されます。cacheTTLSeconds 値よりも高い値を設定することで、自動更新を無効にできます。

cacheEntriesMax を正の値以外に設定すると、キャッシングを完全に無効にできます。

更新プロセスを使用すると、到達不能になるホストのキャッシュされた値が、期限が切れて最終的に消去される前に再試行されます。

2.11.4. 認証要求

このリリースでは、以下の認証方法をサポートします。

  • 標準 API キー: 単一のランダム文字列またはハッシュが識別子およびシークレットトークンとして機能します。
  • アプリケーション ID とキーのペア: イミュータブルな識別子とミュータブルなシークレットキー文字列。
  • OpenID 認証方法: JSON Web トークンから解析されるクライアント ID 文字列。

2.11.4.1. 認証パターンの適用

以下の認証方法の例に従って instance カスタムリソースを変更し、認証動作を設定します。認証情報は、以下から受け取ることができます。

  • 要求ヘッダー
  • 要求パラメーター
  • 要求ヘッダーとクエリーパラメーターの両方
注記

ヘッダーの値を指定する場合、この値は小文字である必要があります。たとえば、ヘッダーを User-Key として送信する必要がある場合、これは設定で request.headers["user-key"] として参照される必要があります。

2.11.4.1.1. API キー認証方法

Service Mesh は、subject カスタムリソースパラメーターの user オプションで指定されたクエリーパラメーターと要求ヘッダーで API キーを検索します。これは、カスタムリソースファイルで指定される順序で値をチェックします。不要なオプションを省略することで、API キーの検索をクエリーパラメーターまたは要求ヘッダーに制限できます。

この例では、Service Mesh は user_key クエリーパラメーターの API キーを検索します。API キーがクエリーパラメーターにない場合、Service Mesh は x-user-key ヘッダーを確認します。

API キー認証方法の例

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
  namespace: istio-system
spec:
  template: authorization
  params:
    subject:
      user: request.query_params["user_key"] | request.headers["user-key"] | ""
    action:
      path: request.url_path
      method: request.method | "get"

アダプターが異なるクエリーパラメーターまたは要求ヘッダーを検査するようにする場合は、名前を適宜変更します。たとえば、key というクエリーパラメーターの API キーを確認するには、request.query_params["user_key"] を request.query_params["key"] に変更します。

2.11.4.1.2. アプリケーション ID およびアプリケーションキーペアの認証方法

Service Mesh は、subject カスタムリソースパラメーターの properties オプションで指定されるように、クエリーパラメーターと要求ヘッダーでアプリケーション ID とアプリケーションキーを検索します。アプリケーションキーはオプションです。これは、カスタムリソースファイルで指定される順序で値をチェックします。不要なオプションを含めないことで、認証情報の検索をクエリーパラメーターまたは要求ヘッダーのいずれかに制限できます。

この例では、Service Mesh は最初にクエリーパラメーターのアプリケーション ID とアプリケーションキーを検索し、必要に応じて要求ヘッダーに移動します。

アプリケーション ID およびアプリケーションキーペアの認証方法の例

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
  namespace: istio-system
spec:
  template: authorization
  params:
    subject:
        app_id: request.query_params["app_id"] | request.headers["app-id"] | ""
        app_key: request.query_params["app_key"] | request.headers["app-key"] | ""
    action:
      path: request.url_path
      method: request.method | "get"

アダプターが異なるクエリーパラメーターまたは要求ヘッダーを検査するようにする場合は、名前を適宜変更します。たとえば、identification という名前のクエリーパラメーターのアプリケーション ID を確認するには、request.query_params["app_id"] を request.query_params["identification"] に変更します。

2.11.4.1.3. OpenID 認証方法

OpenID Connect (OIDC) 認証方法 を使用するには、subject フィールドで properties 値を使用して client_id および任意で app_key を設定します。

このオブジェクトは、前述の方法を使用して操作できます。以下の設定例では、クライアント識別子 (アプリケーション ID) は、azp ラベルの JSON Web Token (JWT) から解析されます。これは必要に応じて変更できます。

OpenID 認証方法の例

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
spec:
  template: threescale-authorization
  params:
    subject:
      properties:
        app_key: request.query_params["app_key"] | request.headers["app-key"] | ""
        client_id: request.auth.claims["azp"] | ""
      action:
        path: request.url_path
        method: request.method | "get"
        service: destination.labels["service-mesh.3scale.net/service-id"] | ""

この統合を正常に機能させるには、クライアントがアイデンティティープロバイダー (IdP) で作成されるよう OIDC を 3scale で実行する必要があります。保護するサービスと同じ namespace でサービスの に要求の認証 を作成する必要があります。JWT は要求の Authorization ヘッダーに渡されます。

以下に定義されるサンプル RequestAuthentication で、issuer、jwksUri、および selector を適宜置き換えます。

OpenID Policy の例

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-example
  namespace: info
spec:
  selector:
    matchLabels:
      app: productpage
  jwtRules:
  - issuer: >-
      http://keycloak-keycloak.34.242.107.254.nip.io/auth/realms/3scale-keycloak
    jwksUri: >-
      http://keycloak-keycloak.34.242.107.254.nip.io/auth/realms/3scale-keycloak/protocol/openid-connect/certs

2.11.4.1.4. ハイブリッド認証方法

特定の認証方法を適用せず、いずれかの方法の有効な認証情報を受け入れる方法を選択できます。API キーとアプリケーション ID/アプリケーションキーペアの両方が提供される場合は、Service Mesh は API キーを使用します。

この例では、Service Mesh がクエリーパラメーターの API キーをチェックし、次に要求ヘッダーを確認します。API キーがない場合は、クエリーパラメーターのアプリケーション ID とキーをチェックし、次に要求ヘッダーを確認します。

ハイブリッド認証方法の例

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
spec:
  template: authorization
  params:
    subject:
      user: request.query_params["user_key"] | request.headers["user-key"] |
      properties:
        app_id: request.query_params["app_id"] | request.headers["app-id"] | ""
        app_key: request.query_params["app_key"] | request.headers["app-key"] | ""
        client_id: request.auth.claims["azp"] | ""
    action:
      path: request.url_path
      method: request.method | "get"
      service: destination.labels["service-mesh.3scale.net/service-id"] | ""

2.11.5. 3scale アダプターメトリクス

アダプターはデフォルトで、/metrics エンドポイントのポート 8080 で公開されるさまざまな Prometheus メトリクスを報告します。これらのメトリクスは、アダプターと 3scale の間の相互作用がどのように実行されているかに関する洞察を提供します。サービスには、自動的に検出され、Prometheus によって収集されるようにラベルが付けられます。

2.11.6. 3scale Istio Adapter の検証

3scale Istio Adapter が予想通りに機能しているかどうかを確認します。アダプターが機能しない場合は、以下の手順に従って問題のトラブルシューティングを行うことができます。

手順

  1. 3scale-adapter Pod が Service Mesh コントロールプレーン namespace で実行されていることを確認します。 

    $ oc get pods -n istio-system

  2. そのバージョンなど、3scale-adapter Pod が起動に関する情報を出力したことを確認します。 

    $ oc logs istio-system
  3. 3scale Adapter の統合で保護されているサービスに対して要求を実行すると、正しい認証情報がかけているという要求を必ず試し、その要求が失敗することを確認します。3scale Adapter ログをチェックして、追加情報を収集します。

関連情報

2.11.7. 3scale Istio adapter のトラブルシューティングのチェックリスト

管理者が 3scale Istio adapter をインストールすると、統合が適切に機能しなくなる可能性のあるシナリオが複数あります。以下のリストを使用して、インストールのトラブルシューティングを行います。

  • YAML のインデントが間違っている。
  • YAML セクションがない。
  • YAML の変更をクラスターに適用するのを忘れている。
  • service-mesh.3scale.net/credentials キーでサービスのワークロードにラベルを付けるのを忘れている。
  • service_id が含まれないハンドラーを使用してアカウントごとに再利用できるようにする時に service-mesh.3scale.net/service-id サービスワークロードにラベルを付けるのを忘れている。
  • Rule カスタムリソースが誤ったハンドラーまたはインスタンスカスタムリソースを参照しているか、対応する namespace の接尾辞がかけている参照を指定している。
  • Rule カスタムリソースの match セクションは、設定中のサービスと同じでない可能性があるか、現在実行中でない、または存在しない宛先ワークロードを参照している。
  • ハンドラーの 3scale 管理ポータルのアクセストークンまたは URL が正しくない。
  • クエリーパラメーター、ヘッダー、認可要求などの誤った場所を指定しているか、パラメーター名がテストで使用する要求と一致しないため、インスタンス のカスタムリソースの params/subject/properties セクションで、 app_id、app_key または client_id の正しいパラメーターの表示に失敗する。
  • 設定ジェネレーターがアダプターコンテナーイメージに実際に存在しており、oc exec で呼び出す必要があることに気づかなかったため、設定ジェネレーターの使用に失敗する。