envoyのJWT認証

JWTについては、発行やリフレッシュなどライフサイクル全体を設計する必要がありますが、envoyは主要な機能であるJWTの有効性検証を提供しています。

対応アルゴリズムなどの概要は、 JWT Authenticationのページに解説があります。アルゴリズムの幅はミドルウェアによりまちまちですが、envoyは相当充実しています。

デフォルトでは、Bearer認証とGETのauth_tokenパラメータからトークンを取得する挙動となります。いずれも設定により変更は可能です。

JWT認証の設定例

JWT検証のconfigは、http_filterとして1レイヤ追加します。以下は設定例です。

        http_filters:
        - name: envoy.filters.http.jwt_authn
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication
            providers:
              examplecom:
                issuer: https://example.com
                local_jwks:
                  filename: /etc/jwk_public.json
            rules:
            - match:
                prefix: /protected
              requires:
                provider_name: examplecom
            - match:
                prefix: /
        - name: envoy.filters.http.router

末尾の行は、一般的なルーティングのフィルタです。定義するレイヤの参考であり、JWT向けの設定ではありません。

JWTフィルタのレイヤでは、主に2つのパートがあります。

  • providers: JWTのプロファイル定義。発行者マッチのためのissuerや、検証のための鍵を指定
  • rules: アクセスPATHごとに検証ルールを定義。ルーティングの定義とは別にJWTフィルタ用に独立した定義が必要

なお、検証用の鍵(この例ではlocal_jwks)は、JWKSの鍵セットである必要があり、単体の鍵を指定するとエラーになります。鍵の種類が何であるべきかは、選択したアルゴリズムによって異なります(これはJWTの仕様)。

rulesについては、requiresのパートで検証のクライテリアを指定します。上の/protected向けの設定では、issuerの一致を検証していますが、トークンの真正性や有効期限も合わせてチェックされます。

RequirementRuleには、他にもチェックのオプションがあります。 JWTのAPIリファレンスを参照してください。比較的簡潔にチェックできる属性は、issuerとaudiencesでしょう。
なお、requiresの定義のないpathについては、JWTの検証をしない挙動(アクセス可能)となります。

まとめ

JWTの実装には総合的なアプローチが必要です。中でも検証プロセスが完備することは主目的の1つであり、OpenIDやOAuthを実装するうえで重要なパーツです。
同じレイヤの有力実装であるnginxと比べてJWT検証ではenvoyがリードしていると言えます。

また、envoyはコンテナのサイドカー構成など多階層の導入が比較的ポピュラーであるため、一部のPathにのみルールを適用する構成も可能でしょう。

中馬崇尋
Chuma Takahiro