【CNDW2025】Gateway APIとKuadrant、Keycloakで実現するプロダクトチームに任せても壊れないAPI公開の設計思想

CloudNative Days Winter 2025で行われたセッション「Gateway API導入で失敗しない！KuadrantとKeycloakで実現するセキュアバイデフォルト設計」では、Gateway APIを軸に、プラットフォームエンジニアリングにおける権限分離とセキュリティ設計の実践が語られた。登壇した日立製作所の松田元輝氏は、架空の娘「クベ子」の物語を通じて、プロダクトチームに裁量を委ねながらも、事故を起こさないAPI公開を実現するための具体的な設計と実装を示した。本レポートでは、その考え方と技術的ポイントを整理する。

「パパと同じNamespaceはイヤ！」から始まるプラットフォームの悩み

セッションは、家庭内の何気ない一言から始まる。「パパと同じNamespaceはイヤ！」。思春期に入った娘・クベ子が専用のNamespaceを求めた、という設定はユーモラスでありながら、プラットフォームエンジニアリングの現場で頻出する課題を端的に表現している。すなわち、プロダクトチームに裁量を与えたい一方で、すべてを任せ切ることには不安が残る、という葛藤である。

専用Namespaceを与えること自体は難しくない。しかし問題はアプリケーション公開、すなわちIngressの扱いである。Ingressの作成権限を丸ごと委譲すれば、認証や認可が設定されないまま外部公開されるリスクが生じる。一方で、プラットフォームチームがIngressを一元管理すると、今度はプロダクトチームが自律的にルーティングや公開設定を変更できなくなる。これは単なる設定の話ではなく、「どこまで任せ、どこを守るか」という責任境界の問題である。

松田氏はこの状況を、決して極端な例ではないと強調する。「どうにかして、基本的なセキュリティを担保しつつ、アプリケーションの公開をクベ子に任せることはできないものか」と語り、プラットフォームエンジニアが日常的に抱える悩みであることを示した。家庭の比喩は、そのまま組織構造に置き換えられる。

現状の課題とめざしたい姿(プラットフォームエンジニアリングで置き換えて考える)

提示されたのは、「過干渉」と「放任」の二択では解決できないという現実である。プロダクトチームに自由度を与えながら、最低限の安全性はプラットフォーム側で保証する。この相反する要求をどう両立させるかが、セッション全体を貫くテーマであり、以降ではその具体的な技術的アプローチが段階的に示されていく。

クベ子にIngressを渡せない理由とGateway APIという『距離感』の設計

クベ子に専用Namespaceを与えたとしても、Ingressの扱いは依然として難題である。Ingressはシンプルなルーティングには十分だが、権限分離を前提とした設計には向いていない。Ingressを作成できる権限を与えれば、アプリケーションは自由に公開できる一方で、認証や認可が設定されないまま外部に露出する危険がある。逆にIngressをすべてプラットフォーム側で管理すれば、クベ子は自分のアプリケーションであっても、細かなルーティング変更を自身で行えなくなる。

Gateway APIの構成要素

松田氏はこの状態を「Ingressの権限を丸ごと渡すと危ないし、かといって握ってしまうと細かいルーティングをいじれなくなる」と表現した。これは家庭内の話ではなく、プロダクトチームとプラットフォームチームの関係そのものである。どちらかが全権を持つ構造では、健全な分業は成立しない。

この問題に対する解として提示されたのがGateway APIである。Gateway APIは、Ingressに代わるKubernetesの新しいネットワークAPIであり、ロール指向の設計を特徴とする。ロードバランサーそのものを管理するGatewayはプラットフォームチームが担当し、Gatewayからサービスへのルーティングを定義するHTTPRouteはプロダクトチームが管理する。触れる範囲が最初から分かれているため、「どこまで任せてよいか」を設計で規定できる。

