https://wenhan.blog/tags/kong/ Recent content in Kong on Wenhan blog Hugo -- gohugo.io ja-JP Thu, 01 May 2025 23:49:19 +0900 https://wenhan.blog/posts/20250501_konnect_ecs_gui/ Thu, 01 May 2025 23:49:19 +0900 https://wenhan.blog/posts/20250501_konnect_ecs_gui/ Kong Konnect のData Planeとして、AWS ECS（Elastic Container Service）Fargate を使ってマイクロサービスをデプロイし、API Gateway環境の構築方法を紹介します。 準備するもの AWSアカウント Kong Konnectアカウント 構築手順 Kong Konnect側 Konnectにログインし、Gateway manager -> Data Plane Nodes -> Configure data planeの順でData Plane作成画面にきて、Generate Certificateをクリックしてdocker runのコマンドが生成されます。このコマンドのパラメータが以降使いますのでコピーしていきます。 証明書が生成されたらKonnect側の作業が終わります。この証明書とkeyに改行が入っています、後でECSの環境変数として設定するため、下のコマンドで一行になるように変更します。 1 awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' tls.key AWS ECS側 コンテナーの定義 AWS ECS -> Task definitions -> Create new task definition with JSON でコンテナーの定義を行います。 利用するJSONは以下になります。 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 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 { "family": "kong-data-plane", "networkMode": "awsvpc", "containerDefinitions": [ { "name": "kong-data-plane", "image": "kong/kong-gateway:3. https://wenhan.blog/posts/20250415_kong_serverless/ Tue, 15 Apr 2025 23:49:19 +0900 https://wenhan.blog/posts/20250415_kong_serverless/ Pre-function Plugin 解説と実用サンプル Kong Gatewayは多機能なAPIゲートウェイですが、ちょっとした処理をサーバレス関数として内蔵できることをご存知でしょうか？ 今回は、Luaスクリプトを使ってリクエストのBodyからUUIDを抽出し、Headerに追記＆ログ出力するという実用的なサンプルをご紹介します。 Pre-function Pluginとは？ 公式ドキュメントにある通り、pre-functionプラグインはリクエストをAPIに送信する前にLuaで処理を記述できる柔軟な機能です。 用途は多彩で： 条件分岐によるフィルタリング ヘッダー／ボディのカスタマイズ 軽量ログやモニタリング処理 メンテナンス用の簡易ブロック処理 など、プラグイン化するほどじゃないけど、ちょっと処理したいというニーズにぴったりです。 実用例 今回は、リクエストボディにあるUUIDを抽出してヘッダーとログに追記する機能をServer Less機能で実現します。 処理の流れ リクエストBodyからUUIDを抽出（JSONパース） UUIDがあれば x-uuid ヘッダーに追記 抽出結果をログに出力（File Logプラグイン使用） 前提準備：サービスとルートを作成 1 2 3 4 5 6 7 8 # サービス作成 curl -i -X POST http://localhost:8001/services \ --data name=mock-service \ --data url=http://httpbin.org/anything # ルート作成 curl -i -X POST http://localhost:8001/services/mock-service/routes \ --data 'paths[]=/uuid-test' File Log Plugin でログ出力（標準出力へ） 1 2 3 curl -i -X POST http://localhost:8001/services/mock-service/plugins \ --data "name=file-log" \ --data "config. https://wenhan.blog/posts/20250325_kong_graphql_mngm/ Tue, 25 Mar 2025 23:49:19 +0900 https://wenhan.blog/posts/20250325_kong_graphql_mngm/ GraphQL のおさらい GraphQL は、Facebook が開発した API クエリ言語であり、従来の REST API よりも柔軟にデータを取得できる仕組みを提供します。 GraphQL の特徴 単一のエンドポイント: REST API では複数のエンドポイントが必要ですが、GraphQL では 1 つのエンドポイント (/graphql) に対して異なるクエリを送信できます。 必要なデータのみ取得: クライアントが必要なフィールドだけを指定して取得できるため、不要なデータ転送を防げます。 型システム: API のスキーマが型で定義されており、データ構造を明確に把握できます。 例えば、https://countries.trevorblades.com/ という GraphQL API に対して、以下のようなクエリを送信すると、日本の国情報を取得できます。 1 2 3 4 5 6 7 { country(code: "JP") { name capital currency } } このクエリを curl を使って実行する場合: 1 2 3 curl -X POST https://countries.trevorblades.com/ \ -H "Content-Type: application/json" \ -d '{"query": "{ country(code: \"JP\") { name capital currency } }"}' レスポンス: https://wenhan.blog/posts/20241224_kong_101_mtls/ Tue, 24 Dec 2024 23:49:19 +0900 https://wenhan.blog/posts/20241224_kong_101_mtls/ API通信におけるセキュリティは、システムの信頼性を保つ上で非常に重要です。本記事では、Kong API Gatewayを使用して、mTLS（Mutual TLS、相互TLS）を設定する方法を詳しく解説します。特に、「Client -> Kong」と「Kong -> Upstream API」の2つの通信パスでのmTLSの設定方法について取り上げます。 mTLSの基礎知識 mTLSとは、TLS（Transport Layer Security）を拡張したプロトコルで、通信の両側（クライアントとサーバー）が互いに証明書を使って認証を行います。通常のTLSはサーバー側の認証だけを行いますが、mTLSでは以下のようなプロセスが追加されます： サーバー認証：クライアントは、サーバーが信頼できる証明書を持っていることを確認します。 クライアント認証：サーバーは、クライアントが信頼できる証明書を持っていることを確認します。 この双方向の認証により、より安全な通信が実現します。 Kong API Gatewayで実現するmTLS通信 Kong API Gatewayを使えば、以下の2つの通信経路でmTLSを簡単に実現できます： クライアント → Kong API Gateway Kong API Gateway → Upstream API Client->KongのmTLS設定 クライアントからKong API Gatewayへの通信にmTLSを実装するには、Kongの「mTLS Plugin」を使用します。以下は手順の概要です。 管理者がクライアント認証用のCA証明書をKongに設定 クライアントはリクエスト時に自分の証明書をKongに提示 Kongがクライアント証明書を検証し、安全な通信を許可 CA証明書を登録 Clientの証明書を検証するためのCA証明書をvalutに登録 1 2 3 4 5 6 7 8 9 curl http://localhost:8001/ca_certificates -F cert=@ca.crt { "cert": "<PEM_CERT>", "id": "c383d81a-bffc-4e2a-b0d3-ac56b441a07b", "cert_digest": "3e9099b5015e8f486c00bcea9d111ee721faba355a89bcf1df69561e3dc6325c", "tags": null, "created_at": 1607347576 } mTLSプラグインを有効化 先ほど作ったca_certificateを利用して、mTLSプラグインを有効化します。ここではグローバル範囲に指定しています。 https://wenhan.blog/posts/20241223_kong_101_req_res_trans/ Mon, 23 Dec 2024 23:49:19 +0900 https://wenhan.blog/posts/20241223_kong_101_req_res_trans/ 前書き 現代のアプリケーション開発では、APIは他のシステムやサービスと連携するための重要な基盤となっています。しかし、異なるシステム間でAPIの要件が合わない、データ形式が異なる、セキュリティ要件が満たされていない、といった課題は頻繁に発生しています。こうした状況において、APIゲートウェイを活用することが、リクエストとレスポンスを柔軟に変更する最も効果的な方法です。 Kong GatewayのようなAPIゲートウェイは、単なるAPI管理ツールではありません。トラフィックの流れを制御する中で、リクエストやレスポンスの内容をカスタマイズする強力な機能を提供します。たとえば、次のような項目を変更することが可能です： ヘッダー クライアントから送信されたリクエストヘッダーに認証情報やカスタム値を追加したり、レスポンスヘッダーを編集してキャッシュ制御やセキュリティに関する情報を含めたりすることができます Bodyの変換 リクエストBodyを加工して上流のサービスが期待する形式に変更したり、レスポンスBodyの内容をフィルタリングして不要なデータを削除することが可能です ステータスコードの変更 APIの動作に応じてステータスコードを変更し、エラー処理やリダイレクトの挙動を制御することもできます データフォーマットの変換 古いシステムがXMLを要求するが、新しいシステムがJSONを利用している場合、APIゲートウェイでデータフォーマットを動的に変換することで互換性を確保できます 暗号化と復号化 セキュリティ要件に応じて、リクエストやレスポンスデータを暗号化または復号化することで、通信の安全性を向上させることができます これらの変更はすべて、APIのクライアントやバックエンドに手を加えることなく実現できる点が最大の利点です。APIゲートウェイはシステムの境界で操作を行うため、変更内容が他のシステムに影響を与えるリスクを最小限に抑えながら、柔軟なカスタマイズを可能にします。 Kongでリクエストとレスポンスを変更する方法 この記事では、これらの変更をKong Gatewayでどのように実現するのかを具体的に解説していきます。 Request transformer / Response transformer プラグインの紹介 Kong Gatewayが提供するRequest TransformerおよびResponse Transformerプラグインは、リクエストやレスポンスの内容を簡単にカスタマイズするためのツールです。このプラグインを利用すれば、リクエストやレスポンスのヘッダーやBodyを加工・変換し、システム間の調整や特定のAPI要件に応える際に役立ちます。 主要な機能 Request Transformer プラグインの主な機能 リクエストヘッダーの追加、削除、上書き クエリパラメータの追加、削除、上書き リクエストBodyの追加・削除 Response Transformer プラグインの主な機能 レスポンスヘッダーの追加、削除、上書き レスポンスBodyの不要部分を削除 これらの機能を組み合わせることで、APIトラフィックを柔軟に制御することができます。 Plugin設定 まず、テスト用のServiceとRouteを作成します。今回はリクエストをそのままレスポンスするAPIを利用し、変更されたリクエストを確認します。 1 2 3 4 5 6 7 curl -i -X POST http://localhost:8001/services/ \ --data name=echo_service \ --data url=http://httpbin.org/anything curl -i -X POST http://localhost:8001/services/echo_service/routes/ \ --data name=echo_route \ --data paths=/echo 次、request transformerのプラグインを有効にし、以下のルールを設定しました。 https://wenhan.blog/posts/20241216_kong_jwt_ultra/ Mon, 16 Dec 2024 23:49:19 +0900 https://wenhan.blog/posts/20241216_kong_jwt_ultra/ (https://tech.aufomm.com/the-ultimate-guide-of-using-jwt-with-kong/ より翻訳) :::note この記事は「究極の」ガイドとまでは言えないかもしれませんが、JWT 検証に使える公式の Kong プラグインを徹底的に解説することを目指しています。読み終えるころには、利用可能なオプションを全体的に理解し、それぞれのユースケースに最適なプラグインを選べるようになるはずです。 ::: 背景 JSON Webトークン（JWT）は、Web開発に欠かせない要素であり、システム間で重要な情報を安全に伝える役割を果たします。その信頼性を確保するために、JWTの検証は欠かせないステップです。一方、KongのようなAPIゲートウェイは、特にOAuth 2.0やOIDC標準が普及する中で、組織のAPIアーキテクチャにおいて重要な位置を占めています。 この記事では、KongでJWTを検証するためのツールを詳しく解説し、現代のWeb開発環境でこのプロセスが果たす役割を探ります。 JWTとは :::note すでにJWTについて理解している方は、どのプラグインを選ぶべきかの詳細を省略し、次のセクションから読み進めてください。 ::: JSON Web Token（JWT）は、JSON Web Signature（JWS）とJSON Web Encryption（JWE）の2つの形式で構成されています。本記事では、主にJWSの検証に焦点を当てています。JWEの検証について知りたい方は、こちらの記事をご覧ください。 RFC7515によると、JSON Web Signature（JWS）は、デジタル署名やメッセージ認証コード（MAC）で保護されたコンテンツを表現するためのJSONベースのデータ構造です。簡単に言えば、JWSは重要なメッセージを含む「署名付きの手紙」のようなものです。この手紙の信頼性を確保するためには、署名を検証する必要があります。 アルゴリズム JWSで使用される暗号アルゴリズムとその識別子は、別の仕様であるJSON Web Algorithms (JWA) JWAに定義されています。また、これらのアルゴリズムは、JWA仕様に基づいて作成されたIANAレジストリに記載されています。 JWSで使用される暗号アルゴリズムとその識別子は、別の仕様であるJSON Web Algorithms (JWA)仕様に記載されています。 通常、RS256やES256といった非対称アルゴリズムの使用が推奨されます。一方、HS256のような対称アルゴリズムの使用は推奨されていません。 JWTのデータ構造 まず、JWTの構造を見てみましょう。以下に例を示します。 eyJhbGciOiJFUzI1NiIsImtpZCI6Imh1SEE3RDVaTUNKTWhLaVJIZVgwaGZSWG9fX1VBbEpCZ0FkTjhxb0MwMXcifQ.eyJpc3MiOiAiZm9tbSIsICJhdWQiOiAiand0LWRlbW8iLCAic3ViIjogImRlbW8tdXNlciIsICJpYXQiOiAxNjcyNDAzMzc4LCAiZXhwIjogMTY3MjQwMzY3OH0.bxkLGEjN4pXQQ6eymBO_DYl24NGu07FFR1ZXgmdFYHPGsNX10r6iyqDEtCHeXWs7Hsn-QIasV_i4Lw2nCHmlAA``` JOSE header JOSEヘッダーには、通常、このJWSを保護するために使用されるハッシュアルゴリズム（alg）やキーID（kid）が記載されています。また、typ（タイプ）が含まれていることも一般的です 1 2 3 4 { "alg": "ES256", "kid": "huHA7D5ZMCJMhKiRHeX0hfRXo__UAlJBgAdN8qoC01w" } Payload ペイロードは、保護されて他の相手に渡されるメッセージです 1 2 3 4 5 6 7 { "iss": "fomm", "aud": "jwt-demo", "sub": "demo-user", "iat": 1672403378, "exp": 1672403678 } Signature ユーザーは、JOSEヘッダーで定義されたアルゴリズムを使用して、保護されたヘッダーとペイロードの署名を計算し、署名が一致することを確認する必要があります https://wenhan.blog/posts/20241206_kong_101_proxy_caching/ Fri, 06 Dec 2024 23:49:19 +0900 https://wenhan.blog/posts/20241206_kong_101_proxy_caching/ はじめに APIゲートウェイにおけるキャッシュの主な目的は以下の通りです： 高速なレスポンス バックエンドの負荷軽減 コスト削減 上段（リクエスト1回目）の流れ クライアントがKong Gatewayにリクエストを送信 Kong Gatewayはこのリクエストをバックエンド（上流のサービス）に転送 バックエンドからのレスポンスをKong Gatewayが受け取り、このレスポンスをキャッシュ（Response Cache）として保存 レスポンスをConsumer側に返す 下段（リクエスト2回目）の流れ クライアントが同じリクエストを送信 Kong Gatewayはキャッシュを確認し、保存されているレスポンスを直接回答 この場合、バックエンドにアクセスする必要がなくなるため、応答速度が大幅に向上 TTL（キャッシュの有効期限）が切れていない限り、このキャッシュが利用可能 Kongのキャッシュ機能は、プラグインで実現しています。プラグインを有効化し、必要な設定を加えるだけでキャッシュ機能を利用可能ですので簡単なセットアップができます。また、キャッシュの有効期間や対象データを細かく制御でき、ユースケースに応じた設定が可能です。さらに、キャッシュ自体を外に保存することができ、大規模なシステムでも効果的に動作し、Kongの高いスケーラビリティと連携します。 キャッシュの基本概念 キャッシュは、頻繁にアクセスされるデータを一時的に保存し、高速に提供する仕組みです。多くのキャッシュデータをRAM上に保存し、極めて高速なレスポンスを実現することができます。キャッシュには以下の3つの構成要素があります： キャッシュキー: 保存されたデータを特定するための識別子 キャッシュデータ: 保存される実際のレスポンスデータ TTL（Time-To-Live）: データの有効期限 Kong Gatewayで提供されるキャッシュ機能 Kongではキャッシュ機能を提供するプラグインは以下の二つがあります。 Proxy Caching Proxy Caching Advanced Proxy Caching Proxy Cachingプラグインは、HTTPレスポンスをキャッシュし、次回の同様のリクエストに対してキャッシュデータを直接返す仕組みです。これにより、バックエンドサービスへのアクセスを最小限に抑え、APIのパフォーマンスを向上させます。 まず、テスト用のServiceとRouteを作成します。 1 2 3 4 5 6 7 curl -i -X POST http://localhost:8001/services/ \ --data name=uuid_service \ --data url=http://httpbin.org/uuid curl -i -X POST http://localhost:8001/services/uuid_service/routes/ \ --data name=uuid_route \ --data paths=/uuid 次に、Serviceに対しProxy Cachingのプラグインを作成します。 https://wenhan.blog/posts/20241203_kong_101_ratelimiting/ Tue, 03 Dec 2024 23:49:19 +0900 https://wenhan.blog/posts/20241203_kong_101_ratelimiting/ 流量制限（Rate Limiting）の重要性 現代のAPI経済において、流量制限（Rate Limiting）は、システムの安定性、セキュリティ、そしてコスト効率の観点から非常に重要な役割を果たしています。以下にその重要性を詳細に解説します。 サーバーの負荷管理 APIは、予測不能な量のリクエストを受ける可能性があります。たとえば、突然の人気アプリケーションの登場や予期しないトラフィックの急増（いわゆる「スパイク」）によって、サーバーが過剰に負荷を受けることがあります。流量制限を設けることで、リクエストの最大許容量をコントロールし、サーバーが適切なパフォーマンスを維持できるようになります。 公平性の確保 流量制限は、すべてのユーザーが公平にAPIを利用できるようにするための重要な手段です。特定のユーザーやアプリケーションがリソースを独占することを防ぎ、他のユーザーの体験を守ります。 セキュリティの向上 悪意のあるリクエストやDoS（Denial of Service）攻撃、ボットによる不正アクセスなどに対抗する手段として、流量制限は有効です。異常なリクエストパターンを検知して制限することで、APIとシステム全体を守ることができます。 コスト管理 多くのクラウドプロバイダーやインフラサービスは、リクエスト数やデータ転送量に基づいて料金が発生します。無制限のリクエストを許可すると、予期しないコストが急増するリスクがあります。流量制限を設けることで、コストの予測がしやすくなり、無駄な支出を防ぎます。 Kongにおける流量制限の基本的な仕組み Kong Gatewayは、オープンソースで開発されたAPIゲートウェイで、APIの管理や保護を簡単に行うためのツールです。企業や開発者がAPIのセキュリティ、パフォーマンス、信頼性を向上させるために利用しています。Kong Gatewayでの流量制限（Rate Limiting）は、APIエンドポイントやごとのトラフィックを制御するための機能です。この機能は、プラグインとして提供されており、簡単に有効化して設定できます。 Kongの流量制限プラグインは、以下のように動作します： リクエストのカウント プラグインは、リクエストをカウントし、指定した時間枠（秒、分、時間、日など）内の許容範囲を超えると制限を適用します。 閾値の超過時の動作 許容範囲を超えたリクエストは、HTTPステータスコード（通常は429 Too Many Requests）とともに拒否されます。カスタムメッセージを設定することも可能です。 ストレージの活用 カウント情報を保持するために、ローカルメモリやRedisなどの外部ストレージを使用します。これにより、分散環境での一貫性を確保します。 柔軟な適用範囲 Service単位: 特定のAPIに制限を設定 Consumer単位: 個々のユーザーやアプリケーションごとに異なる制限を適用 Route単位: 特定のAPIエンドポイントのみに制限を設定 基本設定: Kongの流量制限プラグイン Kongの流量制限プラグインは、以下の二つがあります。どれもリクエスト数を時間単位で制限します。たとえば、1分間に3リクエストまで許可するなど、簡単に設定可能です。 [OSS] https://docs.konghq.com/hub/kong-inc/rate-limiting/ [Enterprise] https://docs.konghq.com/hub/kong-inc/rate-limiting-advanced/ Plugin設定 このブログでは、まずOSSの方から説明いたします。まず、テスト用のServiceとRouteを作成します。 1 2 3 4 5 6 7 curl -i -X POST http://localhost:8001/services/ \ --data name=uuid_service \ --data url=http://httpbin.org/uuid curl -i -X POST http://localhost:8001/services/uuid_service/routes/ \ --data name=uuid_route \ --data paths=/uuid 制限をかけていないため、無限にUUIDを生成することができます。 https://wenhan.blog/posts/20241201_kong_101_service_route/ Sun, 01 Dec 2024 23:49:19 +0900 https://wenhan.blog/posts/20241201_kong_101_service_route/ Kong Gatewayを活用する際に重要な役割を果たすのが「サービス (Service)」と「ルート (Route)」です。サービスがAPIリクエストの転送先を定義する一方で、ルートはそのサービスにリクエストをマッピングするルールを定めます。 サービスとは サービスは、Kong Gatewayがプロキシする外部APIやマイクロサービスの情報を定義したものです。具体的には、リクエストを転送する先のURL、ホスト名、ポート番号、プロトコルなどを設定します。 例えば、Kongを使ってバックエンドの「ユーザーAPI」をプロキシしたい場合、そのAPIをサービスとして登録します。このとき、Kongはクライアントからのリクエストを受け取り、そのリクエストを登録されたサービスに転送します。Kongにサービスを作成する際に設定する主な項目は以下の通りです： name: サービスの名前。識別のためのラベルとして機能します host: リクエストを転送する先のホスト名（例: example.com） port: 接続先のポート番号（デフォルト: 80または443） protocol: 使用するプロトコル（httpまたはhttps） path: 転送先の特定のパス（例: /api/v1/users） ルートとは サービスは単独では機能せず、「ルート (Route)」と連携して使用されます。ルートは、クライアントからのリクエストを特定のサービスにマッピングするための設定です。ルートでは以下のような条件を指定できます： パス (Path): クライアントがアクセスするURLのパス メソッド (Method): HTTPメソッド（例: GET, POST） ホスト名 (Host): リクエストのホストヘッダー ヘッダー (Header): 特定のHTTPヘッダー値 ルートの設定により、Kongはどのリクエストをどのサービスに転送するかを判断します。 実用例 1つのServiceと1つのRouteを構築 この例では、以下のように1つのServiceを一つのRouteで公開する方法を説明します。http://httpbin.org/uuid という外部APIをプロキシするサービスをKong Gatewayに登録し、それを/uuidというパスで公開します。公開されたエンドポイントにアクセスすると、UUID（ユニークな識別子）が取得できます。 まず、以下のコマンドを使用して、http://httpbin.org/uuidをターゲットとするサービスを作成します： 1 2 3 curl -i -X POST http://localhost:8001/services/ \ --data name=uuid_service \ --data url=http://httpbin.org/uuid このコマンドにより、以下の設定がKongに登録されます： サービス名: uuid_service 転送先URL: http://httpbin.org/uuid 次に、このサービスを公開するためのルートを作成します。以下のコマンドを使用して、/uuidというパスでこのサービスを公開します： 1 2 3 curl -i -X POST http://localhost:8001/services/uuid_service/routes/ \ --data name=uuid_route \ --data paths=/uuid このコマンドで登録されたルートには、以下の設定が含まれます： https://wenhan.blog/posts/20241029_konggw_rke2/ Tue, 29 Oct 2024 23:49:19 +0900 https://wenhan.blog/posts/20241029_konggw_rke2/ この記事は、Kong をRKE2上にインストールする手順をメモします。 RKE2のインストール RKE2 Server 1 2 3 4 5 6 7 8 9 10 root@ip-10-0-25-27:~# curl -sfL https://get.rke2.io | sh - [INFO] finding release for channel stable [INFO] using v1.30.5+rke2r1 as release [INFO] downloading checksums at https://github.com/rancher/rke2/releases/download/v1.30.5+rke2r1/sha256sum-amd64.txt [INFO] downloading tarball at https://github.com/rancher/rke2/releases/download/v1.30.5+rke2r1/rke2.linux-amd64.tar.gz [INFO] verifying tarball [INFO] unpacking tarball file to /usr/local root@ip-10-0-25-27:~# systemctl enable rke2-server.service --now Created symlink /etc/systemd/system/multi-user.target.wants/rke2-server.service → /usr/local/lib/systemd/system/rke2-server.service. root@ip-10-0-25-27:~# 後処理 1 2 3 4 5 6 7 # RKE2 Agentが利用するTokenファイル cat /var/lib/rancher/rke2/server/node-token # 同時にインストールされるkubectlのパス cp /var/lib/rancher/rke2/bin/kubectl /usr/local/bin/ # kubeconfigのファイルパス mkdir . https://wenhan.blog/posts/20230308_using-sops-and-age-deploy-konggw/ Wed, 08 Mar 2023 16:41:18 +0900 https://wenhan.blog/posts/20230308_using-sops-and-age-deploy-konggw/ 背景 Kong Gatewayをデプロイする時に、データベースへの接続情報など平文で保存したくないデータが存在しています。これを解決するためにKong Secret Managerが開発され、AWS Secrets Managerなどの3rdパーティのサービスを利用すれば解決できます。しかし、環境によって外部のセキュリティサービスに接続できない時にこの機能は利用できません。ここで、Mozilaが開発したSOPSという暗号化ツールとGithub ActionのCI/CD workflowを利用し、普段暗号化されている設定ファイルをデプロイ時だけ復号し、Kong GWをインストールする実現することができました。 事前準備 CI/CD workflowを構築する前に、まずはローカル環境で暗号と復号を試してみましょう。以下の必要なツールをローカル環境にインストールします。 age sops SOPSはとても便利な暗号化・復号化のツールで人気があります。PGP, age, Google cloud’s KMS, Azure’s key valut, Hashicorp Vaultなどをサポートしています。今回は他のクラウドサービスを極力利用しない方針のため、ageを選択しました。 ツールのインストールができましたら、age-kengen --helpを試してみましょう。 1 2 3 4 5 6 7 8 $ age-keygen --help Usage: age-keygen [-o OUTPUT] age-keygen -y [-o OUTPUT] [INPUT] Options: -o, --output OUTPUT Write the result to the file at path OUTPUT. -y Convert an identity file to a recipients file. 見た感じ大丈夫そうなので、早速Keyを生成しましょう。