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_authnのルールはpathを主体に判定するため、複数のドメインを収容する構成でもドメインを区別せず一律に判定します。
特定のドメイン向けのルールを追加したい場合には、match.headers
で:authority
ヘッダーをフィルタに追加します。
rules:
- match:
prefix: /
headers:
- name: ":authority"
string_match:
exact: sub.example.com
requires:
provider_name: examplecom
複数ルールの順序には意味があり、ドメインを指定するケースの多くはルールセットの前の方に定義することになるでしょう。
まとめ
JWTの実装には総合的なアプローチが必要です。中でも検証プロセスが完備することは主目的の1つであり、OpenIDやOAuthを実装するうえで重要なパーツです。
同じレイヤの有力実装であるnginxと比べてJWT検証ではenvoyがリードしていると言えます。
また、envoyはコンテナのサイドカー構成など多階層の導入が比較的ポピュラーであるため、一部のPathにのみルールを適用する構成も可能でしょう。
Chuma Takahiro