AWS SystemsManager Patch Managerでオンプレサーバを管理

目次

概要

AWS SystemsManager(以下SSM)にはPatchManagerというパッチの適用状況をスキャンし、必要があればインストールから再起動までを自動で行う機能があります。

この機能はEC2で構築したAWS上のインスタンスだけではなくオンプレ環境のサーバも対象にすることができます。

試験では、ハイブリッド環境下でのパッチ状況管理について問われることもあるため一通りの手順を確認し必要な操作を整理します。

PatchManagerの機能

PatchManagerは冒頭にも記載した通りSSMの機能の一つです。

SSMの管理下にあるマネージドノードに対してパッチベースラインを設定し、指定したタイミングで適用状況のスキャンやインストールと必要であれば再起動まで実施することができます。

マネージドノード
SSMAgentがインストールされ適切にアクティベートされているインスタンスのこと。
SSMで管理するためには、それらの設定を行いマネージドノードとしてSSMに登録されている必要がある。

パッチベースライン
どのレベルのパッチを自動で適用するかを設定するフィルターのようなもの。

詳細は省きますが、SSMにはRunCommand、Document、MaintenanceWindowといった複数の機能が含まれておりPatchManagerはそれらの機能を組み合わせて実行されています。

出典:https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2024_AWS-SystemsManager-PatchManager_0430_v1.pdf

パッチマネージャーの設定

前提

ローカル環境にはAlmaLinuxの仮想マシンを用意しました。

下記手順の実行環境は以下のとおりです。

ローカルPCmac mini AppleM2
仮想化ソフトVirtualBox7.1.10
仮想OSAlmaLinux9.7(aarch64)

AlmaLinuxは10.xもリリースされていますが、SSMでサポートされていないようなので実際にハンズオンする際は注意してください。(2026年1月時点)
サポートされているオペレーティングシステムとマシンタイプ

SSM Agentのインストール

SSMがデータを収集したり管理対象サーバでコマンドを実行するためのエージェントをインストールします。
AlmaLinux インスタンスに SSM Agent を手動でインストールする

sudo dnf install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_arm64/amazon-ssm-agent.rpm
ssm-agentインストール

アーキテクチャが異なる場合はlinux_arm64 の部分を変更してください。

稼働確認

インストールした時点で自動起動(enabled)が設定されています。

sudo systemctl status amazon-ssm-agent
ssm-agent稼働確認

AWS側でアクティベーションの作成

インストールしたSSMAgentと、SSMを紐づけるためのAWS側の操作です。

SSMのコンソールから、ハイブリッドアクティベーションを開き、「アクティベーションを作成する」をクリックします。

作成画面では、説明とこのアクティベーションで登録できるインスタンス数を指定します。

IAMロールはSSMがマネージドインスタンスに対して操作を行うためのものです。

アクティベーションの作成画面からも作成できますが、自前で作成することも可能です。

自動で作成した場合のIAMロールとポリシーは以下の通りです。

IAMロール

IAMポリシー

JSON

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:DescribeAssociation",
                "ssm:GetDeployablePatchSnapshotForInstance",
                "ssm:GetDocument",
                "ssm:DescribeDocument",
                "ssm:GetManifest",
                "ssm:GetParameter",
                "ssm:GetParameters",
                "ssm:ListAssociations",
                "ssm:ListInstanceAssociations",
                "ssm:PutInventory",
                "ssm:PutComplianceItems",
                "ssm:PutConfigurePackageResult",
                "ssm:UpdateAssociationStatus",
                "ssm:UpdateInstanceAssociationStatus",
                "ssm:UpdateInstanceInformation"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2messages:AcknowledgeMessage",
                "ec2messages:DeleteMessage",
                "ec2messages:FailMessage",
                "ec2messages:GetEndpoint",
                "ec2messages:GetMessages",
                "ec2messages:SendReply"
            ],
            "Resource": "*"
        }
    ]
}

アクティベーションを作成すると、以下のような画面になります。
アクティベーションコードは、このタイミングでしか表示されませんので画面を更新する前に控えておきましょう。
※記事公開時点で本アクティベーションは削除済み

これでAWS側の操作は完了です。

サーバ側でアクティベーション実施

アクティベーションは、AWSが公開しているS3バケットからバイナリを取得し実行することで完了します。
実行の際に、先程AWSで作成したアクティベーションコードとIDが必要になります。
ハイブリッド Linux ノードで SSM Agent をインストールする

mkdir -p tmp/ssm
curl https://amazon-ssm-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/linux_arm64/ssm-setup-cli -o tmp/ssm/ssm-setup-cli

この時リージョンは、アクティベーションを作成したリージョンに合わせるようにしてください。
また、SSMAgentの時と同様にアーキテクチャが異なる場合は、linux_arm64の部分を変更してください。

実行権限を付与して実行。

chmod +x tmp/ssm/ssm-setup-cli
sudo tmp/ssm/ssm-setup-cli -register -activation-code "ACTIVATION_CODE" -activation-id "ACTIVATION_ID" -region "REGION"

実行完了。

マネージドインスタンス登録の操作は以上です。

確認

SSMのフリートマネージャーから、先ほどのサーバがマネージドインスタンスとして登録されていることが確認できます。

比較として、EC2に構築したSSM管理下のサーバも表示しています。
ノードIDのプレフィックスやリソースタイプが異なることが確認できます。

スキャン実行

パッチマネージャからスキャンを実行します。

スキャン成功。

余談

検証中に以下のようなエラーになりました。

An unsupported package manager and python version combination was found.

Python3=127, Python2=1, Yum=127, Apt=127, Zypper=127, Dnf=127

Exiting...

failed to run commands: exit status 16

利用していたAlmaLinuxのバージョンがSSMのサポート対象外だったことが原因でした。

試験での出題ポイント

  • PatchManagerはセキュリティパッチの適用状況を管理し、スキャンや自動適用を行う
  • SSMAgentとSystemsManagerの接続ができればハイブリッド環境でも利用可能
  • AWSのAMIには最初からインストール済み
  • オンプレのサーバにはSSMAgentのインストールとアクティベーションが必要

まとめ

オンプレミス環境のサーバをSSMのマネージドインスタンスとして登録するためには以下が必要になります。

サーバ側
  • SSMAgentのインストール
  • アクティベーション操作
AWS側
  • IAMロールの作成
  • アクティベーションの作成

手順としては記載していませんが、AWS(SSMのエンドポイント)と通信する必要があるためインターネットへの接続が制限されている環境ではAWSまでの通信経路を用意しましょう。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

株式会社Luxy(https://luxy-inc.com)の代表取締役.

2018年〜インフラエンジニアとしてキャリアをスタートし、オンプレミスのネットワーク・サーバ環境で3年半、クラウド環境で4年半の8年間エンジニアとして従事。
2021年に佐藤氏の創業した会社を引き継ぎ、代表に就任。

目次