はじめに
Azure Automation の Runbook から Azure Database for PostgreSQL Flexible Server を停止・再起動しようとした際、
「自分は共同作成者を持っているのに、なぜ実行できないのか？」
「Automation 共同作成者を付ければよいのか？」
「Runbook に付与すべき権限は誰に対して、どこに付けるのか？」
という点で混乱したため、整理した内容をまとめます。
結論：権限を付ける相手とロールを間違えない
今回のポイントは、次の2つです。
Runbook を実行する主体は、Azure Portal を操作しているユーザーではありません。
実際に Azure リソースを操作するのは、Automation アカウントのマネージド ID です。
そのため、作業者自身が 共同作成者（Contributor） や User Access Administrator を持っていても、
Runbook のマネージド ID に対象リソースへの権限が付与されていなければ、Runbook からの停止・再起動は失敗します。
また、付与するロールも間違えやすいポイントです。
選ぶべきロールは「Automation 共同作成者」ではありません。
対象 PostgreSQL Flexible Server、または対象リソースグループに対する「共同作成者（Contributor）」です。
整理すると、以下の通りです。
| 項目 | 正しい指定 |
|---|---|
| 権限を付与する相手 | Automation アカウントのマネージド ID |
| 付与するロール | 共同作成者（Contributor） |
| 付与先スコープ | 対象 PostgreSQL Flexible Server、または対象リソースグループ |
| 間違えやすいロール | Automation 共同作成者 |
つまり、今回の正解は次です。
Automation アカウントのマネージド ID
↓
対象 PostgreSQL Flexible Server または対象リソースグループ
↓
共同作成者（Contributor）を付与
まず押さえるべき登場人物
今回の権限設計では、登場人物を分けて考える必要があります。
| 区分 | 対象 | 必要な権限 |
|---|---|---|
| ロールを付与する人 | 作業者、管理者 | User Access Administrator または Owner |
| Runbook の実行主体 | Automation アカウントのマネージド ID | 対象リソースへの Contributor |
| 操作対象 | PostgreSQL Flexible Server | 停止・再起動されるリソース |
特に混乱しやすいのは、自分に Contributor があることと、Runbook のマネージド ID に Contributor があることは別物、という点です。
Azure RBAC では、ロール割り当ては「セキュリティ プリンシパル」「ロール定義」「スコープ」の組み合わせで成立します。セキュリティ プリンシパルにはユーザー、グループ、サービス プリンシパル、マネージド ID が含まれます。
「自分は”Contributor（共同作成者）”なのにできない」理由
Azure の Contributor は、リソースの管理権限を持つ強いロールです。
しかし、Contributor には Azure RBAC のロール割り当て権限は含まれません。
Microsoft Learn では、Contributor はすべてのリソースを管理するフルアクセスを付与する一方で、Azure RBAC のロール割り当てはできないと説明されています。
つまり、以下のように整理できます。
| 自分の権限 | できること | できないこと |
|---|---|---|
| Contributor | リソースの作成・変更・削除など | 他の ID への RBAC ロール割り当て |
| User Access Administrator | Azure リソースへのアクセス管理 | リソース操作そのものは別ロール次第 |
| Owner | リソース管理 + ロール割り当て | ほぼ全権限 |
Azure Automation のマネージド ID にロールを割り当てるには、Microsoft.Authorization/roleAssignments/write が必要であり、代表例として User Access Administrator または Owner が挙げられています。
付与すべきロールは「Automation 共同作成者」ではない
Azure Portal のロール検索で「共同作成者」と入力すると、以下のようなロールが多数表示されます。
- 〇 共同作成者
- × Automation 共同作成者
- × Data Factory 共同作成者
- × Log Analytics 共同作成者
- × API Management サービス共同作成者
- × Application Insights コンポーネント共同作成者
ここで選ぶべきなのは、単に「共同作成者」と表示される Contributor です。
※Automation 共同作成者 は、Automation アカウント自体を管理するためのロール。
※そのため、Automation アカウントではなく、操作対象である PostgreSQL Flexible Server 側に対して Contributor を付与する必要があります。
カスタムロールを使わない場合の現実的な解
この記事では「カスタムロールを作らず、簡潔に済ませる」ことを前提にします。
その場合は、以下の付与が分かりやすいです。
対象：Automation アカウントのマネージド ID
ロール：共同作成者（Contributor）
スコープ：対象 PostgreSQL Flexible Server
または、複数リソースを同じ Runbook で管理する場合は、以下も選択肢になります。
対象：Automation アカウントのマネージド ID
ロール：共同作成者（Contributor）
スコープ：対象リソースグループ
Contributor はリソース管理のフルアクセスを付与しますが、Azure RBAC のロール割り当てはできません。
そのため、Runbook の実行主体に対して「対象リソースを操作させる」用途では、実務上シンプルな選択肢になります。
推奨する付与スコープ
可能であれば、スコープは狭くします。
おすすめ順は以下です。
| 優先度 | スコープ | コメント |
|---|---|---|
| 1 | 対象 PostgreSQL Flexible Server | 最も範囲が狭い |
| 2 | 対象リソースグループ | VM や関連リソースも同じ Runbook で操作する場合 |
| 3 | サブスクリプション | 原則避ける |
RBAC のスコープは、管理グループ、サブスクリプション、リソースグループ、リソースの各レベルで指定できます。
Azure Portal での設定手順
1. Automation アカウントのマネージド ID を確認する
- Azure Portal で Automation アカウントを開く
- ID を開く
- システム割り当て済み が有効になっていることを確認する
- オブジェクト ID または名前を確認する
Azure Automation のシステム割り当てマネージド ID を有効にすると、Automation アカウントを表すサービス プリンシパルの principalId が割り当てられます。
2. 対象 PostgreSQL Flexible Server を開く
- Azure Portal で対象の Azure Database for PostgreSQL Flexible Server を開く
- アクセス制御 (IAM) を開く
- 追加 → ロールの割り当ての追加 を選択する
3. ロールを選択する
検索欄では、以下に注意します。
NG:
Automation 共同作成者
Data Factory 共同作成者
Log Analytics 共同作成者
OK:
共同作成者
Contributor
ポイントは、**サービス名が前についていない汎用の「共同作成者」**を選ぶことです。
4. メンバーを選択する
メンバーには、ユーザーではなく以下を指定します。
Automation アカウントのマネージド ID
ここを自分のユーザーにしてしまうと、Runbook 実行時には権限が不足します。
まとめ
Azure Automation Runbook で Azure Database for PostgreSQL Flexible Server を停止・再起動する場合、権限設計のポイントは以下です。
- Runbook の実行主体は Automation アカウントのマネージド ID
- 対象 PostgreSQL Flexible Server に対して、そのマネージド ID へ権限を付与する
- 組み込みロールで簡潔に済ませるなら Contributor を付与する
- Automation 共同作成者は、今回の PostgreSQL 操作用ロールではない
- ロールを付与する人には User Access Administrator または Owner が必要
- Runbook 公開前に削除系コマンドが混ざっていないか確認する
RBAC は「誰が」「どのロールで」「どのスコープに対して」操作するかを分けて見ると整理しやすいです。
Automation の場合は特に、操作している自分ではなく、Runbook の ID に権限が必要という点を忘れないようにしたいです。