この構造により、クベ子は自分のHTTPRouteを通じてアプリケーションの公開やルーティングを自由に設定できる。一方で、Gatewayそのものには手を出せないため、クラスタ全体に影響を与える変更はできない。過干渉でも放任でもない、適切な距離感を保った権限委譲が可能になるのである。Gateway APIは、クベ子の自立を尊重しながら、親としての責任を果たすための土台となる存在だ。

『何も考えずに公開してしまう』を防ぐ、クベ子のためのセキュリティ設計

Gateway APIによって権限分離の土台は整った。しかし、それだけで安全なAPI公開が実現するわけではない。HTTPRouteを作成すれば通信は成立するが、そこには認証も認可も存在しない。クベ子がHTTPRouteを作り忘れなく設定したとしても、セキュリティを意識しなければ、リクエストはそのまま通ってしまう。これは設計上の欠陥ではなく、Gateway APIがルーティングに特化したAPIである以上、避けられない前提である。

この課題に対して松田氏が提示したのが、KuadrantとKeycloakの組み合わせである。KuadrantはGateway APIに対して認証・認可やレート制限といったポリシーを適用できるOSSであり、GatewayやHTTPRouteに対してAuthPolicyを定義できる。重要なのは、そのポリシーを「どこに適用するか」である。

まずプラットフォーム側は、GatewayそのものにAuthPolicyを適用する。これにより、トークン検証が必須となり、認証情報を持たないリクエストはすべて拒否される。松田氏はこの狙いを「クベ子がポリシーを作り忘れても、最低限のセキュリティが担保された状態を作りたい」と説明した。設定忘れが事故につながらない構造を、親であるプラットフォーム側が用意するのである。

一方、トークンの発行と検証を担うのがKeycloakだ。Keycloakと連携することで、クライアントクレデンシャルフローによるアクセストークン取得と、そのトークンを用いた認証付きアクセスが可能になる。こうしてGateway APIの入口に「必ず認証がかかる」状態を作ることで、クベ子が自由にアプリケーションを公開しても、無防備なAPIが外部に晒されることはなくなる。セキュアバイデフォルトとは、注意を促すことではなく、失敗できない構造を先に用意することなのだ。

クベ子に任せても壊れないAPI公開とプラットフォームエンジニアリングの答え

GatewayにAuthPolicyを適用することで、API公開の入口には必ず認証がかかる状態が整った。しかし、それだけでは十分ではない。Gatewayはクラスタ全体に影響するため、ここで許可する条件を細かく絞り込みすぎると、他のNamespaceや別のプロダクトにも影響が及んでしまう。そこで最後に示されたのが、HTTPRoute単位でのAuthPolicy適用である。

HTTPRouteはクベ子が管理するリソースであり、その範囲であれば自由にポリシーを変更できる。悪意のあるクライアントからのアクセスを拒否し、特定のクライアントだけを許可する、といった制御も、HTTPRouteに対してAuthPolicyを適用することで完結する。Gatewayレベルでは「最低限の安全」を保証し、HTTPRouteレベルでは「クベ子自身の判断」を反映する。この二層構造によって、過干渉でも放任でもない状態が成立した。

この設計が示しているのは、単なるセキュリティ実装のテクニックではない。プラットフォームチームは「事故が起きない前提条件」を用意し、プロダクトチームはその枠の中で自由に試行錯誤できる。責任の境界が技術によって明確化されているため、どこまでが自分の裁量なのかがわかりやすい。

まとめ

松田氏は今回紹介した取り組みを次のように言葉にした。「プラットフォーム側で守るべきところは最初から固めておいて、その上でプロダクト側に安心して任せられる状態を作りたかったんです。Gateway APIがその境界をきれいに分けてくれて、Kuadrantを使うことで『何も設定しなくても危なくならない』状態を作ることができました」。

クベ子に任せても壊れない。その状態を実現するための設計こそが、プラットフォームエンジニアリングが目指すべき現実解の一つであるというわけだ。