【ITニュース解説】Protect Kubernetes Services with OAuth2 Proxy, Gateway API, Traefik, and Pocket ID

この解説では、Kubernetes上で動作するサービスを安全に保護するための認証システムを構築する方法について説明する。具体的には、新しいトラフィック管理の標準であるGateway API、エッジルーターのTraefik、認証プロキシのOAuth2 Proxy、そしてOIDCプロバイダーのPocket IDを組み合わせる。これまでのシステムではIngress-nginxという技術が使われていたが、Kubernetesが推奨するGateway APIに移行し、より柔軟で標準的な方法で認証フローを再構築する点が重要である。

Gateway APIは、Kubernetes環境における外部からのトラフィック（通信）を内部のサービスへ適切に振り分けるための、新しい標準的な仕組みだ。従来のIngressよりも高度なルーティングやポリシー設定が可能になる。この記事ではTraefikをこのGateway APIの実装として利用する。Traefikを選んだ理由は、Gateway API自体はブラウザベースのOIDC（OpenID Connect）ログインや外部認証フィルターといった機能までは標準化していないため、Traefik独自のMiddleware（ミドルウェア）という拡張機能を使ってこれらの認証機能を構築できるからである。もし別のGateway API実装（Envoy Gatewayなど）を使う場合でも、Gateway APIのリソース自体は変更せずに、認証部分のAdapter（アダプター）だけを調整すれば良いという柔軟性がある。

構築するシステムは、一つの親ドメインの下に三つの異なるHTTPSホスト名を持つ。一つ目はpocket-id.k8s.example.comで、これはPocket IDのユーザーインターフェース（UI）であり、OIDCプロバイダーとして機能する。二つ目はauth.k8s.example.comで、OAuth2 Proxyのエンドポイントを提供する。そして三つ目はwhoami.k8s.example.comで、これが外部からの認証が必要となる、保護されたデモサービスとなる。親ドメインを共通にすることで、OAuth2 Proxyはセッションクッキーを.k8s.example.comのような狭い範囲で共有でき、セキュリティと利便性を両立させる。

認証フローの具体的な流れは以下のようになる。まず、ユーザーがブラウザから保護されたサービス（whoami.k8s.example.com）へアクセスを試みる。このリクエストはTraefik Gatewayが受け取る。Traefikは、設定されたForwardAuthミドルウェアを通して、認証プロキシであるOAuth2 Proxyの/oauth2/authエンドポイントに、このリクエストの認証状態を問い合わせる。もしユーザーがまだ認証されていない（セッションクッキーがない）場合、OAuth2 Proxyは「401 Unauthorized」というエラーをTraefikに返す。

Traefikはこの401エラーを受け取ると、Errorsミドルウェアの機能により、そのエラーをブラウザへの「302 Found」（リダイレクト）に変換する。このリダイレクト先はOAuth2 Proxyのサインイン開始URL（/oauth2/sign_in?rd=...）である。ブラウザはリダイレクトに従い、OAuth2 Proxyにアクセスし、サインインプロセスを開始する。OAuth2 Proxyは、OIDCの認証リクエストをOIDCプロバイダーであるPocket IDに送信する。

Pocket IDはユーザーに対してパスキーなどの方法で認証を要求する。ユーザーがPocket IDで正常に認証されると、Pocket IDは認証コードを含んだコールバックをOAuth2 Proxyに返す。OAuth2 Proxyはこの情報を受け取り、ユーザーのセッションクッキーを設定し、ブラウザを元の保護されたサービス（whoami.k8s.example.com）に再度リダイレクトする。

ブラウザが再び保護されたサービスへリクエストを送信すると、今回はセッションクッキーが設定されているため、Traefikは再びOAuth2 Proxyに認証を問い合わせるが、今度はOAuth2 Proxyが有効なセッションを検知し、「202 Accepted」の応答と、ユーザー情報（Authorizationヘッダー、X-Auth-Request-User、X-Auth-Request-Email、X-Auth-Request-Groupsなどのヘッダー）をTraefikに返す。Traefikはこれらの認証情報をリクエストに付加し、保護されたサービス（whoami）に転送する。最終的に、whoamiサービスは認証されたユーザーに対してそのレスポンスを返し、ブラウザに表示される。

