Cloudflare Workers デプロイをクライアント単位で分離する権限設計

Cloudflareの4つのWorkerロールを使うと、1つの共有デプロイ認証情報にもクライアント単位の境界を設けられます。2026年9月15日以降、制作会社は、より広いポリシーによって権限が拡張されていない限り、Cloudflare Workers デプロイを担うクライアントのCIジョブに既存Worker 1つのデプロイだけを許可し、削除権限やアカウント内の他のWorkerへのアクセスは渡さずに済みます。

Cloudflare Workers デプロイで重要なのはスコープ

権限は2つの要素で決まります。ロールは「何ができるか」、スコープは「どこでできるか」を定めます。

Cloudflareでは、チームメンバー、User Group、エージェント、APIトークンに対して、Workerロールと個別Workerのスコープを組み合わせられるようになりました。同じロールを全Workerに適用することもできますが、今後はその必要がありません。

一見すると、小さな管理機能に思えるかもしれません。しかし、1つのCloudflareアカウントで複数クライアントを運用する制作会社や代理店にとって、引き渡しの設計が変わります。クライアントAのデプロイ認証情報を、クライアントAのWorkerだけで止められるからです。

9月15日のリリースは全顧客が利用でき、ダッシュボード、API、Terraformから設定できます。

Workersのロールリファレンスに記載されたロールは、次の4つです。

この分割に意味があるのは、デバッグ、コードレビュー、コードのリリース、サービスの削除が、それぞれ別の仕事だからです。すべてを同じ認証情報にまとめる必要はありません。

従来のCloudflare Workers権限はアカウント単位でした。新しいモデルでは、Developer Platform全体、全Worker、または既存Worker 1つに適用範囲を設定できます。Workers製品単位のポリシーは、現在と将来のすべてのWorkerを対象にします。個別Workerのポリシーが対象にするのは、選択したWorkerだけです。

ただし、構造上の制約が1つあります。まだ存在しないWorkerをスコープに指定することはできません。新規Workerの作成には、引き続き製品単位のAdminが必要です。

クライアントへの引き渡しはどう変わるか

クライアントごとにWorkerを1つずつホストしている小規模な制作会社を考えてみます。デプロイ用ワークフローに必要なのは、client-a-apiの新バージョンを公開することです。Workerの新規作成、そのWorkerの削除、client-b-checkoutへのアクセスは必要ありません。

今回のリリース以前は、Cloudflareが現在レガシーと位置付ける一般的なWorkers向けCI権限は、アカウント単位でした。選択肢は、広すぎる認証情報を受け入れるか、クライアントを別アカウントへ分離するかです。個別Workerのスコープによって、もう1つの方法が加わりました。アカウント構成は変えず、デプロイトークンにはclient-a-apiだけのEditorを付与します。

Worker単位の制御は全顧客が利用できるため、サブスクリプションの計算は変わりません。変わるのは運用上の計算です。

ただし、このモデルには重要なトレードオフが含まれていません。クライアント別にスコープを限定した12個の認証情報は、共有トークン1つよりも発行、保管、ローテーションの対象が増えます。利点は認証情報が減ることではありません。認証情報の不具合や漏えいが起きたとき、調査すべきプロジェクトの範囲を狭められることです。

Workerを1つだけ運用し、デプロイ権限を共有していない個人開発者には、大きな変化はありません。プラットフォーム担当チームに全Workerの管理権限を意図的に持たせている組織も同様です。この機能が効くのは、複数の担当者、クライアント、自動化ジョブが1つのCloudflareアカウントを共有しつつ、影響範囲までは共有すべきでない場合です。

クライアントのデプロイジョブに必要十分な権限を与える

最初の引き渡しに適しているのは、安定したRouteまたはCustom Domainを持つ既存Workerです。これなら、Workerの作成とドメイン変更をデプロイジョブから切り離せます。

1. 1

   ロールを選ぶ前にジョブの役割を言語化する

   まず、1文で定義します。「このワークフローは、既存のclient-a-api Workerの新バージョンをデプロイします。」

   この定義なら、個別WorkerスコープのEditorが適切です。ジョブが新規Workerを作成する場合は、製品単位のAdminが必要です。RouteまたはCustom Domainの追加、変更、削除も行うなら、対象となる各ゾーンにWorkers Routes Writeも必要です。

2. 2

   アカウント所有のAPIトークンを作成する

   CloudflareでManage Account > Account API Tokensを開き、アカウント所有トークンを作成します。スコープをSpecified Workersに設定してclient-a-apiを選び、ロールにはEditorを指定します。

   ワークフローには、個人のユーザートークンではなくアカウント所有トークンを使います。Cloudflareはアカウント所有トークンを、長期運用する連携のためのサービスプリンシパルと位置付けています。作成者が退職しても、デプロイが止まらない設計にできます。トークンの作成または更新には、Super Administrator権限が必要です。

3. 3

   そのトークンでWranglerを実行する

   トークンはデプロイシステムのシークレットストアに保存します。CloudflareがWrangler向けに案内している環境変数は次のとおりです。

   export CLOUDFLARE_API_TOKEN="<YOUR_API_TOKEN>"
   export CLOUDFLARE_ACCOUNT_ID="<YOUR_ACCOUNT_ID>"
   npx wrangler deploy

   既存Worker用に設定済みのプロジェクトから実行します。wrangler loginで代用することはできません。現在、そのOAuthフローはきめ細かな権限設定に対応していないためです。

