このサーバのアプリケーションいつバージョンアップしたんだっけ？ SSM インベントリと AWS Config の組み合わせでタイムラインから確認する
コンバンハ、千葉（幸）です。
先日、以下の記事を書きました。
AWS Systems Manager インベントリを利用して収集した OS 上のファイルのメタデータが、 AWS Config による記録の対象となった、というものです。ファイルの情報を変更したらそれが AWS で検知できるなんて面白いなーと思いました。
それの検証を行った際に、従来からできる機能でも面白いと思ったものがありました。今回はそれをご紹介します。
全体のイメージは以下の通りです。
目次
SSM インベントリによるマネージドインスタンスのメタデータの収集
SSM インベントリでは、マネージドインスタンスが持つメタデータを SSM エージェントを通じて収集することができます。
収集できるメタデータには以下のようなものがあります。
- アプリケーション
- AWS コンポーネント
- ファイル
- ネットワーク設定の詳細
- Windows 更新プログラム
- インスタンスの詳細
- サービス
- タグ
- Windows レジストリ
- Windows ロール
- カスタムインベントリ
あくまでメタデータのみで、機密情報やデータそのものは収集しません。
インベントリは SSM ステートマネージャーと連携し、定期的に収集を実行するよう設定することができます。ステートマネージャーにおいては 関連付け というリソースを定義することになります。これは後述します。
詳細は以下を参照してください。
AWS Systems Manager インベントリ - AWS Systems Manager
AWS Config 設定レコーダーによるリソースの設定変更記録
AWS Config では、設定レコーダーによりリソースの設定変更を記録することができます。追跡対象とするリソースはユーザー側で設定することが可能です。
AWS Config が追跡できるのは 一部の AWS サービス内のリソースです。一覧は以下の通りとなっています。
AWS Config でサポートされているリソースタイプとリソース関係 - AWS Config
SSM インベントリに関連するものとしては以下 2 種があり、それぞれ対応するメタデータが異なります。
AWS::SSM::ManagedInstanceInventory- アプリケーション
- AWS コンポーネント
- ネットワーク設定
- インスタンスの詳細情報
- Windows 更新プログラム
AWS::SSM::FileData- ファイル
マネージドインスタンスのソフトウェア設定の記録 - AWS Config
後者の方が、先日のアップデートで新たにサポートされたリソースタイプです。前者は比較的古くから対応してあり、少なくとも 2017 年には対応しているようでした。
また、上記 2 種のいずれにも含まれていないメタデータは Config の追跡対象とはできません。
- タグ
- サービス
- Windows レジストリ
- Windows ロール
- カスタムインベントリ
やってみた
今回は、Amazon Linux2 の EC2 インスタンスを マネージドインスタンスとし、yum アップデートの前後でのアプリケーションの更新を Config のタイムラインで確認するところをゴールとします。
基本的な操作はほぼほぼ前回のエントリと重複しているので、サラッと触れていきます。
- AWS Config レコーダーの設定
- Systems Manager インベントリのセットアップ
- マネージドインスタンスの作成
- yum アップデートの実行
1. AWSConfig レコーダーの設定
AWS Config -> 設定 から、[ 記録するリソースタイプ ] の中にAWS::SSM::ManagedInstanceInventory が含まれている状態を前提とします。
あるいは、 [ このリージョンでサポートされているすべてのリソースを記録します ] を選択している状態でも問題ありません。
2. Systems Manager インベントリのセットアップ
インベントリのセットアップでは、取得するメタデータの種類や、対象とするマネージドインスタンス、実行スケジュールを定義します。
その設定に応じた、SSM ステートマネージャーのリソース 関連付け が作成されます。
今回はすでに作成済みのものを使用します。
パラメータとしては以下を設定しています。
- 取得するメタデータの種類
- アプリケーション
- AWS コンポーネント
- ネットワーク設定
- インスタンスの詳細情報
- Windows 更新プログラム
- Windows ロール
- カスタムインベントリ
- 対象とするマネージドインスタンス
- すべて
- 実行スケジュール
- 30分ごと
3. マネージドインスタンスの作成
今回は以下の AMI を用いてインスタンスを作成します。最新のものより １ 世代古いものを選んでみました。
- amzn2-ami-hvm-2.0.20200617.0-x86_64-gp2 (ami-06ad9296e6cf1e3cf)
この AMI には SSM エージェントがインストールされているので、追加で以下の条件を満たすようにローンチし、マネージドインスタンスとしました。
- Systems Manager のサービスエンドポイントに到達可能
- パブリックサブネットに配置し、パブリック IP を割り当て
- 必要な権限を持っている
- AWS 管理ポリシー
AmazonSSMManagedInstanceCoreがアタッチされたロールをインスタンスに関連付け
- AWS 管理ポリシー
「30分ごと」のスケジュールにたまたま合致したのか、初めてマネージドインスタンスとして管理対象となった際に自動的に適用されるのかはわかりませんが、ステートマネージャーが適用されました。（おそらく後者な気がしています。）
この状態であれば、AWS Config に SSM インベントリで収集した内容が記録されているはずです。
Config -> リソース -> リソースのインベントリ より、リソースタイプで AWS::SSM::ManagedInstanceInventory でフィルタリングすると、マネージドインスタンスが現れてきます。
リソースの詳細画面に遷移します。メタデータのうちいくつかは、この画面から 確認することができます。（ JSON もしくはそれを見やすくしてくれた形式）
設定タイムラインを覗いてみます。
まず初回検出されたイベントと、インベントリにより収集されたメタデータが関連づけられた分でタイムラインが 2 つ並んでいます。
ひとまずアップデート前の状態確認は完了です。
4. yum アップデートの実行
今回は マネージドインスタンスに対して SSM セッションマネージャーで接続し、豪快に sudo yum update を実行します。
コマンドの結果はもろもろ省略しますが、以下のようなアップデートが行われました。
Dependencies Resolved ============================================================================================================================================== Package Arch Version Repository Size ============================================================================================================================================== Installing: kernel x86_64 4.14.186-146.268.amzn2 amzn2-core 21 M Updating: amazon-ssm-agent x86_64 2.3.1319.0-1.amzn2 amzn2-core 21 M bind-export-libs x86_64 32:9.11.4-9.P2.amzn2.0.4 amzn2-core 1.1 M bind-libs x86_64 32:9.11.4-9.P2.amzn2.0.4 amzn2-core 155 k bind-libs-lite x86_64 32:9.11.4-9.P2.amzn2.0.4 amzn2-core 1.1 M bind-license noarch 32:9.11.4-9.P2.amzn2.0.4 amzn2-core 89 k bind-utils x86_64 32:9.11.4-9.P2.amzn2.0.4 amzn2-core 257 k curl x86_64 7.61.1-12.amzn2.0.2 amzn2-core 342 k ec2-net-utils noarch 1.4-2.amzn2 amzn2-core 16 k file x86_64 5.11-36.amzn2.0.1 amzn2-core 57 k file-libs x86_64 5.11-36.amzn2.0.1 amzn2-core 339 k glibc x86_64 2.26-35.amzn2 amzn2-core 3.3 M glibc-all-langpacks x86_64 2.26-35.amzn2 amzn2-core 7.0 M glibc-common x86_64 2.26-35.amzn2 amzn2-core 768 k glibc-locale-source x86_64 2.26-35.amzn2 amzn2-core 3.2 M glibc-minimal-langpack x86_64 2.26-35.amzn2 amzn2-core 27 k json-c x86_64 0.11-4.amzn2.0.4 amzn2-core 30 k libcrypt x86_64 2.26-35.amzn2 amzn2-core 47 k libcurl x86_64 7.61.1-12.amzn2.0.2 amzn2-core 286 k libgcc x86_64 7.3.1-9.amzn2 amzn2-core 97 k libgomp x86_64 7.3.1-9.amzn2 amzn2-core 203 k libstdc++ x86_64 7.3.1-9.amzn2 amzn2-core 444 k microcode_ctl x86_64 2:2.1-47.amzn2.0.7 amzn2-core 288 k p11-kit x86_64 0.23.19-1.amzn2 amzn2-core 268 k p11-kit-trust x86_64 0.23.19-1.amzn2 amzn2-core 131 k python-urllib3 noarch 1.25.7-1.amzn2.0.1 amzn2-core 189 k rsyslog x86_64 8.24.0-52.amzn2 amzn2-core 617 k selinux-policy noarch 3.13.1-192.amzn2.6.3 amzn2-core 456 k selinux-policy-targeted noarch 3.13.1-192.amzn2.6.3 amzn2-core 6.6 M strace x86_64 4.26-1.amzn2.0.1 amzn2-core 921 k system-release x86_64 1:2-12.amzn2 amzn2-core 17 k Transaction Summary ============================================================================================================================================== Install 1 Package Upgrade 30 Packages
ステートマネージャーの 30 分ごとの定期実行を待ってもいいのですが、今回はオンデマンドで実行してインベントリの再収集を行います。
正常に完了したので、 Config のタイムラインを再度確認します。イベントが 2 つに分かれています。
今回は SSM エージェントがアップデートされたので、その影響で分かれたようです。
1 点目のイベントでは このように SSM エージェントの変更が記録されています。
2 点目のイベントではこのように各種アプリケーションの更新が記録されています。アップデートしたパッケージは 30 個ですが、バージョンだけでなくインストール時刻やパッケージ ID 、リリースなどの情報も記録対象となっているため、項目数が多くなっています。
カーネルについては今回の yum アップデートで新しいバージョンをインストールしましたが、このように記録されています。
どのようにタイムラインで参照できるかを確認できました！
終わりに
SSM インベントリにより収集されたアプリケーションのメタデータの変更を AWS Config から確認してみました。
記録がタイムラインとして残っていくので、このサーバのアプリケーションっていついつ時点でバージョンいくつだっけ？ というのを確認するのも手軽に行えます。マネージドインスタンスとして管理できるのは EC2 インスタンスだけでなく、オンプレミスのサーバにも対応しています。
構成管理はこういった便利な仕組みを活用していきたいですね。
以上、千葉（幸）がお送りしました。