この認証フローにおいて、特に重要なのはTraefikのForwardAuthミドルウェアとErrorsミドルウェアの連携である。ForwardAuthはセッションの有無だけを確認し、401または202を返す役割を担い、Errorsミドルウェアがその401エラーを捕捉して、ユーザーをOAuth2 Proxyのログイン画面に自動的にリダイレクトさせる。この分離されたリダイレクトステップが、これまでのIngress-nginxを使った設定との大きな違いであり、よりクリーンな認証フローを実現する。

このシステムを構築する前の準備として、まず動作するKubernetesクラスター、kubectl、Helmといった基本的なツールが必要となる。また、*.k8s.example.com（実際の構築では制御するドメインに置き換える）のようなワイルドカードDNSレコードを、TraefikがHTTPSトラフィックを受け入れるエンドポイントに向けて設定する必要がある。Traefikが外部からアクセスできるようにするには、クラウド環境ではLoadBalancerタイプのService、ベアメタル環境ではMetalLBなどのロードバランサーが必要となる。すべてのログインコールバックとセッションクッキーはHTTPS通信を要求するため、TLS証明書も不可欠である。

具体的な構築ステップとしては、まずKubernetesの標準機能ではないGateway APIのCRD（Custom Resource Definitions）をクラスターにインストールする。その後、TraefikをHelmでインストールし、Gateway APIプロバイダーを有効にする。TraefikがGatewayClassを登録し、Serviceに外部IPアドレスが割り当てられたら、cert-managerを用いてワイルドカード証明書を取得し、Gatewayリソースを設定してHTTPSリスナーを作成する。

次に、OIDCプロバイダーとなるPocket IDをHelmでインストールし、HTTPRouteを作成してpocket-id.k8s.example.comとして公開する。Pocket IDの初期設定を完了させ、ユーザーの作成、開発者グループへの追加、そしてOAuth2 Proxy用のOIDCクライアント（リダイレクトURLはhttps://auth.k8s.example.com/oauth2/callback）の登録を行う。この際、クライアントIDとクライアントシークレット、およびグループクレームが重要になる。

最後に、OAuth2 ProxyをHelmでインストールする。Pocket IDのクライアントID、クライアントシークレット、そしてセッション用のクッキーシークレットをKubernetesのSecretとして作成し、OAuth2 Proxyの設定に利用する。OAuth2 ProxyはPocket IDをOIDCプロバイダーとして設定し、auth.k8s.example.comとしてHTTPRouteを介して公開する。

そして、保護したいサービス（デモ用のwhoamiアプリケーション）をDeploymentとServiceとしてデプロイする。このサービスへのアクセスには、先述のTraefikのForwardAuthミドルウェアとErrorsミドルウェアを適用したHTTPRouteを設定する。ForwardAuthミドルウェアはOAuth2 Proxyの/oauth2/authエンドポイントを呼び出し、Errorsミドルウェアは認証失敗時（401）にOAuth2 Proxyのログインページへのリダイレクト（302）を生成する。このミドルウェアの適用順序が、認証フローを正しく機能させるために非常に重要である。

これらの設定を適用した後、プライベートブラウザウィンドウを使用してhttps://whoami.k8s.example.comにアクセスし、認証フロー全体が正しく動作することを確認する。正しく設定されていれば、Pocket IDへのリダイレクト、認証、そして最終的にwhoamiサービスからの応答が表示されるはずだ。もし問題が発生した場合は、kubectl describe gateway,httproute -n oauth-exampleコマンドでGatewayやHTTPRouteのステータスを確認し、認証ログやミドルウェアの設定を検証すると良い。

この解説で示した手順は認証フローの基本を網羅しているが、本番環境でのデプロイメントには、より堅牢なシークレット管理、ネットワークポリシーによる通信制御、必要に応じたセッションストアの利用、そして詳細なトラステッドプロキシ設定など、さらなる考慮が必要となる。