Go to Qiita Advent Calendar 2024 Top
LoginSignup
3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@chanhamain株式会社MIXI

AWS Systems Managerのパッチマネージャーを使ってパッチ適用を自動化する

Posted at

はじめに

本記事はAWS Well-Architected Labs - Operational Excellence - 100 - INVENTORY AND PATCH MANAGEMENTのポイントやハンズオン手順をまとめたものになります。AWS Well-Architected Labsについて知りたい方はこちらをご覧ください。

パッチ適用

パッチ適用運用はやらないといけないけど、手動で行う場合は面倒臭い作業です。数台のサーバーならまだしも数が多いとさらに大変です。パッチ適用はトイルの代表格と言っても過言ではないでしょう。そんなパッチ適用をパッチマネージャーを使えば自動化することができます。

パッチ適用自動化を行う上でのAWSサービスやSystems Manager機能間の関係

パッチマネージャーを使ったパッチ適用を行う場合はいくつかのAWSサービスやSystems Manager機能を連携させる必要があります。最初利用した時は関係性が若干分かりにくかったため、まとめておきます。

マネージドインスタンス

まずはパッチ適用の自動化対象のサーバをSystems Managerの管理下にする必要があります。ちなみにSystems Manager管理下にあるサーバはマネージドインスタンスと呼ばれます。EC2だけでなく、オンプレミスのマシンもマネージドインスタンスにすることができます。マネージドインスタンスにする条件は公式ドキュメントを参照してください。
Systems Manager の前提条件

パッチマネージャー

どのパッチをどのインスタンスに適用させるかをパッチマネージャーで設定することができます。

パッチベースライン

パッチ適用のルールを定義することができます。OS毎にデフォルトのベースラインが用意されており、それらは変更することはできませんが、ユーザの用途に合ったパッチベースラインをカスタムバッチベースラインとして作成することができます。具体的には以下のような設定を行います。

  • Product (製品)
    • 承認ルールが適用されるオペレーティングシステムのバージョン
  • Classification (分類)
    • 承認ルールが適用されるパッチのタイプ
  • Severity (重要度)
    • ルールが適用されるパッチの重要度の値
  • Auto-approval (自動承認)
    • 自動承認のためにパッチを選択する方法
  • Compliance reporting (コンプライアンスレポート)
    • ベースラインで承認されたパッチに割り当てる重要度
  • Include non-security updates (セキュリティに関連しない更新を含める)
    • セキュリティに関連するパッチに加えて、ソースリポジトリで使用可能なセキュリティに関連しない Linux オペレーティングシステムのパッチをインストールするには、このチェックボックスをオンにします

カスタムパッチベースラインの作成

パッチグループ

パッチベースラインを適用するインスタンスをパッチグループとしてグループ化できます。パッチグループに所属させたいインスタンスにはkey=Patch Groupのタグを付与する必要があります。パッチグループ作成時はkeyに対するvalueを指定して作成します。パッチグループはパッチベースラインに対して関連付けられます。

SSMドキュメント AWS-RunPatchBaseline

パッチベースラインに設定されているパッチ適用を行うためにはRun Command経由でSSMドキュメントであるAWS-RunPatchBaselineを実行する必要があります。Run Commnandの実行はメンテナンスウィンドウ、AWS CLI,SDK等から行います。実行時の必須パラメータとして以下を指定します。

  • Operation
    • Scan
      • 適用予定のパッチ一覧だけを確認し、インストールは行わない
    • Install
      • 適用対象のパッチをインストールします。
  • RebootOption
    • RebootIfNeeded
      • 再起動が必要なパッチが合った場合はインスタンスを再起動する
    • NoReboot
      • インスタンスの再起動は行わない

SSM ドキュメント AWS-RunPatchBaseline について

また、どのインスタンスに対してRun Commandを実行するかターゲットを指定します。注意として、パッチ適用を行うインスタンスはパッチグループにも所属させ、Run Commandのターゲットしても指定してあげる必要があるということです。

ハンズオン手順

パッチマネージャーを使ったパッチ適用を試せるAWS Well-Architected Labs - Operational Excellence - 100 - INVENTORY AND PATCH MANAGEMENTのハンズオン手順を記載します。

セットアップ

IAMユーザ作成

まずはAdministratorAccess相当のポリシーがアタッチされたIAMユーザを用意しましょう。以降はこのIAMユーザでAWSマネジメントコンソールにログインし、操作してください。
全画面_2020_08_01_16_53.png

EC2キーペア作成

EC2のキーペアを適当な名前で作成します。今回はyhamano-walという名前で作成します。ファイル形式はpemを選んでください。
全画面_2020_08_01_17_09.png

CloudFormationでのデプロイ

テンプレートファイルのダウンロード

今回のハンズオン環境をCloudFormationを用いてデプロイします。
まず、こちらからCloudFormationテンプレートをローカルにダウンロードしてください。

