SSM Patch ManagerをSSM Maintenance WindowsでスケジュールしてBaselineOverrideパラメータを指定するとコンプライアンスレポートが出力されない
はじめに
皆様こんにちは、あかいけです。
またしてもPatch Managerに関連してハマってしまったのでブログにします。
今回はMaintenance Windowsでパッチ適用をスケジュールし、
BaselineOverrideパラメータを指定した場合にコンプライアンスレポートが出力されない、という事象についてまとめます。
構成イメージ
まず、本ブログでは以下のような構成を前提とします。
Patch Managerのスケジューリングをするには、主に以下の方法があります。
- パッチポリシー
- State Manager（Association）
- Maintenance Windows
また公式ドキュメントではパッチポリシーの利用が推奨されています。
AWS では、パッチポリシーを使用して組織と AWS アカウントのパッチ適用を設定することが推奨されています。
パッチポリシーは、2022 年 12 月に Patch Manager に導入されました。
では今回なぜMaintenance Windowsを使っているのでしょうか？
それはパッチポリシーやState Managerだとcronの制約があるためです。
具体的には、State Managerのcron式では月フィールドの指定や曜日範囲（MON-FRIなど）の指定ができません。
Maintenance Windowsのcron式にはこの制限がないため、より柔軟なスケジューリングが可能です。
詳しくは以下ブログをご参照ください。
BaselineOverrideについて
さてBaselineOverrideについてですが、
これはパッチを適用するためのSSMコマンドドキュメントであるAWS-RunPatchBaseline内で指定できる、パッチベースラインを上書きするためのパラメータです。
S3バケットに上書き用のJSONファイルをオブジェクトとして配置し、BaselineOverrideパラメータでそのオブジェクトのURLを指定します。
ユースケース
用途の例としては、パッチベースラインの自動承認日(公開後何日経過したパッチを適用するか)をオペレーションごとに変えたい場合などが挙げられます。
例えば、パッチをインストールする一週間前にスキャンだけしてどのパッチが当たるか確認したい、といった場合、
パッチスキャンとパッチインストールで自動承認日をずらす必要があります。
-
パッチ要件
- 3週間以上前にリリースされたパッチを適用したい
-
スケジュール要件
- パッチスキャン：インストールの一週間前に実行したい
- 自動承認日を2週間前にする
- パッチインストール：毎月最終週の日曜日に実行したい
- 自動承認日を3週間前にする
- パッチスキャン：インストールの一週間前に実行したい
しかし、この自動承認日はパッチベースライン側の設定のため、
スキャンとインストールで異なる自動承認日を使いたい場合はBaselineOverrideで上書きする必要がある、というわけです。
制約：コンプライアンスレポートが更新されない
そんなBaselineOverrideですが、実はパッチポリシーで使用する場合を除き、コンプライアンスレポートが更新されないという制約があります。
パッチ適用オペレーションでパッチポリシーが使用される場合を除き、BaselineOverride パラメータを使用しても、パラメータで指定されたベースラインのパッチコンプライアンスはオーバーライドされません。
出力結果は、AWS Systems Manager のツールである Run Command から Stdout ログに記録されます 結果は、NON_COMPLIANT としてマークされているパッケージのみを出力します。
つまり、パッケージは Missing、Failed、InstalledRejected、または InstalledPendingReboot としてマークされます。
コンプライアンスレポートとは、Patch Managerのマネジメントコンソールで確認できる、パッチ適用状況のダッシュボードのことです。
個人的にPatch Managerの喜びの半分はこのコンプライアンスレポートだと思っているので、これが確認できないのは困ります…。
余談：複数のパッチベースラインを使い分けられないの？
ここまでの話を聞いて、単純に複数のパッチベースラインを用意して、スキャン用とインストール用でEC2に紐づければ良いのでは？と思われるかもしれません。
しかし残念ながら、パッチグループの仕様上これはできません。
マネージドノードは 1 つのパッチグループのみ所属できます。
パッチグループは、オペレーティングシステムタイプごとに 1 つのパッチベースラインのみに登録できます。
つまり、1つのEC2インスタンスに対して同一OSタイプで複数のパッチベースラインを割り当てることはできないのです。
コンプライアンスレポートを出力するにはどうすればよいか？
ここからが本題です。
Maintenance Windows + BaselineOverrideの構成でコンプライアンスレポートを出力するための方法を検討しました。
案1. パッチポリシーを使う
BaselineOverrideを使ってもコンプライアンスレポートが更新されるのはパッチポリシーだけなので、パッチポリシーに切り替えるのが最もシンプルです。
ただしパッチポリシーはスケジューリングにState Managerを使っているため、Maintenance Windowsでしか指定できないcron式が必要な場合は利用できません…。
案2. コンプライアンスレポートをAPIで更新する
Systems ManagerにはPutComplianceItems APIが用意されており、コンプライアンスデータをプログラムから登録できます。
パッチインストール後にこのAPIを呼び出してレポートを更新する方法も考えられます。
実際にAWS CLIで試してみましたが、想像以上にコンプライアンスレポートの出力形式に合わせるのが中々面倒でした。（というか途中で諦めました）
パッチの適用結果をパースして、正しい形式に変換して、APIを呼び出して…と、割と作り込みが必要です。
そもそも作り込みの工数を減らすためにマネージドサービスを使っているのに、これでは本末転倒です…。
案3. インストール後にスキャンを別途実施する （私はこれを採用）
はい、これが一番単純な方法です。
インストール時はBaselineOverrideでの上書きを使ってパッチを適用し、その後にBaselineOverrideを指定せずにスキャンを実行します。
スキャン時は通常のパッチベースラインが使われるため、コンプライアンスレポートが更新されます。
ただしこの方法にも欠点があります。
BaselineOverrideを指定しないスキャンでは通常のパッチベースラインが使われるため、自動承認日の上書きが反映されません。
つまり、コンプライアンスレポート上の判定結果はオーバーライド前の自動承認日に基づくものになります。
（ここは妥協するしかないかなと思っています…。）
また、AWSドキュメントには複数のスキャンオペレーションがある場合、各スキャンが前回のパッチコンプライアンスデータを上書きする旨の注意書きがあります。
そのため、コンプライアンスレポート更新用のスキャンがパッチのインストール後に実行されるようスケジュールを調整する必要があります。
さいごに
以上、Patch ManagerをMaintenance WindowsでスケジュールしてBaselineOverrideパラメータを指定するとコンプライアンスレポートが出力されない、という話でした。
かなりニッチなユースケースだとは思いますが、この仕様を知らなかった私はだいぶ苦しみました。
結果的にはインストール後に追加スキャンを実行するというシンプルな方法に落ち着きましたが、同じ事象で困っている方の助けになれば幸いです。
