Cloudflare R2 Data Catalogは、read-only API tokenでnamespace一覧、table load、queryを実行できるようになった。これまでread clientにもAdmin Read & Writeを渡していた構成では、query engineがtableやmetadataを変更できる過大権限になっていた。今後はwriterとreaderのcredentialを分離できる。

何が変わったか

Admin Read only tokenでR2 Data Catalog readとR2 storage readを行える。table作成・drop・transaction commitなどのwrite operationは引き続きAdmin Read & Writeが必要である。DuckDB、PyIceberg、R2 SQLなどread主体のengineへ最小権限tokenを配布できる。

変更前後の差

従来はcatalog operation全体にread-write tokenが必要だった。変更後はcatalog metadataとunderlying objectのread権限だけを持つtokenを作れる。ただしcatalogが発行するSigV4 credentialは、認証に使ったtokenのR2 storage permissionを継承する。catalogだけread-onlyでもstorageがwriteなら、objectへ書き込める余地が残る。

誰に影響するか

R2 Data CatalogをBI、notebook、ad hoc query、ETL validation、RAG dataset inspectionなどへ接続する組織が対象である。shared read-write tokenを複数engineへ配っている場合は優先的にrotationすべきである。

期限

強制移行期限はない。既存tokenは動作するが、過大権限を放置する理由はない。credential inventoryとrotation windowを設定する。

必要な対応

reader、writer、maintenance serviceを分離し、それぞれのtokenを別にする。read-only tokenにはWorkers R2 Data Catalog ReadとWorkers R2 Storage Bucket Item Readを付与する。secret manager、CI、notebook、local configから旧tokenを回収し、audit logでwrite attemptがないか確認する。

実装・移行手順

  1. catalogへ接続する全engineと用途をinventory化する
  2. readとwrite workloadを分類する
  3. read-only API tokenをbucket scopeで作成する
  4. staging engineへtokenを設定する
  5. list、load、queryが成功することを確認する
  6. create、drop、commitが拒否されるnegative testを行う
  7. production readerを切り替える
  8. 旧shared tokenを失効する

失敗しやすい点

catalog permissionだけreadにする、storage permissionをwriteのまま残す、writerとreaderが同じsecret名を使う、negative testをしない、token scopeをaccount全体にする、といった問題が起きやすい。vended credentialの継承関係を見落とさないことが重要である。

リスク

read-only化が不完全でmetadata fileを変更できる、rotation漏れで旧tokenが残る、query engineが一時tableを作る設計で失敗する、maintenance jobまでread-onlyにして停止するリスクがある。用途ごとに実際のoperationを確認する必要がある。

評価方法

  • read-write token保有client数
  • read-only移行率
  • unauthorized writeの拒否率
  • token scopeのbucket限定率
  • rotation未完了secret数
  • query成功率とlatency
  • audit log上のwrite operation

ロールバック

readerが想定外のwriteを必要とする場合は、即座にshared Admin tokenへ戻さず、専用read-write tokenを限定scopeで発行する。旧tokenを再有効化せず、新credentialを短期で配布し、必要operationを特定して権限設計を修正する。

編集部分析

今回の変更は機能追加というより、data lakeの権限境界を現実的に分離できるようにしたものだ。read-onlyという表示だけでは不十分で、catalogとstorageの二層を同時に確認する必要がある。negative testを権限レビューの標準にすべきである。

実務チェックリスト

  • [ ] readerとwriterをinventory化した
  • [ ] catalogとstorageの両方をread-onlyにした
  • [ ] bucket scopeを限定した
  • [ ] write拒否のnegative testを行った
  • [ ] 旧shared tokenを失効した
  • [ ] audit logを確認する
  • [ ] maintenance jobを別credentialにした

一次情報