Cloudflareは、Cloudflare Access for Workersの提供開始を発表しました。これは、Accessポリシーを1つのWorkerアプリケーション、またはアカウント内のすべてのWorkersアプリケーションに直接結び付けられるツール群です。この連携により、開発者がそれぞれ個別にアクセス制御を設定することを覚えておく必要なく、アプリケーションはデフォルトで企業のログイン認証の背後に置かれます。
今回の取り組みは、AIツールの支援によって従業員がより速くアプリケーションを構築・デプロイできるようになっている状況を背景としています。Cloudflareは、この速度によって、内部アプリケーションや非公開データが誤ってパブリックインターネット上に公開される可能性もあると考えています。そのため、新しいツールは、Workers上でホストされるアプリケーションの保護をデプロイプロセス自体の一部にするよう設計されています。
アクセス方法にかかわらずアプリケーションを保護
WorkerでAccessを有効にすると、Cloudflareはアプリケーションコードにリクエストが到達する前に認証を適用します。ユーザーがカスタムドメイン、パス、workers.devのサブドメイン、プレビューURLのいずれを介してアプリケーションにアクセスしても適用されます。
従来、Accessの設定はホスト名単位で行われていたため、ユーザーがWorkerにアクセスできる各ドメインについて個別のポリシーを作成する必要がありました。新しいカスタムドメインを追加する場合は、まずポリシーを更新しなければならず、そうしなければそのドメインは認証なしでアクセス可能になっていました。現在は、ポリシーがWorker自体に結び付けられるため、関連するドメインとURLが自動的に保護されます。
必要に応じて保護範囲を選択できます。
- workers.devのURLやプレビューに使用するカスタムドメインなど、プレビューURLのみを保護する。
- カスタムドメイン、パス、workers.devドメイン、プレビューURLを含む、アプリケーションに関連付けられたすべてのホスト名を保護する。
アカウントレベルのデフォルトポリシー
多数のWorkersアプリケーションを管理するチームは、Accessポリシーをアカウントレベルで一度設定できます。これにより、すべての既存および将来のアプリケーションが作成時点から非公開になり、ポリシーがプレビューURLのトラフィック、プロダクションのトラフィック、またはその両方を対象とするかどうかを指定できます。
プレビューのみの設定は、プロダクション環境では公開しておきたい一方で、開発中のバージョンが公開されるのを防ぎたいアプリケーションに適しています。Cloudflareでは、公開される想定の特定のWorkerについて、アカウントポリシーを上書きすることもできます。
包括的なポリシーを必要としない場合は、1つのWorkerに直接Accessを適用できます。Workerのインターフェースに新しく追加されたAccessタブには、そのアプリケーションに適用されているポリシーが表示されます。複数のポリシーが存在する場合は、より具体的なポリシーが優先され、順序はホスト名ポリシー、Workerポリシー、アカウントポリシーとなります。
アプリケーションコード内のユーザーID
Accessでは、メールアドレス、名前、グループなど、アプリケーションに各リクエストを送信したユーザーのIDも確認できます。Cloudflareによると、このデータはコンテンツのパーソナライズ、権限の適用、ユーザーごとのアクティビティ記録に利用できます。
ユーザーID情報はWorkerのコンテキストオブジェクトctx内、具体的にはctx.accessを通じて表示されます。アプリケーションはctx.access.getIdentity()を呼び出して認証済みユーザーのIDを取得でき、トークンの解析、署名の検証、クレームの抽出など、JSON Web Tokenの検証を手動で実装する必要はありません。
Accessは組織が現在利用しているIDプロバイダーとの連携に対応しており、特定のメールアドレス、メールドメイン、グループに基づいてアクセスを制限することもできます。エージェントについては、サービストークンによってアクセスを付与できます。
ローカルテストと内部プラットフォーム
wrangler devを使用し、wrangler.jsoncファイルにAccess設定を追加して認証済みユーザーをシミュレートすることで、IDの挙動をローカルでテストできます。これにより、開発者は設定内のメールアドレスを切り替え、デプロイ前に各ユーザーに適切なコンテンツが表示されることを確認できます。
Cloudflareは、ドラッグ＆ドロップ方式で静的サイトを公開できる内部プラットフォームのオープンソース例も公開しました。公開された各Workerはデフォルトで非公開になります。この構成はWorkers for Platformsを活用しており、名前空間内にあるアプリケーションのトラフィックは、1つの共有Workerを経由します。そのWorkerにAccessポリシーを設定すると、そこから公開されたアプリケーションはデフォルトで非公開になります。
提供状況と技術構成
この機能はダッシュボードを通じて全員が利用できるようになっており、開始するためのCloudflare Access for Workersのドキュメントも提供されています。新機能はFL2を基盤としており、FL2はRustで構築され、Cloudflareのエッジインフラストラクチャ上で動作するモジュール型のプロキシです。
ホスト名ではなくWorkerレベルでAccessを適用できるようにするため、CloudflareはWorkersのルーティングを実行処理から分離し、ルーティングロジックをAccessより前の段階に移しました。同社によると、明確に分割されたモジュールと順序付けられた段階を持つFL2のシステムが、この変更の管理に役立ちました。各部分が入力と出力を固定的な形で宣言するため、再構築中に段階間の不適切な相互作用をコンパイラーで検出できました。