Cloudflare Workers を丸ごと守れる新 Access 機能が来たよ!
やっほー、しぃちゃんだよ! 今日は Cloudflare Workers のセキュリティ周りで、地味だけどすごく便利なアップデートを見つけちゃったよ。「Worker を守るのがこんなに簡単になるの!?」ってびっくりしたから、みんなにも紹介するね!
Cloudflare Changelogなにが発表されたの?
Cloudflare の Changelog で、Cloudflare Workers に Cloudflare Access を適用する新しい方法が 2 つ発表されたよ。
- Worker 1 つ、またはアカウント内の全 Worker に、まとめて Access のポリシーをかけられるようになったの
- 対象を絞って「プレビューのみ」「本番も含めて」保護範囲を選べる
今までどうだったの?
今までは、1 つの Worker が Route・カスタムドメイン・workers.dev URL の複数の入り口を持っていると、それぞれを個別に Access アプリケーションへ登録して、ドメインや Route が変わるたびに手動で同期しなきゃいけなかったんだって。地味に面倒だし、更新し忘れて保護が漏れちゃう心配もあったみたい。
これで何が変わるの?
新しい仕組みでは、ポリシーを Worker 自体にひも付けられるようになったよ。そうすると、その Worker に紐づくドメインやプレビュー URL が増えたり変わったりしても、自動で保護対象に含まれるの。もう一覧を手でメンテしなくていいんだね。
さらに、アカウント単位で「新規・既存を問わず全 Worker をデフォルトで非公開」にする設定もできるようになったよ。公開のままにしたい Worker だけ、個別にバイパスを追加すれば OK。サインインの許可範囲は、Cloudflare アカウントのメンバーシップ・メールアドレス・メールドメインから選べるみたい。より細かいポリシーを作りたいときは、Zero Trust の管理画面から編集できるよ。
深く潜ってみよう
Access が有効な Worker では、認証済みリクエストに ctx.access が自動で付くようになったよ。ctx.access.getIdentity() を呼ぶだけで、サインインしたユーザーの email・name・groups が取れるから、自前で JWT を検証するコードを書かなくてよくなるの。
export default {
async fetch(request, env, ctx) {
if (!ctx.access) {
return new Response("Access did not run", { status: 401 });
}
const identity = await ctx.access.getIdentity();
return Response.json({ aud: ctx.access.aud, email: identity?.email });
},
};
ローカル開発でも wrangler dev のまま認証フローを試せるように、wrangler.jsonc に access.dev の設定を書けるようになってるよ。
{
"access": {
"dev": {
"aud": "my-app",
"identity": { "email": "admin@example.com" }
}
}
}
ポリシーの一覧は、ダッシュボードの Workers & Pages にある Access タブからまとめて見たり管理したりできるよ。Workers API 経由での設定変更にも対応してるみたい。
まとめ
- Worker 単体、またはアカウント全体に Access のポリシーをまとめてかけられるようになった
- ドメインや Route が増減しても、ポリシーが Worker にひも付くから自動で追従する
ctx.access.getIdentity()で、認証済みユーザーの情報が JWT 検証なしに取れるwrangler.jsoncの設定でローカル開発中も認証フローをテストできる
社内向けの管理画面やステージング環境を Cloudflare Workers で運用してる人には、かなり刺さるアップデートだと思うよ!