【連載第2回】PagerDuty Runbook Automation と Amazon EC2 を連携して運用を自動化する：AWS セキュリティ・権限設定編

はじめに

運用現場の作業を安全かつ効率的に自動化する PagerDuty Runbook Automation（以下、RBA） と Amazon EC2 の連携チュートリアル。全3回でお届けする本連載の第2回目です。

第1回：基盤構築および Runner セットアップ編
第2回：AWS セキュリティ・権限設定編（本記事）
第3回：ノード連携とジョブ実行編

前回の第1回では、RBA のプロジェクト作成から、ジョブを代行実行する「Runner」の構築と自動起動設定までを行いました。

今回は、RBA と AWS 環境を連携させる上で最も重要となる「セキュリティおよび IAM 権限の設定」について解説します。アクセスキー（シークレットキー）を直接発行・管理するのではなく、AWS のベストプラクティスである External ID（外部 ID）を用いた IAM ロールによる信頼関係 を構築し、セキュアな自動化基盤を作っていきましょう！

【Step 1】操作される側（Amazon EC2）の権限準備

まずは、自動化ジョブの「ターゲット」となる Amazon EC2 側の準備を行います。
RBA からの命令は AWS Systems Manager（SSM）を経由して届くため、Amazon EC2 自身が SSM と通信できる権限を持っている必要があります。

1. Amazon EC2 用の IAM ロール作成とアタッチ

AWS マネジメントコンソールから IAM 画面を開き、以下の手順でロールを作成します。

信頼されたエンティティタイプ: 「AWS のサービス」を選択し、ユースケースで「EC2」を選択します。
許可ポリシーを追加: 検索バーに AmazonSSMManagedInstanceCore と入力し、チェックを入れてアタッチします。
ロール名: 任意の名前（例：EC2-SSM-Managed-Role）を入力して作成します。
対象となる Amazon EC2 インスタンスの画面を開き、「セキュリティ」>「IAM ロールを変更」から、作成したロールをアタッチします。

2. SSM エージェントの確認

操作対象の Amazon EC2 インスタンス内で、SSM エージェントが正常に稼働しているかを確認します。（※Amazon Linux 2023 には標準でインストールされています）

ps aux | grep ssm-agent

プロセスが起動していることが確認できたら、操作される側の準備は完了です。

💡 参考：公式ドキュメント（AWS Systems Manager の IAM ロール設定）
ステップ 4: Systems Manager の IAM インスタンスプロファイルを作成する | AWS 公式

【Step 2】操作する側（RBA）のための IAM ロール作成

次に、RBA（操作する側）が AWS 環境を操作するための権限を作ります。
ここでは RBA コンソールから「連携に必要な情報」を取得し、それをもとに AWS 側で IAM ロールを作成するという手順を踏みます。

1. RBA コンソールで連携情報を確認する

まずは RBA の画面を開き、AWS プラグインの設定画面へアクセスします。

対象のプロジェクトを開き、左メニューの Project Settings > Edit Configuration をクリックします。
Plugins タブを選択し、+ Plugin Config をクリックします。
Plugin Group の一覧から AWS を選択します。
画面に RBA の AWS アカウント ID と External ID が表示されます。この2つの値をメモしておきます。

2. AWS 環境で RBA 用の IAM ロールを作成する

AWS コンソールの IAM 画面に戻り、RBA 用のロールを新規作成します。

信頼されたエンティティタイプ: 「AWS アカウント」を選択します。
別のアカウント: 先ほど RBA コンソールでメモした「RBA の AWS アカウント ID」を入力します。
オプション: 「外部 ID を要求する」にチェックを入れ、メモした「External ID」を入力します。

3. 許可ポリシーの設定

RBA から SSM 経由でコマンドを実行できるよう、必要な権限を付与します。

マネージドポリシーのアタッチ: AmazonSSMManagedInstanceCore を検索してアタッチします。
インラインポリシーの作成: ロール作成後（または作成時）に、以下の JSON をコピーしてインラインポリシーとして追加します。

※ の部分は、ご自身の AWS アカウント ID（12桁の数字）に置き換えてください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "ssm:SendCommand",
            "Resource": [
                "arn:aws:s3:::*",
                "arn:aws:ssm:*::document/AWS-RunShellScript",
                "arn:aws:ssm:*::document/AWS-RunPowerShellScript",
                "arn:aws:ec2:*::instance/*"
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "ssm:ListCommands",
                "ssm:ListCommandInvocations",
                "ssm:GetCommandInvocation"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "ec2:Describe*",
            "Resource": "*"
        }
    ]
}

