PagerDuty Runbook Automation（RBA）設定ガイド

Runbook Automation（RBA）は、PagerDuty の定型業務を自動化するツールとして登場し、今ではインシデント管理の運用高度化に欠かせない存在となりました。2024年は特に多くの反響があり、さまざまなサポートを行う機会がありました。

特に初期セットアップやジョブの実行に関する質問が多かったため、今後、それらの手順を設定ガイドとしてまとめていこうと思います。スムーズな導入の参考になれば幸いです。

まず、本記事では、Runbook Automation の導入を検討している方向けに、トライアルの申し込みからユーザーやグループの作成と権限付与までを解説します。

# Runbook Automation とは
PagerDuty Runbook Automation （RBA）は、IT 運用タスクを自動化する強力なツールです。自動診断や復旧、サーバーのプロビジョニング、定期メンテナンスなど、様々な運用タスクを自動化することで、運用コストの削減、人的ミスの軽減、サービス品質の向上を実現します。

従来の手作業による運用では、時間と労力がかかり、ミスが発生しやすいという課題がありましたが、RBAを導入することで、これらの課題を解決し、安定したシステム運用が可能になります。

Runbook Automation の基本情報については、PagerDuty のブログ [ルーティン業務を劇的に改善する「Runbook(ランブック)」とは？](https://www.pagerduty.co.jp/blog/what-is-a-runbook/#PagerDuty%C2%AE_Runbook_Automation_%E3%81%AB%E3%82%88%E3%82%8B%E8%87%AA%E5%8B%95%E5%8C%96) にて触れておりますので、併せてご参照ください。

# トライアル環境の利用開始
※すでにトライアル環境をお持ちの方はこちらのステップはスキップしてください。

Runbook Automation のトライアルを申し込むには [公式ウェブサイト](https://www.rundeck.com/sign-up/runbook-automation) からアクセスし、申し込みフォームには、氏名、メールアドレス、会社名などの情報を入力します。必須項目は赤色のアスタリスクでマークされていますので、必ず入力してください。

![Screenshot 2025-02-17 at 13.23.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/d20b26fb-40e3-41dd-a692-e93081bc3702.png)


件名が "PagerDuty Runbook Automation trial activation" のメールが届くので、メール内のリンクからパスワードを設定し、ログインしてください。（ユーザーIDはAppAdmin）

メールには以下の内容が記載されています。

1. パスワードは 数字・特殊文字を含む10文字以上 にする必要がある
2. 最大 10人のフルユーザー が利用可能
3. トライアルアカウントは30日間 利用可能
4. Automated Diagnostics Project に含まれる 事前構築済みのジョブテンプレート の使用を推奨
5. RBAの[ドキュメント](https://docs.rundeck.com/docs)（英語のみ）について
6. サポートについて（英語のみ）

特に No.4 についてログイン後、サンプルの Project と ジョブテンプレート があらかじめ用意されていることが分かります。そのため、一からジョブを作成せずにすぐに試すことができます。

![Screenshot 2025-02-17 at 13.49.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/8917bff2-b9cc-4a02-9d47-4a5f4105933c.png)


# ユーザーの管理
それでは、管理コンソールに AppAdmin でログインして、初期設定を行っていきます。

まずRBAにおいて、ユーザーや権限周りはどのように管理するのか、その考え方について簡単にまとめます。

### ユーザー管理の概要
- ユーザーのログインと権限付与の仕組みがある
- ログインの仕組みは、ビルトインの認証（Local User / Group）、LDAP、SSO など
- 権限付与は Access Control Policy (ACL) Policy にて設定
- ACL は YAML形式のポリシーファイルで定義
- その他、User Class や User Role という仕組みもある

**参考情報**
- [ユーザー管理の概要について](https://docs.rundeck.com/docs/learning/getting-started/users-overview.html) 


### ユーザーの種類
<dl>
  <dt>ローカルユーザー（Built-in Users）</dt>
  <dd>Manage Local User で管理</dd>
  <dd>Local Group を利用してグループ分けできる</dd>
  <dt>外部認証</dt>
  <dd>LDAP/Active Directory連携やSSO（Okta, Azure Active Directoryなど）が利用可能</dd>
  <dd>ログイン後は User Class 内に登録される</dd>
  <dd>デフォルトでAppAdminがアサインされる（SaaSの場合）</dd>
  <dd>外部認証経由で登録されたユーザーはローカルグループに追加できない</dd>
</dl>

### User Class
- 特定のライセンスをユーザーに割り振る目的で使用
- ACLの上位セットとして機能するが、詳細な権限設定はACLにて管理する
- オンプレ版では、`Full User` と `Job Runner` クラスがある
- SaaS 版では、`AppAdmin` と `Job Runner` クラスがある

**参考情報**
- [ユーザークラス管理について](https://docs.rundeck.com/docs/manual/user-management/user-classes.html)

### User Role
- ACL 内で使用される属性であり、システム内で実行できるアクションやアクセスできるリソースを定義
- オンプレ版では、`opsadmin` と `fulladmin` などオンプレ特有のインフラ設定の変更（データベース設定、クラスタ管理など）に対しての権限をもつ
- SaaS版は、`appadmin` が最も高い権限を持つロール
- SaaS版でも、ACLの設定で`opsadmin` と `fulladmin` が表示されるが、設定しても`appadmin`の権限と同等となる（正直ちょっとわかりづらい）

**参考情報**
- [ビルトインのユーザーロールについて](https://docs.rundeck.com/docs/administration/security/default-users.html)
- [Self-hosted（オンプレ版）と SaaS 版での違いについて](https://docs.rundeck.com/docs/about/cloud/?utm_source=chatgpt.com#self-hosted-and-saas-differences)

### ACL (Access Control List) Policy
- RBA内の権限管理で利用する仕組み
- System Context Rule : プロジェクトに属さないすべてのアクセス（サーバー管理、グループメンバーシップ、複数のプロジェクトで使用する資格情報、プロジェクト自体へのアクセスなど）を管理
- Project Context Rule : プロジェクト内のアクセス（ノードやジョブへのアクセスなど）を管理
- User もしくは Group 単位で設定

**参考情報**
- [アクセス制御の概要について](https://docs.rundeck.com/docs/learning/getting-started/acl-overview.html)
- [Access Control Policy とは](https://docs.rundeck.com/docs/administration/security/authorization.html)


## ユーザーの追加
AppAdmin 以外のユーザーを追加します。右上の歯車マークを開き、**User Manager** からアクセスできます。
![Screenshot 2025-02-28 at 15.11.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/d6c76767-b3d9-4d5d-9d8b-99091c0aa74f.png)


**Manage Local Users** より [Add User] ボタンをクリックして、ユーザーを追加します。
username や Password などを入力します。必要に応じて Groups にチェックを入れて [Save] します。

![Screenshot 2025-02-28 at 15.18.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/bf21b267-0390-4bab-8da9-319edeaff4e7.png)


## ACL Policy の設定
次に、作成したユーザーにACL Policyを設定します。デフォルトで作成されている Local Group `admin` や `user` にユーザーを所属させることで、ログイン後ある一定の権限が付与された状態になりますが、もう少し細かいアクセス制御をした ACL Policy を作成したいと思います。

参考にしたのは以下の情報です。
[ACLレシピについて](https://docs.rundeck.com/docs/learning/howto/acls/)

では、**Group/Project Full Access** を作成したいと思います。
ACL Policy を設定する前に、以下の2点を先に完了させておく必要があります。

### Local Group の作成
サンプルコードを見ると、アクセスコントロールを **grp-sandbox-full** というグループに付与している箇所がいくつかあります。（例：`group: grp-sandbox-full`）そのため、コードをこのまま利用するのであれば、先に作っておく方がスムーズです。

Local Group は、歯車マーク→ User Manager → Manager Local Group にて新規作成できます。
 ![Screenshot 2025-02-28 at 15.37.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/9a412c48-501e-4e21-a2af-375b3626476b.png)

後ほどアクセステストを行うユーザー `takanogu` を **Selected** に追加しておき、[Save] で保存します。

### Project の作成
こちらもコード内に `project: prj-sandbox` と記載されている箇所がいくつかあるので事前に作成しておきます。左上の **Projects** から [+Create Project] で新規の Project を作成します。
![Screenshot 2025-02-28 at 15.34.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/048d25b2-45ab-4948-ac5d-e41d038dda3f.png)

Project Name を "prj-sandbox" とサンプルコードに合わせます。

![Screenshot 2025-02-28 at 15.35.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/e622b00c-a5b8-4b72-bfa7-b38a390fc3a9.png)

### Key Storage パスの確認
API Token や SSH 接続時の認証情報を安全に保管しておくために [Key Storage](https://docs.rundeck.com/docs/manual/key-storage/) を利用します。

ACL サンプルのコード内では、`path: keys/project/prj-sandbox` と表記されていますが、これは prj-sandbox Project 作成時に、専用の Key Storage が自動的に作成されるためです。

こちらは prj-sandbox に移動し、**Project Settings** から **Key Storage** をクリックします。
![Screenshot 2025-02-28 at 16.03.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/5f31927f-9c04-4938-ba1a-a3f98c7a2ca1.png)

このように Key Storage のパスが確認できます。

![Screenshot 2025-02-28 at 16.03.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/4d04ae16-59eb-4858-ad59-265c4f064ce6.png)

事前準備はこれでOKです。

### ACL Policy の作成
右上歯車マークから **Access Control** をクリックして、[＋Create ACL Policy] で新しく ACL Policy を作成します。

ACL Policy の Name を設定して、Rule を追加します。
ここで、[ACL Policy GUI](https://docs.rundeck.com/docs/administration/security/acl-policy-editor.html) 記載の通り、[+ New Rule] で1つずつルールを追加することが可能ですが、KB に掲載されている [サンプルコード](https://docs.rundeck.com/docs/learning/howto/acls/group-project-full.html#acl-code) をそのまま　**Editor** にコピペします。

![Screenshot 2025-02-28 at 15.37.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/193d12cc-8ec3-4ce5-9bd2-cd3fd9ee3848.png)

[Save] をクリックして、一覧画面にて追加されたことを確認します。

![Screenshot 2025-02-28 at 16.10.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/8b4d560b-7d26-4a88-914e-e7e99127d460.png)

### アクセス確認
実際に `takanogu` でログインしてみます。

![Screenshot 2025-02-28 at 15.38.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/4d1c2392-ed99-4546-b9f3-13eae361dd3e.png)

Project を開いてみると、作成した　Project のみが表示されます。
![Screenshot 2025-02-28 at 15.38.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/2c505894-e4ef-461e-a450-9c481808098f.png)

Project Settings　も含め設定が可能なようです。
![Screenshot 2025-02-28 at 15.39.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/455a4b4d-56f4-4b9d-9b41-3d450761e4c0.png)

今回のケースでは、Group 単位で ACL Policy を設定しましたが、User 単位でも設定できますので、いくつかのパターンをお手元でも試していただければと思います。
また、`admin` Group における ACL Policy のサンプルコードも記載がありますので、こちらもご参照ください。
- 参考情報：[admin.aclpolicy のサンプルコード](https://docs.rundeck.com/docs/administration/security/authorization.html#example)


## System Configurationの設定
最後に、System Configuration について簡単にご紹介します。ここでは、システム全体の動作に関する設定を行います。例えば、プラグインや SSO の設定、通知メールの設定、オンプレ (Self-hosted) 利用の場合は Runner 関連の設定などを管理できます。


![Screenshot 2025-02-28 at 16.10.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/d5e2fb9d-db35-42c2-9ba3-44032abf2d9d.png)

:::note info
Runbook Automation のKBを読むと、`rundeck-config.properties` などのファイルを編集して設定を有効にするような記載がありますが、SaaS版ではその構成ファイルを直接編集するのではなく、この **System Configuration** を編集をする必要があるので注意をしてください。
:::

# おわりに
Runbook Automation は、システム運用を自動化するための強力なツールです。トライアルを利用することで、その機能と効果を実際に体験できます。本記事が、Pagerduty Runbook Automation の導入を検討している方の参考になれば幸いです。