チームメンバーと AI エージェントに Workers への適切なアクセス権を付与する

チームだけでなく、今では agent までもが Cloudflare の Developer Platform 上でアプリケーションを構築するようになり、適切なアクセス制御は安全なリリースに欠かせない。何より避けたいのは、必要以上の権限を持つ agent が本番環境に変更を加えてしまうことだ。そこで、特定のチームメンバーや agent に特定の Worker だけへのアクセスを許可できるようになった。これにより、そのアプリケーションだけを変更でき、アカウント内の他のリソースには触れられない。さらに、できることを細かく制限するための4つのロールも追加した。

ロール	できること	向いている場面
Metadata Read-Only	リソースの一覧、設定、可観測性データ（メトリクス、ログ、trace など）を閲覧できるが、プロダクトの内容にはアクセスできない。	チームメンバーや agent に、問題調査のために可観測性データへアクセスさせたいが、
ソースコードにはアクセスさせたくない場合。
Content Read-Only	Worker のコードや D1 データベースの内容など、プロダクトの内容を読み取れるが、変更はできない。	チームメンバーや agent にソースコードへアクセスさせたいが、
Worker には一切変更を加えさせたくない場合。
Editor	プロダクトの内容を読み書きし、設定を更新できる。リソースの作成や削除はできない。	チームメンバー、agent、CI/CD システムに Worker への変更をデプロイさせたいが、
その Worker を削除されないようにしたい場合。
Admin	リソースを完全に制御できる。作成、名前変更、削除、他のユーザーへのアクセス権付与も含む。	チームメンバーや agent に Worker への完全なアクセス権、削除の権限まで与えたいが、
アカウント内の他の Worker やリソースへのアクセスは与えたくない場合。

新しいロールは本日からすべての顧客が利用できる。特定のユーザーに割り当てれば、そのユーザーが dashboard にログインしたときに、アクセス権を与えた Worker だけが表示される。あるいは、適切な権限スコープを持つ API token を作成して agent に渡せば、そのアプリケーションだけにアクセスさせられる。

以下は、Worker ごとに権限を付与する API token を作成する例だ。

チームの働き方に合わせたロール設計

これらのロールを定義するにあたって、私たちは適切なバランス点を探った。ロールの範囲が広すぎれば、意図を超えたアクセス権を付与せざるを得ず、最小権限の原則は成り立たない。かといって細かい権限に分解しすぎると、どれを与えればいいのか分からなくなる。最終的に4つのロールに落ち着いた。ある人物や agent に与えたいアクセスレベルに対応する。リソースをデバッグするには十分だが内容は見せない、内容は読めるが変更はできない、変更はできるがリソースは削除できない、そしてリソースを完全に管理できる、の4つだ。

このロール群は、D1、R2、KV を含む他の Developer Platform プロダクトにも展開し、段階的にリソースレベルのアクセス制御を導入していく予定だ。各ロールは3つのスコープのいずれかで適用できる。「metadata read-only」を例にすると、レベルごとの効果は次のとおり。

• Developer Platform レベル：すべての Developer Platform リソースのメタデータにアクセスできる。
• プロダクトレベル：あるプロダクト配下のすべてのリソース、たとえばすべての Worker のメタデータにアクセスできる。
• リソースレベル：特定の1つのリソース、たとえば特定の1つの Worker のメタデータにアクセスできる。

ロールとスコープの組み合わせが、誰が何をでき、どのリソースに対してできるのかを決める。いくつかの一般的な Workers のワークフローで見てみよう。

ソースコードを晒さずにデバッグする

問題を調査するには、エンジニアや agent が Worker の設定、メトリクス、ログ、trace を確認し、どこで失敗しているのか突き止める必要があるかもしれない。ただし Worker のコードを見る必要も、変更する必要もない。

Metadata Read-Only なら、Worker のソースコードを晒すことなくこれらの情報を取得できる。GraphQL API で分析データをクエリし、ログにアクセスし、trace やその他の可観測性データを確認できる。これらのリクエストが返すのは、アクセス権を持つ Worker のデータだけだ。agent のスコープが1つの Worker に限定されていれば、Cloudflare API を使って問題を調査でき、そのアカウント内の他の Worker のデータは見えない。

こうしたロールをより多くの Developer Platform プロダクトに広げていく際も、この分離は維持する予定だ。ユーザーは D1 データベースや R2 バケットの設定と可観測性データを閲覧できるが、データベース内の値やバケット内のファイルは読み取れない。

コードをレビューするが、変更はしない

同僚やコードレビュー agent が、Worker 内で動くコードを読む必要が出ることがある。動作を把握したり、バグを追ったり、変更提案をレビューしたりするためだ。だが、だからといって新しいコードをデプロイしたり、Worker の設定を更新したりできていいはずはない。

Content Read-Only はこの分離を実現する。Worker のコードを取得してレビューできるが、変更もデプロイもできない。権限を単一の Worker に限定すれば、読めるのはその Worker のコードだけで、アカウント内のすべての Worker のコードには及ばない。

他の Developer Platform 製品が対応すれば、Content Read-Only の挙動はまったく同じになる。D1 データベース、KV 名前空間、R2 バケットに保存されたデータを読めるが、変更はできない。

CI にデプロイさせつつ、全権は渡さない