💡 Tips: 上記のポリシーには ec2:Describe* を含めています。これは RBA 側から Amazon EC2 のインスタンスステータスをチェックできるようにするためです。また、自作のスクリプトを実行したい場合は、Resource に arn:aws:ssm:*::document/AWS-RunRemoteScript の権限も追加してください。

ロール名（例：PagerDuty-RBA-Integration-Role）を入力して作成を完了し、作成された IAM ロールの ARN を控えておきます。

【Step 3】RBA と AWS の連携設定（プラグインの認証設定）

AWS 側の受け入れ準備が整いました。RBA コンソールに戻り、控えておいた IAM ロールの情報を AWS プラグインに設定します。

RBA コンソールで対象のプロジェクトを開き、左下の Project Settings から Edit Configuration を開きます。
Plugins タブを開き、Step 2 で情報を確認した AWS プラグインの設定画面を再度表示します。
Role ARN: の欄に、Step 2 で控えた AWS 側の「IAM ロールの ARN」を貼り付けます。
Default Region: 操作対象のリージョン（例：ap-northeast-1）を入力します。
画面下部の Save ボタンをクリックして設定を保存します。

💡 参考：公式ドキュメント（AWS Integration for Runbook Automation）
AWS Plugins Overview | Rundeck Docs

【Step 4】ノードエクゼキューター（実行経路）の設定

最後に、RBA がノード（Amazon EC2）に対して「どのような経路でコマンドを実行するか」を指定します。
デフォルトの SSH 接続ではなく、SSM 経由で実行するように設定を変更します。

再度、対象プロジェクトの Project Settings から Edit Configuration を開きます。
Default ノードエクズキュータ（または Default Node Executor）のタブを開きます。
実行方式のプルダウンメニューから AWS / SSM / Node Executor を選択します。（※すでに選択されている場合はそのままで問題ありません）
画面下部の Save ボタンをクリックして設定を保存します。

💡 注意点: このノードエクゼキューターの設定を変更し忘れると、ジョブを実行した際に従来の SSH で接続しようとしてしまい、コマンドの送信に失敗します。非常に重要な設定ですので、忘れずに変更しておきましょう！
💡 参考：公式ドキュメント（Cross Account SSM の設定手順）
Orchestrating across AWS accounts using Systems Manager | Rundeck Docs

これでお互いのシステムが安全に通信し、SSM 経由で命令をやり取りできるようになりました！

アイレットエンジニアの視点：アクセスキーではなく External ID を使う理由

今回、IAM ユーザーの「アクセスキー（アクセスキー ID とシークレットアクセスキー）」を発行して RBA に登録する方法はあえて避けました。

1. セキュリティのベストプラクティスに準拠するため

アクセスキーは固定の認証情報であるため、万が一漏洩した際のセキュリティリスクが高く、定期的なローテーションといった運用負荷も発生します。一方、IAM ロールと External ID（外部 ID）を用いたクロスアカウント連携を利用すれば、認証情報を外部に持たせることなく、RBA という特定のサービスからのアクセスのみを安全に許可できます。これは AWS が推奨するセキュリティのベストプラクティスでもあります。

2. 「IAM ロールの混同」や「コンソールの行き来」による混乱を防ぐため

実は、私自身が最初にこの連携を試した際、最も躓いたのが権限周りの設定でした。
「RBA（操作する側）用の IAM ロール」と「Amazon EC2（操作される側）用の IAM ロール」を混同してしまい、どちらのリソースに何の権限が必要なのかが分からなくなることが多々ありました。さらに、RBA のコンソールと AWS コンソールを何度も行き来しながら設定を行うため、作業の途中で「今、何のための設定をしているんだっけ？」と迷子になりやすかったのです。

本記事の手順を「Amazon EC2 側の準備」「RBA 側のロール作成」「認証情報の登録」と明確にステップを分け、コンソールの行き来が順番通りになるよう構成したのは、まさにこの経験があったからです。

一見すると IAM ロールの設定は複雑に感じますが、この記事の順番通りに進めていただければ、過去の私のように混乱することなく、スムーズかつセキュアに連携基盤を構築できるはずです！

おわりに

今回は全3回シリーズの第2回として、Amazon EC2 側の権限準備と、External ID を用いたセキュアな RBA・AWS 間の認証設定を行いました。
アクセスキーを使わない連携は、エンタープライズの運用環境において非常に重要なセキュリティ要件となります。

次回はいよいよ最終回です。今回設定した権限を使って、RBA 上に Amazon EC2 ノードを動的に読み込み、実際に自動化ジョブを作成・実行する「ノード連携とジョブ実行編」をお届けします。お楽しみに！

【連載第2回】PagerDuty Runbook Automation と Amazon EC2 を連携して運用を自動化する：AWS セキュリティ・権限設定編

はじめに