IAMロール作成

CloudFormationで作成するEC2にアタッチするIAMロールを事前に作成します。
AWSマネジメントコンソールからIAM画面に遷移し、ロールの作成を選択します。
全画面_2020_08_02_9_36.png

ユースケースの選択でEC2を選択します。
全画面_2020_08_02_9_49.png

Attchアクセス権限ポリシーでAmazonSSMManagedInstanceCoreを選択します。元々の手順ではAmazonEC2RoleforSSMを選択するようになっていますが、権限が大きすぎることからこちらは非推奨となっています。詳しくはクラメソさんのブログを参照ください。
全画面_2020_08_02_9_47.png

タグは何も指定せずに、ロール名を入力してロールの作成を行います。ロール名は適当でOKです。
全画面_2020_08_02_9_54.png

スタック作成

スタックの作成を行なっていきます。CloudFormationの画面に遷移し、新しいリソースを使用(標準)を選択します。
全画面_2020_08_02_10_20.png

テンプレートファイルのアップロードから先ほどダウンロードしたCloudFormationテンプレートを選択します。
全画面_2020_08_02_9_06.png

次に各種パラメータを入力します。

  • スタックの名前
    • OELabStack1
  • InstanceProfile
    • 先ほど作成したIAMロール名を入力します。
  • InstanceTypeApp,InstanceTypeWeb
    • デフォルトで入力されているt2.microでOK
  • KeyName
    • 先ほど作成したEC2キーペアを選択
  • SourceLocation
    • アクセス元のグローバルIPを指定。こちらアクセスすると確認できる。入力時は**/32**を末尾に追記すること
  • WorkloadName
    • Test

CloudFormation_-_スタック.png

オプション設定は何も入力せずに、レビュー画面を確認し、問題無ければスタックの作成を行う。作成開始後はステータスがCREATE_COMPLETEになるまで待ちます。
CloudFormation_-_スタック_OELabStack1.png

再度同じCloudFormationの実行手順で別環境を作成します。
各種パラメータは以下です。

  • スタックの名前
    • OELabStack2
  • InstanceProfile
    • 先ほど作成したIAMロール名を入力します。
  • InstanceTypeApp,InstanceTypeWeb
    • デフォルトで入力されているt2.microでOK
  • KeyName
    • 先ほど作成したEC2キーペアを選択
  • SourceLocation
    • アクセス元のグローバルIPを指定。こちらアクセスすると確認できる。入力時は**/32**を末尾に追記すること
  • WorkloadName
    • Prod

Systems Managerを用いた状態管理

マネージドインスタンスへの登録確認

Systems Managerのマネージドインスタンス一覧に作成した8つのEC2インスタンスが表示されることを確認する。IAMロールをアタッチしてから一覧に表示されるまで数分かかる場合もあります。
AWS_Systems_Manager_-_Managed_Instances.png

インベントリ設定

マネージドインスタンスをインベントリに設定します。なお、**パッチマネージャーでのパッチ適用をする場合にインベントリ設定を行う必要はありません。**インベントリ画面からセットアップインベントリを選択します。
AWS_Systems_Manager_-_Inventory.png

ターゲットでタグの指定を選択し、key=Environment,value=OELabIPMを入力し、その他の設定はそのままでインベントリを作成する。
AWS_Systems_Manager_-_Inventory.png

パッチ管理

パッチベースライン作成

まずパッチベースラインの作成を行います。
AWS_Systems_Manager_-_Patch_Manager.png

各種パラメータは以下です。記載されていないパラメータはデフォルト設定でOK

  • パッチベースラインの詳細
    • 名前
      • AmazonLinuxSecAndNonSecBaseline
    • 説明
      • Amazon Linux patch baseline including security and non-security patches
    • OS
      • Amazon Linux

AWS_Systems_Manager_-_Patch_Manager.png

  • オペレーティングシステムの承認ルール
    • ルール1
      • 製品
        • ALL
      • 分類
        • ALL
      • 重要度
        • ALL
      • コンプライアンスレポート オプション
        • 非常事態
    • ルール2
      • 製品
        • ALL
      • 分類
        • ALL
      • 重要度
        • ALL
      • コンプライアンスレポート オプション
        • ミディアム
      • セキュリティ以外の更新を含める
        • チェック

AWS_Systems_Manager_-_Patch_Manager.png

  • パッチの例外
    • 拒否済みパッチ オプション
      • system-release.*

AWS_Systems_Manager_-_Patch_Manager.png

パッチグループの割り当て

EC2のタグにkey=Patch Groupが設定されていればパッチグループとして定義されますが、今回はタグkey=Patch Group,value=Criticalが最初から付与された状態で作成されているため、パッチグループの割り当てのみ行います。
作成したパッチベースライン詳細画面からパッチグループの変更を選択し、パッチグループにはCriticalを入力し、追加します。

