PagerDuty RBA 設定ガイド - ライセンス・ロール編

PagerDuty Runbook Automation（RBA）を導入する際、ユーザー管理の概念を正しく理解することは重要です。

前回の記事 [PagerDuty Runbook Automation（RBA）設定ガイド](https://qiita.com/t_noguchi/items/d561be31fbe98d9fc280) で軽く触れましたが、本記事では、RBA の User Class と User の違い、ライセンスの概念、そしてライセンスの付与・削除方法についてもう少し具体的に解説します。

# Local User と User Class
まず前回のおさらいです。

## Local User
**Manage Local Users** で、RBAのユーザーアカウントを管理できます。主にユーザーの追加や編集、所属する Local Group の設定、削除などを行うことができます。

![Screenshot 2025-03-12 at 13.47.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/f9b76c02-49fb-4f88-b46c-38a497b70b49.png)

## User Class
User に対して User Class を割り当てることで、アクセス制御とライセンス管理を強化しています。主なユーザークラスは以下の通りです。​

1. `AppAdmin` (SaaS版の場合）：RBA 環境への完全なアクセス権を持つユーザー
2. `Job Runner`：全プロジェクトでジョブの実行と出力の閲覧が可能だが、ジョブや他のリソースの変更はできない

デフォルトでは、ユーザーは`AppAdmin`に割り当てられますが、必要に応じて他のクラスに変更することが可能です。

![Screenshot 2025-03-12 at 13.55.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/b0a1e179-7350-4a8e-a776-df4a9b40afd8.png)

# ライセンスについて
PagerDuty Runbook Automation では、ユーザーごとに適用されるライセンスが必要になります。SaaS版では、`AppAdmin` および `Job Runner`　を購入できます。Trial 環境を利用した場合は、`AppAdmin` が **10ライセンス** 付与されており、それらのライセンスをユーザーに割り当てる必要があります。

## ライセンスの付与
**User Class** で `AppAdmin` をAssignすることでユーザーにライセンスを割り当てることができ、現在のアサイン状況や残りのライセンス数は以下の部分で把握できます。

![Screenshot 2025-03-12 at 13.54.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/2ac07800-8cf1-47bc-9cf7-1c923b7f9f20.png)

また、Actions から **Unassign**　をクリックすると、ライセンスをユーザーから外すことができます。
![Screenshot 2025-03-12 at 14.56.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/c9e62a5a-96e7-48a2-9380-c7c64e0059fd.png)


ユーザーの作成自体は、ライセンス数に関係なく作成でき、ACL Policy を Local Group を通じてアサインすることも可能です。ただし、ライセンスが付与されていないと下図のような表示となり、アクセス権限がない状態になります。

![Screenshot 2025-03-12 at 14.41.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/295ce34c-52d6-41a6-8050-07f42e76b89d.png)

ライセンスについての詳細については、歯車マークをクリックし、**License Info** からも確認ができます。

![Screenshot 2025-03-12 at 14.51.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/4bcd5c11-3543-4378-bd90-ba4685762b22.png)

## 自動アサイン機能
ライセンスを一度付与されたユーザーがライセンスを外された後にログインすると、自動的に **ライセンスが再割り当て（リアサイン）される機能** があります。

この機能は、**ライセンスに余剰がある場合** に動作し、管理者が誤ってライセンスを外してしまった際にも、ユーザーがログインすることで自動的に復旧できます。

そのため、ライセンスの割り当てを適切に管理するには、以下の対応が必要です：

- 余剰ライセンスをなくす：不要なユーザーのライセンスを外した後、他のユーザーに割り当てる
- 不要なユーザーのログインを防ぐ：不要なユーザーアカウントを削除する
- ログイン可能なユーザーを制限：`rundeck.security.requiredRole=role1,role2,role3` の設定を有効にし、特定の **Role (≒ Local Group)** に所属するユーザーのみログイン可能とし、ライセンスを外したユーザーは、ログイン可能な Local Group から除外する
参考：[Require Roles For Sign On](https://docs.rundeck.com/docs/administration/security/authentication.html#require-roles-for-sign-on)

運用ルールに応じて、上記のいずれか、または組み合わせた対策を実施してください。

### （補足）Require Roles For Sign On の設定
Require Roles For Sign On の設定は、歯車マークから **System Configuration** にアクセスし、下図のように　`rundeck.security.requiredRole=role1,role2,role3`　を追加することで有効になります。
`role1,role2,role3` の部分には具体的なRole名（Local Group名）を追加します。（例：`rundeck.security.requiredRole=admin,user,All_Project`)

![Screenshot 2025-04-02 at 11.24.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/c2d7ada7-07f9-4b2b-8e88-2ed7015f33e3.png)

有効後、このRole以外のユーザーでログインするとこのような表記になり、ログインできなくなります。

![Screenshot 2025-04-02 at 11.25.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/88a1f069-8a45-4fea-838a-f45ed7b3760a.png)

### AppAdmin は削除してよいか？
10ライセンスの割り振りを検討する際、デフォルトで作成される `AppAdmin` を削除してよいか？とご質問をいただくことがありますが、削除については奨励しておりません。
もし`AppAdmin`のライセンスを別のユーザーに割り当てたい場合は、`admin` ロールを付与された管理ユーザーを作成した後、 **User Class** から`AppAdmin`のライセンスを **unassign** してください。

# SSO 経由でのユーザー登録
SSO経由（Azure AD、Oktaなど）でログインし、登録されたユーザーは、上記のLocal User や Group と扱いが異なり、すべて **User Class** に登録されます。

例えば、Oktaであればこちらの [Single SignOn - Okta](https://docs.rundeck.com/docs/administration/security/sso/okta.html) にそって設定を進めます。

私のテスト環境では **System Configuration** で以下のように設定します。
![Screenshot 2025-04-02 at 14.35.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/0b45134f-2504-440e-adfe-f4805dbc9c71.png)


![Screenshot 2025-04-02 at 14.31.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/1014662e-c801-4ac4-8467-59e8832f8737.png)

OKTA経由でログインをします。

![Screenshot 2025-04-04 at 14.15.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/fd5548b1-2b05-4afb-ae0b-af01bd108044.png)

Login with Okta （上記 System Configuration　で追加したボタン）をクリックして、OKTAでのログインを完了します。

![Screenshot 2025-04-04 at 14.15.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/b5076519-d361-4cbe-8e09-22ed6bca103b.png)

Profile を見ると、所属しているグループ名に、OKTA のグループ名が反映されていることがわかります。
![Screenshot 2025-04-04 at 14.19.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/27eb8580-6606-4435-ba72-b080fe43b8b2.png)

OKTA グループ単位でアクセス管理を行う場合は、このグループ名（ここでは `okta-group-rba` ) に対して設定すると、SSOログイン後、適切なアクセス制御ができます。

![Screenshot 2025-04-04 at 14.22.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957400/df4f2b13-d840-42b8-88de-fedb009bd89f.png)


ここでは、OKTAの例を紹介しましたが、Azure ADについては、[Single SignOn (SSO) - Azure Active Directory](https://docs.rundeck.com/docs/administration/security/sso/azure-sso.html)に設定手順が載っております。

もし、Azure Groupを連携させ、RBAのACLをグループ単位で反映させたい場合は、`framework.plugin.UserGroupSource.AzureGroupSource.enabled=true` というプラグインを設定する必要があります。

参照：[Note: Azure Groups](https://docs.rundeck.com/docs/administration/security/sso/azure-sso.html#note-azure-groups)

# おわりに
本記事では、PagerDuty Runbook Automation のユーザー管理における **Local User と User Class の違い**、**ライセンスの概念と割り当て方法**、**SSO 経由でのユーザー登録**について解説しました。

RBA を適切に運用するには、ユーザーの権限管理やライセンスの適切な割り振りが重要です。特に、**不要なライセンスの管理**や**SSO との連携設定**を適切に行うことで、セキュリティを確保しながらスムーズな運用が可能になります。