CI/CD ワークフローに必要なのは、自分がデプロイするアプリへのアクセスだけだ。別の Worker を書き換えたり、自分がデプロイした Worker を削除してアプリを落としたりできてはいけない。

Worker 単位のアクセス制御を使えば、ワークフローごとに専用の API token を持たせ、Editor role を付けて 1 つの Worker に限定できる。ワークフローの設定を誤ったり token が漏れたりしても、影響範囲は抑えられる。その Worker に変更をデプロイすることはできても、削除はできず、アカウント内の他のアプリにも触れない。

Admin 権限で Worker を削除する

Admin は付与できる最も高い権限レベルで、アプリを削除できる。このロールも単一の Worker に限定できるので、権限がアカウント内のすべての Worker に広がることはない。

ルーティングとカスタムドメイン

Worker にルートやカスタムドメインを追加すると、どのホスト名をそのアプリにルーティングするか指定できる。たとえば Wrangler ファイルの次の設定は、example.com へのトラフィックをその Worker に送る:

{
 "route": {
 "pattern": "example.com/*",
 "zone_name": "example.com"
 }
}

このルートを変更すると、本番トラフィックが別の場所に流れたり、アプリがそのまま落ちたりしかねない。Worker へのアクセス権だけでは足りない理由がここにある。ルートやカスタムドメインを追加・変更・削除するには、その Worker の Editor 権限に加えて、その zone の Workers Routes 権限が要る。

より広い zone アクセス権ではなく Workers Routes 権限を求める形にすることで、Worker へのトラフィックの到達経路は管理できても、そのドメイン下の無関係な設定には手を出せない。

とはいえ、ルートを設定してしまえば、デプロイがその接続を変えない限り、接続先の zone やリソースへのアクセス権がなくても Worker の新バージョンをデプロイできる。CI/CD システムはアプリをデプロイでき、ドメインやデータベース、ストレージへのアクセス権までは持たなくて済む。

Workers の権限は Durable Objects にも及ぶ

Durable Objects に専用のロールや権限はない。ある Durable Object へのアクセス権は、それを実装する Worker へのアクセス権で決まる。誰かに Durable Object へのアクセスを許可するには、対応する Worker のロールを付与する。

Metadata Read-Only なら、Durable Object のメトリクス、ログ、trace にはアクセスできるが、オブジェクトに保存されたデータには届かない。Durable Objects Data Studio は保存データを直接クエリして変更できるため、これを使うには Editor ロールが必要になる。

足りない権限を、あなたとあなたの agent に明示するエラー

狭い権限を付与すると、そのうち誰かが権限のない操作を試す。そのときエラーは、必要な権限を示してくれないと、手が止まってしまう。

いまでは API が漠然とした 403 Forbidden を返す代わりに、該当する API ドキュメントへのリンクを添える。そこから、そのリクエストに具体的にどの権限が必要か分かる。おかげで、あなたも agent も必要なアクセスレベルを正確に判断でき、必要以上の権限を渡さずに済む。

提供開始

Worker 単位のアクセス制御がすべてのお客様にご利用いただけるようになりました。Cloudflare dashboard で設定するか、API または Terraform から設定できます。

特定の Worker へのアクセスをチームメンバーに付与するには、Manage Account > Members に移動して該当メンバーを選び、必要なロールと Worker のスコープを指定したポリシーを作成します。

ユーザーグループでチームのアクセス権を管理する

同じチームやプロジェクトで複数のメンバーに同じアクセス権が必要な場合は、一人ずつ権限を割り当てるのではなくユーザーグループを作成します。ポリシーをそのグループに割り当て、対象のメンバーを追加すれば、グループ内の全員が自動的にそのポリシーを継承します。

Workers の従来の権限を置き換える

これまで Workers へのアクセスは以下のロールと権限で管理していました。Developer Platform 全体で統一されたロール体系を進めているため、今後は新しいロールの使用を推奨します。

従来のロール	Member/API Token	推奨する新しいロール
Workers Platform (Read-Only)	Member	Developer Platform Content Read-Only
Workers Platform Admin	Member	Developer Platform Admin
Workers Scripts Read	API Token	Content Read-Only
Workers Scripts Edit	API Token	Editor
Workers CI Read	API Token	Content Read-Only
Workers CI Edit	API Token	Editor
Workers Observability Read	API Token	Metadata Read-Only
Workers Observability Edit	API Token	Editor
Workers Observability Telemetry Edit	API Token	Editor
Workers Tail Read	API Token	Metadata Read-Only

従来のロールと権限に廃止予定日はありません。既存の割り当ては引き続き有効で、廃止する場合には事前に告知します。それでも新しいロールへの移行を推奨します。細かいリソース単位のアクセス制御に対応しているのは新しいロールだけだからです。

今後の予定

Worker 単位のアクセス制御は、Cloudflare 開発者プラットフォーム全体で認可モデルをより一貫させるための第一歩です。

今後は同じリソース単位のアクセス制御を、KV 名前空間や D1 データベースなど、より多くの開発者プラットフォーム製品に広げていきます。アカウント内のすべての bucket やデータベースへのアクセス権を付与する必要はなくなり、本当に必要なリソースだけに適切なロールを組み合わせて限定できるようになります。

Workers 向けに導入したこのロール体系は、これらのリソースにもそのまま適用されます。

使い始めるには開発者ドキュメントをご覧ください。