Cloudflare Workers が Access ポリシーを直接サポート — 内部アプリをデフォルトでロックダウン

Cloudflare は Workers に有意義なアップグレードを提供しました。Cloudflare Access を Worker またはアカウント内のすべての Worker に直接適用できるようになり、内部アプリケーションがデフォルトで会社のログインの背後に置かれます。各開発者が自分のデプロイをロックダウンするのを忘れずに頼る必要はもうありません。

以前は、Access ポリシーはホスト名に紐付けられていました。複数のドメインで到達可能な Worker がある場合、各ドメインで個別に Access を設定する必要がありました。1 つでも見逃すと、そのドメインが公開されてしまいます。現在は、ポリシーが Worker 自体に紐付けられ、関連するすべてのドメイン（カスタムドメイン、ルート、workers.dev サブドメイン、プレビュー URL）をカバーします。

3 つのレベルの制御が可能です：

• アカウントレベルのポリシー： 一度設定すると、アカウント内のすべての Worker（現在および将来）がデフォルトでプライベートになります。プレビュー URL のみ、本番トラフィック、またはその両方にスコープを設定できます。
• Worker レベルのポリシー： アカウントの残りに影響を与えずに、単一の Worker をロックダウンします。
• バイパス： 公開すべき Worker がある場合、その特定の Worker でアカウント全体のポリシーを上書きできます。

内部プラットフォームを運営するチームには、便利なトリックがあります。Workers for Platforms のディスパッチ Worker に Access ポリシーを設定すると、それを介してデプロイされたすべての Worker がデフォルトでプライベートになります。Cloudflare は、このパターンを示す 内部サイトテンプレート もオープンソース化しました。

JWT の苦労なしでコード内の ID

Access が Worker を保護している場合、ctx オブジェクトを介して認証されたユーザーのメール、名前、グループをコード内で直接取得できます。JWT の解析、署名の検証、クレームの抽出はもう不要です。

export default {
  async fetch(request, env, ctx) {
    if (!ctx.access) {
      return new Response("Access required", { status: 403 });
    }

    const identity = await ctx.access.getIdentity();
    const email = identity?.email ?? "unknown";

    return new Response(`Hello, ${email}`);
  }
};

ローカル開発では、wrangler.jsonc で認証済みユーザーをシミュレートできます：

{
  "access": {
    "dev": {
      "aud": "my-app",
      "identity": { "email": "admin@company.com" }
    }
  }
}

これにより、毎回デプロイして完全な Access ログインフローを経由することなく、ユーザーごとの動作をテストできます。

内部：FL2 がそれを可能にする

この機能は、Cloudflare の Rust ベースのモジュラープロキシである FL2 上に構築されています。Access をホスト名ではなく Workers にアタッチするために、Cloudflare は Workers のルーティングを Workers の実行から分割し、ルーティングロジックを Access の前に実行するように移動する必要がありました。古い NGINX/Lua ベースの FL1 システムでは、そのリファクタリングはリスクが高かったでしょう。FL2 の厳格なモジュールシステムと静的に宣言されたフェーズにより、安全になり、コンパイラが壊れた相互作用を検出できるようになりました。