AWS_Systems_Manager_-_Patch_Manager.png

AWS_Systems_Manager_-_Patch_Manager.png

Run Commandを介してAWS-RunPatchBaselineでインスタンスにパッチを適用する

Run Command画面からRun Commandを選択します。
AWS_Systems_Manager_-_Run_Command.png

各種パラメータは以下を設定します。記載されていないパラメータはデフォルトの設定でOK

  • コマンドドキュメント
    • AWS-RunPatchBaseline
  • コマンドのパラメータ
    • Operation
      • Install
  • ターゲット
    • インスタンスタグの指定
      • key
        • Workload
      • value
        • Test

AWS_Systems_Manager_-_Run_Command.png

対象インスタンス(タグがkey=Workload,value=Testの4つ)のRun Command処理が成功することを確認する。
AWS_Systems_Manager_-_Run_Command.png

メンテナンスウィンドウの作成と自動運用アクティビティのスケジュール

メンテナンスウィンドウ実行用のIAMリソース作成

Systems Managerがユーザーに代わってメンテナンスウィンドウでタスクを実行できるようにIAMリソースを作成します。
以下の設定のIAMロールを作成します。

  • ロール名
    • SSMMaintenanceWindowRole
  • ロールの説明
    • Role for Amazon SSMMaintenanceWindow
  • アタッチポリシー
    • AmazonSSMMaintenanceWindowRole

作成後に信頼関係を以下に変更する。

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"",
         "Effect":"Allow",
         "Principal":{
            "Service":[
               "ec2.amazonaws.com",
               "ssm.amazonaws.com",
               "sns.amazonaws.com"
            ]
         },
         "Action":"sts:AssumeRole"
      }
   ]
}

メンテナンスウィンドウの作成

メンテナンスウィンドウ画面からメンテナンスウィンドウの作成を行う。
AWS_Systems_Manager_-_Maintenance_Windows.png

各種パラメータは以下を設定します。記載されていないパラメータはデフォルト設定でOK

  • メンテナンスウィンドウの詳細の入力
    • 名前
      • PatchTestWorkloadWebServers
    • スケジュールを指定
      • 期間
        • 1時間
      • タスクの開始を停止
        • 0

パッチメンテナンスウィンドウへのターゲットの割り当て

作成したメンテナンスウィンドウに対してターゲットの割り当てを行います。ウィンドウIDの詳細画面からターゲットの登録を選択します。
AWS_Systems_Manager_-_Maintenance_Windows.png

各種パラメータは以下を設定します。記載されていないパラメータはデフォルト設定でOK

  • メンテナンスウィンドウのターゲットの詳細
    • 名前
      • TestWebServers
  • ターゲット
    • Target selection
      • key=Workload,value=Test
      • key=InstanceRole,value=WebServer

パッチメンテナンスウィンドウへのタスクの割り当て

作成したメンテナンスウィンドウに対してタスクの割り当てを行います。ウィンドウIDの詳細画面からrun commandタスクの登録を選択します。
AWS_Systems_Manager_-_Maintenance_Windows.png

各種パラメータは以下を設定します。記載されていないパラメータはデフォルト設定でOK

  • メンテナンスウィンドウのタスクの詳細
    • 名前
      • PatchTestWorkloadWebServers
  • コマンドのドキュメント
    • AWS-RunPatchBaseline
  • ターゲット
    • 登録済みターゲットグループの選択
      • 先ほど登録したターゲットのID
  • レート制御
    • 並行性
      • 1
    • 誤差閾値
      • 1
  • IAMサービスロール
    • カスタムサービスロールを使用する
      • SSMMaintenanceWindowRole
  • パラメーター
    • Operation
      • Install

メンテナンスウィンドウの実行の確認

メンテナンスウィンドウの実行時間になったら、履歴から実行結果を確認し、ステータスが成功となっていることを確認する。
AWS_Systems_Manager_-_Maintenance_Windows.png

リソース削除

最後に作成したリソースを削除します。

  • CloudFormationスタック
    • OELabStack1
    • OELabStack2
  • インベントリ
    • Inventory-Association
  • メンテナンスウィンドウ
    • PatchTestWorkloadWebServers
  • パッチベースライン
    • AmazonLinuxSecAndNonSecBaseline

おわりに

各サービスの関係性さえ理解すれば、比較的簡単にパッチマネージャーでパッチ適用を自動化することは可能ですが、パッチ適用フローを十分に精査する必要があると思います。実際のシステムに取り入れるのであれば、開発環境でまずは適用し、問題がなければ本番環境に適用するようなフローになると思います。また、**どの分類のどの重要度までのパッチを適用すれば良いかも考慮する必要があります。**ここら辺については従来通りエンジニア側で考える必要がありますが、パッチ適用作業自体を自動化できることを大きなメリットとなるため、機会があれば使っていきたいと思います。

参考

3
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?