4. 4

   切り替えを確認してから広い権限を外す

   新しいトークンを使って影響のないバージョンをデプロイし、対象のWorkerが更新されることを確認します。トークンに製品単位のWorkersロールや、無関係なリソースのスコープがないことも確かめます。

   その後、旧来の広いデプロイ用シークレットをワークフローから削除します。テスト中に両方の認証情報を残すのは妥当ですが、テスト後も併用すれば、せっかく設けた境界が機能しません。

通常のデプロイに必要な引き渡しは、これで完了です。Editorには、そのWorkerの更新、アップロード、デプロイ、ロールバック、名前変更、シークレット管理が含まれるため、クライアントのジョブはこれらを実行できます。一方でWorkerは削除できず、個別Workerのポリシーから他のWorkerへアクセスすることもできません。

4つのジョブに合う4つのポリシー

証跡の収集だけを担うサポートエージェント

デバッグ用エージェントには、対象WorkerのMetadata Read-Onlyを付与します。ソースコードを読んだりサービスを変更したりせず、設定、メトリクス、ログ、トレースを確認できます。

これにより、証跡収集のワークフローが、知らないうちにコードレビューやデプロイのワークフローへ広がるのを防げます。同じロールで、そのWorkerに対するwrangler tailも実行できます。

クライアントの実装をレビューする外部開発者

外部委託の開発者には、クライアントのWorkerにContent Read-Onlyを付与します。デプロイ済みのソースと設定は確認できますが、変更やデプロイはできません。

レビューの境界が明確になるため、稼働中の内容を理解する必要があるという理由だけでEditorを渡さずに済みます。

クライアント専用のCIパイプライン

アカウント所有トークンに、既存Worker 1つだけのEditorを付与します。バージョンの公開とロールバックはできますが、Workerの削除や他のWorkerへのアクセスはできません。

認証情報がスタッフ個人ではなくワークフローに属するため、制作会社からクライアントへ引き渡す用途には特に適しています。クライアント業務でブラウザエージェントも運用しているなら、Cloudflareの許可済みホスト制御が境界の別の側面、つまりブラウザのアクセス先を制御します。今回のリリースが制御するのは、デプロイを行う主体が変更できるWorkerです。

ライフサイクル変更を担うプラットフォーム管理者

削除権限が本当に必要な担当者または自動化に限り、Adminを付与します。Workerを作成する管理者には製品単位のAdminを残し、完成したWorkerの日常運用は、より狭いポリシーへ引き渡します。

これにより、ライフサイクル管理と日常的なリリース作業を明確に分けられます。デプロイジョブに、クライアントサービスを作成・廃止する担当者と同じ権限は不要です。

境界は狭くなるが、完全な分離ではない

利点は確かですが、「1つのWorkerだけ」という説明を単純化しすぎると危険です。

Durable Objectsも同様に注意が必要です。Durable Objectsには独立したロールやスコープがなく、実装元のWorkerのアクセス権を継承します。Metadata Read-Onlyでは保存データにアクセスせず、Durable Objectのメトリクス、ログ、トレースを確認できます。一方、Editorは、SQLiteベースのDurable ObjectをData Studioから照会または変更するためにCloudflareが定める権限条件も満たします。

Routesも別の境界です。既存のRouteまたはCustom Domainを変えずに新バージョンをデプロイするだけなら、Editorで足ります。その接続を変更するには、対象となるすべてのゾーンにWorkers Routes Writeも必要です。またCloudflareによると、Custom Domainsは現在、Worker単位のロールに対応していません。

最後に、Cloudflareの権限は加算されます。直接付与した狭いポリシーによって、User Groupから継承した広いポリシーが打ち消されることはありません。Members画面には直接権限が表示されますが、Groupから継承したポリシーはGroupsタブで確認する必要があります。この確認を省くと、画面上は意図した狭いポリシーが見えていても、実効権限は広いままという事態が起こり得ます。

今すぐ対応すべきチーム

1つのアカウントで複数クライアントのWorkerを運用し、担当者、エージェント、CIジョブのいずれかが、Worker 1つの作業に対して全Workerの権限を持っているなら、今週中に対応する価値があります。既存Workerがあり、通常のデプロイでドメイン接続を変更しない環境ほど効果が明確です。

ワークフローがWorkerを作成する、RouteやCustom Domainを変更する、またはバインディング先のデータ製品へ直接アクセスする場合は、トークンを絞る前に待つべきです。先に必要な操作を洗い出さなければ、次回のデプロイが途中で失敗します。

Workerへのアクセスを共有していない、Workerを1つしか運用していない、またはアカウント全体を担うプラットフォームチームにデプロイを意図的に集約している場合は、影響ありません。

月曜日にまずやること

最初に、既存クライアント1社のCIデプロイで使う権限ポリシーを変更します。アカウント所有トークンをEditorにし、そのWorker 1つだけへスコープを限定します。影響を与えられるすべてのバインディングと継承対象のDurable Objectを一覧化し、直接ポリシーとGroupポリシーを確認したうえで、RouteまたはCustom Domainを変更せずにデプロイします。

正常に完了したら、旧来の全Worker向けシークレットを削除します。この1回の切り替えで実効性のある境界ができ、次のクライアントにも繰り返せるパターンが手に入ります。

プラットフォームの変更点をわかりやすく整理した運用ノートをさらに読みたい方は、ニュースレターにご登録ください。