AWS Systems ManagerのPatch Mangerを使用してLinuxOSに自動的にパッチを当てみた

watanabe.r


この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。

はじめに

AWS Systems Manger(以下SSM) Patch Mangerについて元々興味があったのと、調査を依頼されたので理解を深めるために、
SSMのPatch Mangerを使用してパッチ適応の自動化をハンズオン形式で行いたいと思います。

SSM Patch Mangerとは

AWS Systems Manager の一機能である Patch Manager は、セキュリティ関連の更新およびその他の種類の更新の両方を使用してマネージドノードにパッチを適用するプロセスを自動化します。

引用:AWS System Manager Patch Manager

主なユースケース

  • Patch Manager の一機能である AWS Systems Manager を使用してパッチを大規模にロールアウトし、フリートコンプライアンスの可視性をノード全体で強化します。
  • Patch Manager を AWS Security Hub と統合して、フリートのノードがコンプライアンス違反になったときにアラートを受け取ったり、セキュリティの観点からフリートのパッチ適用ステータスを監視したりします。
  • パッチコンプライアンス用のマネージドノードのスキャンでは、コンプライアンスデータが意図せず上書きされることを防ぐため、一度に 1 つの方法のみを実行します。

引用: ユースケースとベストプラクティス

構成図

パッチポリシーのほかにRun Commandなどが実行されていますが今回は省略してあります。
今回はPublicSubnetで行っていますが、PrivateSubnetだとSSM Endpointが必要になります。
file

パッチポリシーの作成

1. 事前にEC2インスタンスを作成

以下以外はデフォルトで作成しました。
タグは後で使用するので任意で大丈夫です。

タイプ 設定値
OS AmazonLinux2
タイプ t2.micro
タグ Key:PatchManagerTest Value:Watanabe

2. SSM→左ペイン「パッチマネージャー」を選択

パッチマネージャーに行くと以下の画像のようなところに行きます。
file

3. 2の画像の右上の「パッチポリシーを作成」を押下

4. パッチポリシーの作成

  1. 設定名は「watanabe-patch-test」にしました
    file
  2. 今回は全体の動きが知りたいので「スキャンとインストール」を選択し、時間は現在の時間の数分後に設定しました。
    file
  3. パッチベースラインはデフォルトです。自分で作成することもできますが、今回はデフォルトにしました。
    「S3バケットに書き込む」は無効にしてあります。
    file
  4. ターゲットはEC2インスタンスが置いてある東京リージョンにチェックを入れてあります。(シンガポールはデフォルトで入っていました)
    ※自分のEC2インスタンスがおいてあるリージョンを指定してください
    「ノードタグを指定」から先ほどEC2につけたタグを入力しました。
    file
  5. 「レートの制御」はデフォルトです。
    「インスタンスプロファイルのオプション」は有効にしてあります。
    ※有効にすると自動的にEC2インスタンスにIAMロールがアタッチされます。
    設定できましたら作成します。
    file

    5. 作成後、左ペイン「高速セットアップ」にて作成したパッチポリシーがあるか確認

    フィルターで「Patch Manager」で絞る→作成したものを選択→「詳細を表示」を押下
    以下の画像の様に設定した名前が表示されていることを確認します。
    file
    自分の選択したリージョン、今回は「ap-northeast-1」のものを選択し「詳細を表示」押下します。
    以下の画像の様に「AWS-QuickSetup-PatchPolicy-ScanForPatches-LA-qp4fl」と「AWS-QuickSetup-PatchPolicy-InstallPatches-LA-qp4fl」が保留中になっていれば大丈夫です。
    file

6. スキャンが実行されたか確認

指定時間になると5で確認した「AWS-QuickSetup-PatchPolicy-ScanForPatches-LA-qp4fl」が「成功」に変わっていることを確認します。
file

「SSM」→左ペイン「Run Command」→「コマンド履歴」から指定時刻のものを選択し「詳細を表示」を押下します。
指定したインスタンスIDと時刻(数分ずれとGMTなことに注意)が一致しており
下のほうの「Operation」が"Scan"になっていることを確認します。
「コマンドのステータス」にある「全体的なステータス」が「成功」になっていればScanの実行は成功しています。
file

7. インストールが実行されたか確認

手順6同様に「AWS-QuickSetup-PatchPolicy-InstallPatches-LA-qp4fl」が「成功」に変わっていることを確認します。
file

「SSM」→左ペイン「Run Command」→「コマンド履歴」から指定時刻のものを選択し「詳細を表示」を押下します。
指定したインスタンスIDと時刻(同様に数分ずれとGMTなことに注意)が一致しており
下のほうの「Operation」が"install"になっていることを確認します。
「コマンドのステータス」にある「全体的なステータス」が「成功」になっていればInstallの実行は成功しています。
file

「SSM」→左ペイン「パッチマネージャー」→「コンプライアンスレポート」から
以下の画像の様に「コンプライアンス状況」が「準拠」になっており、「最終オペレーション日」が指定した時刻(JST)になっていることを確認します。
file

まとめ

SSMの機能の一部であるパッチマネージャーをハンズオン形式で行いました。
指定時間に定期的に自動パッチをあてられるのは、とても利便性の高いものだと確認できました。
また機会があればSSMのほかの機能も触ってみたいと思います。

Last modified: 2023-05-10

Author