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 アカウントごとに単一のハンドラーを使用します。
手順
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 を利用する必要がある場合に役立ちます。3scale アカウントに属するサービスの Deployment リソースを編集するか、またはパッチを適用します。
-
有効な
service_id
に対応する値を使用して"service-mesh.3scale.net/service-id"
ラベルを追加します。 -
手順 1 の ハンドラーリソースの名前 の値を使用して
"service-mesh.3scale.net/credentials"
ラベルを追加します。
-
有効な
- 他のサービスを追加する場合には、手順 2 を実行して、3scale アカウントの認証情報とそのサービス識別子にリンクします。
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
カスタムリソースの生成を可能にするツールが含まれます。
オプション | 説明 | 必須 | デフォルト値 |
---|---|---|---|
| 利用可能なオプションについてのヘルプ出力を生成します | いいえ | |
| この URL の一意の名前、トークンのペア | はい | |
| テンプレートを生成する namespace | いいえ | istio-system |
| 3scale アクセストークン | はい | |
| 3scale 管理ポータル URL | はい | |
| 3scale バックエンド URL。これが設定されている場合、システム設定から読み込まれる値がオーバーライドされます。 | いいえ | |
| 3scale API/サービス ID | いいえ | |
| 指定する 3scale 認証パターン (1=API Key, 2=App Id/App Key, 3=OIDC) | いいえ | ハイブリッド |
| 生成されたマニフェストを保存するファイル | いいえ | 標準出力 |
| 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
識別子に自動設定されます。 - この値は具体的なものでなくても構いませんが、ラベル値はルールの内容と一致させる必要があります。詳細は、アダプター経由でのサービストラフィックのルーティング を参照してください。
このコマンドを実行して、
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}
-
これでターミナルにサンプル出力が生成されます。必要に応じて、これらのサンプルを編集し、
oc create
コマンドを使用してオブジェクトを作成します。 要求がアダプターに到達すると、アダプターはサービスが 3scale の API にどのようにマッピングされるかを認識している必要があります。この情報は、以下のいずれかの方法で提供できます。
- ワークロードにラベルを付ける (推奨)
-
ハンドラーを
service_id
としてハードコーディングする
必要なアノテーションでワークロードを更新します。
注記ハンドラーにまだ組み込まれていない場合は、このサンプルで提供されたサービス 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
手順
-
kind: rule
リソース内で、以前に設定で作成したdestination.labels["service-mesh.3scale.net/credentials"] == "threescale"
ルールと一致させます。 -
上記のラベルを、ターゲットワークロードのデプロイメントで
PodTemplateSpec
に追加し、サービスを統合します。値threescale
は生成されたハンドラーの名前を参照します。このハンドラーは、3scale を呼び出すのに必要なアクセストークンを保存します。 -
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 プログラムの一部として有効にされています。
手順
-
[your_API_name]
Integration の順に移動します。 - Settings をクリックします。
Deployment で Istio オプションを選択します。
- デフォルトでは Authentication の API Key (user_key) オプションが選択されます。
- Update Product をクリックして選択内容を保存します。
- Configuration をクリックします。
- 設定の更新 をクリックします。
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 が予想通りに機能しているかどうかを確認します。アダプターが機能しない場合は、以下の手順に従って問題のトラブルシューティングを行うことができます。
手順
3scale-adapter Pod が Service Mesh コントロールプレーン namespace で実行されていることを確認します。
$ oc get pods -n <istio-system>
そのバージョンなど、3scale-adapter Pod が起動に関する情報を出力したことを確認します。
$ oc logs <istio-system>
- 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
で呼び出す必要があることに気づかなかったため、設定ジェネレーターの使用に失敗する。