https://wenhan.blog/tags/plugin/ Recent content in Plugin on Wenhan blog Hugo -- gohugo.io ja-JP Tue, 23 Jan 2024 22:55:37 +0900 https://wenhan.blog/posts/20240123_kong-oidc-plugin-extra-use-cases/ Tue, 23 Jan 2024 22:55:37 +0900 https://wenhan.blog/posts/20240123_kong-oidc-plugin-extra-use-cases/ (https://tech.aufomm.com/kong-oidc-plugin-extra-use-cases/ より翻訳) KongのOIDCプラグインはとてもパワフルで複雑なので（200近くのパラメーターがある…）、ユーザーがどのような設定の組み合わせが必要かを知っていれば、より多くのことができるようになる。今日の投稿では、このプラグインをよりうまく使うためのいくつかの使用例を紹介しよう。 なお、私はKong Gateway (Enterprise)の最新バージョン2.4.1.1を使用しています。 前提条件 Kong Gateway (Enterprise) OIDCサーバーが稼動していること。(私の例ではKeycloak) もしKeycloakの使い方がわからない場合は、以前の投稿をご覧ください IDPトークンからデータを抽出しヘッダへの追加 IDPトークンからアップストリームヘッダーに値をマッピングしたい場合は、config.upstream_headers_namesとconfig.upstream_headers_claimsを使用できます。 例えば、JWTトークンのペイロードに以下のようなclaimがあるとします。 1 2 3 4 5 { "payload": { "kong-test": "to-upstream" } } 目的は、ヘッダーkong-testにto-upstreamの値をマッピングし、アップストリームサーバーに送信することである。OIDCプラグインは以下のように設定できる。これはパスワードフローを使っている。 1 2 3 4 5 6 7 8 9 10 curl --request POST \ --url http://kong.li.lan:8001/plugins \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data name=openid-connect \ --data config.issuer=https://<keycloak>/auth/realms/demo \ --data config.client_id=<client_id> \ --data config.client_secret=<client_secret> \ --data config.auth_methods=password \ --data config.upstream_headers_claims=kong-test \ --data config.upstream_headers_names=test_kong ユーザー名とパスワードを指定してapiエンドポイントを呼び出すと、アップストリームサーバーに送信されるリクエストに以下のヘッダーが表示されるはずです。 https://wenhan.blog/posts/20230522_kong_jwt_plugin/ Mon, 22 May 2023 00:33:31 +0900 https://wenhan.blog/posts/20230522_kong_jwt_plugin/ (https://tech.aufomm.com/how-to-use-jwt-plugin/ より翻訳) Kongにはたくさんの認証プラグインがあります。今回はJWT Pluginの使い方についてお話したいと思います。 使用例 サービスを作成 1 2 3 4 curl -X POST http://localhost:8001/services \ -H "Content-Type: application/json" \ -H "Accept: application/json, */*" \ -d '{"name":"jwt-service","url":"https://httpbin.org/anything"}' Routeを作成 1 2 3 4 curl -X POST http://localhost:8001/services/jwt-service/routes \ -H "Content-Type: application/json" \ -H "Accept: application/json, */*" \ -d '{"name":"jwt-route","paths":["/jwt"]}' curl 'http://localhost:8000/jwt' -i でルートにアクセスすると、HTTP/1.1 200 OKとなるはずです。 JWT Pluginを有効 :::note このプラグインは、Service単位またはグローバル全体に有効化することも可能です。 ::: 1 2 3 4 curl --request POST \ --url http://localhost:8001/plugins \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data name=jwt 上記のルートをもう一度アクセスすると、HTTP/1. https://wenhan.blog/posts/20230220_exit_slack/ Mon, 20 Feb 2023 14:21:23 +0900 https://wenhan.blog/posts/20230220_exit_slack/ 背景 Kong Gatewayを使ってAPIにアクセスする時には、もしリクエストが失敗したら通知して欲しいですね。通常のやり方はLog系のプラグインでLogを保存してから、3rd partyの製品（ELK）でAlertを設定して通知することです。でも他の製品を使うとデプロイも面倒だし、ライセンスや設定内容も必要だし、できればKong内部で実現したいな。。という要望があると思います。 今回は、Exit Transformer プラグインを使って、リクエストがエラーだったらLuaスクリプトでSlack Webhookを叩くことをメモします。このプラグインは、Lua 関数を使用して、Kong 応答終了メッセージを変換およびカスタマイズすることができます。メッセージ、ステータスコード、ヘッダーの変更から、Kong 応答の構造の完全な変換まで、さまざまな機能があります。 プラグインを試す まずはページ上にある例を試してみよう。 サービスとルートを作成 1 2 http :8001/services name=example.com host=mockbin.org http -f :8001/services/example.com/routes hosts=example.com 失敗させるため key auth プラグインを実装 1 http :8001/services/example.com/plugins name=key-auth Luaスクリプトを作成 以下のコードでは、x-some-headerのヘッダーを追加し、メッセージの最後に, arrを追加した。 この内容をtransform.luaとして保存する。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 -- transform.lua return function(status, body, headers) if not body or not body.message then return status, body, headers end headers = { ["x-some-header"] = "some value" } local new_body = { error = true, status = status, message = body. https://wenhan.blog/posts/20220802_using-kong-gw-route-by-header-plugin/ Wed, 03 Aug 2022 01:19:02 +0900 https://wenhan.blog/posts/20220802_using-kong-gw-route-by-header-plugin/ 紹介 Kong GatewayではRouteでサブパスを定義し、どのServiceにアクセスするかを決めています。例えば、以下のURLの後ろのサブパスがpathAの場合は、トラフィックがserviceAにルーティングされ、最終的に後ろにあるendpointAにアクセスされます。 1 http://mykong.org:8000/pathA => serviceA => endpointA しかし、サブパスではなくて、もっと動的にリクエストの転送先を決めたい場合があります。このプラグインは、事前に定義されたヘッダーと転送先をルールに、リクエストヘッダ情報を見て転送先を決めています。ルールに二つのパラメータがあり、conditionは定義したヘッダーと値、upstream_nameは転送先のUpstreamオブジェクトです。 1 {"rules":[{"condition": {"location":"us-east"}, "upstream_name": "east.doamin.com"}]} この記事では、このプラグインの実装についてメモします。 注：このプラグインを操作できるのはAdmin APIを通す方法のみ。Kong Managerでの操作はできない。 https://docs.konghq.com/hub/kong-inc/route-by-header/ デモ 実際にこのプラグインを使ってみましょう。まずは作業用のserviceとrouteを作成する。serviceのendpointはhttp://httpbin.org/anything となりますが、このプラグインのルールに当てはまらない時にアクセスされます。 1 2 3 4 5 6 7 8 9 10 curl -i -X POST http://localhost:8001/services \ --data protocol=http \ --data host=httpbin.org \ --date path=/anything --data name=demo curl -i -X POST http://localhost:8001/routes \ --data "paths[]=/" \ --data service.id=<The id of service created above> --data name=demo 次に、転送先のUpstreamを二つ用意し、myipとdateをそれぞれアクセスするとIPアドレスと時間が表示されます。 1 2 3 4 5 curl -i -X POST http://localhost:8001/upstreams -d name=myip curl -i -X POST http://localhost:8001/upstreams/myip/targets --data target="ip. https://wenhan.blog/posts/20220531_using-kong-canary-release-plugin/ Tue, 31 May 2022 13:58:39 +0900 https://wenhan.blog/posts/20220531_using-kong-canary-release-plugin/ 紹介 Kong Gatewayのプラグインを利用すれば、カナリアリリースが簡単に設定することができます。しかもカナリアリリースのモードは単なるパーセンテージではなく、徐々に利用拡大や、Writelist&blacklistの設定もできます。 この記事では、カナリアリリースのやり方についてメモします。 https://docs.konghq.com/hub/kong-inc/canary/ ServiceとRouteの作成 デモの例として、現在のバージョンをhttp://httpbin.org/xmlに、新規リリースのバージョンをhttp://httpbin.org/jsonにします。なので、現在のバージョンの場合は、xmlのレスポンス、新規リリースのバージョンの場合は、jsonのレスポンスが帰ってくるはず。 1 2 3 4 5 6 7 ❯ http POST localhost:8001/services \ name=canary-api-service \ url=http://httpbin.org/xml ❯ http -f POST localhost:8001/services/canary-api-service/routes \ name=canary-api-route \ paths=/api/canary 動作確認、xmlのレスポンスが帰ってきた。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 ❯ http GET localhost:8000/api/canary HTTP/1. https://wenhan.blog/posts/20220517_using-kong-mocking-plugin/ Tue, 17 May 2022 13:58:39 +0900 https://wenhan.blog/posts/20220517_using-kong-mocking-plugin/ 紹介 Mockingプラグインは、開発中のAPIに対するテストを行うために、模擬のエンドポイントを提供するものです。Open API（OAS）仕様に基づいて、APIに送信されたリクエストに模擬応答をレスポンスします。また、テストの柔軟性のため、Mockingプラグインを簡単に有効または無効にすることができます。 https://docs.konghq.com/hub/kong-inc/mocking/ 注意点として、このプラグインは、200、201と204の応答をレスポンスすることができます。正常動作をテストするために開発されたもので、200番台以外のコードをを返すことができません。 今回は、db-less環境のKong-gatewayをDocker containerで構築し、その上に Mocking Pluginを試してみます。 Kong-gatewayをデプロイする前に db-lessの環境のため、Admin APIやGUIで設定を変更することはできません（保存先はないから）。そのため、起動時にDeclarative Configurationという名の設定ファイルを事前にコンテナーに食わせる必要があります。 https://docs.konghq.com/gateway/2.8.x/reference/db-less-and-declarative-config/#main 今回の目標は Mockingを試したいので、 Mockingの設定内容も事前にこのファイルに記述していきます。Mocking Pluginの紹介ページで書いたように、設定自体はとてもシンプルです。ただ、肝心なのはapi_specificationとapi_specification_filenameの二つです。この二つのパラメータは、模擬のエンドポイントのスペック内容を定義するために使われますが、違いは以下の通りです。 api_specification_filename: スペック内容が保存されたファイル名を設定する。 api_specification: スペック内容をそのままパラメータに設定する。 api_specification_filenameは、設定するファイルを事前にDev Portalにアップロードしてから、パスなしで設定してください。設定の例はここに書いています。しかし、今回はdb-lessの環境を構築するため、そもそもdev protalが利用できないし、api_specification_filenameを利用できません。 そのため、api_specificationにサンプルのAPIのスペック内容をそのまま設定し、コンテナーを立ち上げます。スペックのサンプルは、Mocking Pluginの紹介ページにあります。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 _format_version: "1.1" _transform: true services: - host: mockbin.org name: example_service port: 80 protocol: http routes: - name: example_route paths: - /mock strip_path: true plugins: - name: mocking config: api_specification: '{"swagger":"2.