この記事はGrafana Advent Calendar 2025の19日目の記事です。
1. はじめに
はじめまして、AMBL株式会社でクラウドエンジニアをやっています @magurodon です。
技術ブログもGrafanaも初心者な私ですが、最近業務でGrafana Cloudの権限周りで整理しておきたい内容があったので、備忘録として残しておきます。
■この記事のターゲット
数か月前の私と同様に、OrganizationレベルとStackレベルの権限の設定分けがわかっていない人向けです。
■先に結論
組織の管理者（Admin）以外は、Organizationレベルでは「None（権限なし）」で招待し、Stackやそのリソースごとに個別に権限設定するのが良さげです。
2. 前提環境と課題
■前提環境
- プラン: Grafana Cloud Pro
- スタック数: 2つ以上（プロジェクトが増えるごとに増加中）
- ユーザー: 複数のプロジェクトメンバーが混在
■抱えていた課題
Grafana Cloudを利用し始めた当初、プロジェクトAのメンバーとプロジェクトBのメンバーが同じOrganization内に混在していました。
何も考えずにユーザーを招待してしまうと、「プロジェクトAの人がプロジェクトBのスタックを見えてしまう（最悪編集できてしまう）」 という状態になり、セキュリティ的にも運用リスク的にも困ったことになりました。
これは「スタック（Stack）」という概念と「組織（Organization）」という概念の階層構造を正しく理解できていなかったのが原因です。
3. Grafana Cloudの権限構造の理解
Grafana Cloudには大きく分けて2つの権限レイヤーが存在します。
ここでの基本ロールとその役割を整理できれば、少なくとも根性で個別に権限分けを行えるようになります。
① Organizationレベル（ポータル）
契約やユーザー課金、スタックの作成などを管理する上位の層です。
ここでのロールは以下のようになっています。
| ロール名 | 概要 | できること |
|---|---|---|
| Admin | 管理者 | 支払い管理、ユーザー招待、スタック作成など全権限 |
| Editor | 編集者 | 組織配下のスタックの閲覧・設定が可能 |
| Viewer | 閲覧者 | 読み取り専用で組織配下のスタックにアクセス可能 |
| None | 権限なし | 【重要】組織・スタック両方において何も権限を持たない状態 |
② Stackレベル（各Grafanaインスタンス）
実際にダッシュボードを作ったり、アラートを設定したりする層です。
普段私たちが「Grafana」として触っている画面の権限です。
| 基本ロール名 | 概要 |
|---|---|
| Admin | インスタンスの管理者でデータソース設定などが可能 |
| Editor | ダッシュボードの作成・編集が可能 |
| Viewer | ダッシュボードの閲覧のみ可能 |
| No roles assigned | 何も権限を持たない状態 |
■権限の波及(重要！！！！)
Organizationレベルで「Editor」や「Viewer」権限を与えてしまうと、そのOrganization配下のすべてのStackに対して、自動的にOrganizationと同等の権限が波及してしまいます（Stack側ではOrganizationで設定した権限より下の権限は設定できなくなる）。
そこで重要になるのが、「Organizationレベルでは権限を絞り、Stackレベルで個別に付与する」というアプローチです。
4. 実際の設定手順
具体的な設定手順を紹介します。
(スクリーンショットは個人用FreeプランのGrafana Cloud)
手順1: ユーザーを招待する（Portal画面）
Grafana Cloud Portalの Members > Invite New Member からメンバーを招待します。
この時、Roleの設定で 「None」を選択します。
ここでAdminやEditorを選ばないのがポイント
手順2: 招待されたユーザーの状態確認
この状態だと、ユーザーはOrganizationには所属していますが、OrganizationにもStackアクセスできない（見えない）状態になります。これで「見えすぎてしまう」問題は解決です。
ほとんどのサービスが閲覧不可で、ダッシュボードも何も見えない
手順3: 特定のStackに権限を付与する
アクセスさせたい特定のStackやリソースの設定から権限を設定します。
ここの権限の設定方法はこちらのSIOSさんの記事が参考になりました。
ここで初めて 「Editor」 や 「Viewer」 などのロールを割り当てます。
これで、「プロジェクトAの人はスタックAの特定のダッシュボードだけ」「管理者は全部」というような住み分けが完了しました。
※ちなみに、ダッシュボードなどデータソースがあるものは、データソースの権限も設定しないとスクショのようにNo data表示になるので注意
5. 最後に
■まとめ
- 複数スタック運用時は、Organizationレベルでの権限付与は慎重に
- 基本はNoneで招待し、必要なスタックに必要な権限だけ渡す（最小権限の原則）
■今後の展望
現在は手動でポチポチ設定していますが、メンバーが増えてくると管理が大変です。
今後はチーム単位での権限管理や、IdP連携（Google Workspaceなど）を用いたアクセス管理に挑戦していきたいです。