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

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

Local User と User Class

まず前回のおさらいです。

Local User

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

User Class

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

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

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

ライセンスについて

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

ライセンスの付与

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

また、Actions から Unassign　をクリックすると、ライセンスをユーザーから外すことができます。

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

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

自動アサイン機能

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

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

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

余剰ライセンスをなくす：不要なユーザーのライセンスを外した後、他のユーザーに割り当てる
不要なユーザーのログインを防ぐ：不要なユーザーアカウントを削除する
ログイン可能なユーザーを制限：rundeck.security.requiredRole=role1,role2,role3 の設定を有効にし、特定の Role (≒ Local Group) に所属するユーザーのみログイン可能とし、ライセンスを外したユーザーは、ログイン可能な Local Group から除外する
参考：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)

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

AppAdmin は削除してよいか？

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

SSO 経由でのユーザー登録

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

例えば、Oktaであればこちらの Single SignOn - Okta にそって設定を進めます。

私のテスト環境では System Configuration で以下のように設定します。

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

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

Profile を見ると、所属しているグループ名に、OKTA のグループ名が反映されていることがわかります。

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

ここでは、OKTAの例を紹介しましたが、Azure ADについては、Single SignOn (SSO) - Azure Active Directoryに設定手順が載っております。

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

参照：Note: Azure Groups

おわりに

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

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