小ネタです。そして掲題が全てを語っています。
以下、ECS on EC2 構成の ECS サービスにおいて ECS タスクを動作させるプラットフォームとなる EC2 インスタンスを ECS コンテナインスタンス と呼称します。これは Launching an Amazon ECS Linux container instance へ微妙に倣っての呼び方になります。
3行で
- ECS on EC2 構成の ECS サービスで GuardDuty ECS Runtime Monitoring を有効化する場合、ECS サービスの更新は必要ない
- ECS コンテナインスタンスで GuardDuty エージェントが動作し EC2 Runtime Monitoring の要件を満たせれば、その時点で ECS Runtime Monitoring も有効になる
- ECS コンテナインスタンスでの EC2 Runtime Monitoring 導入には GuardDuty エージェントが要求する制約がいくつかある
なお本稿が伝えたいことは末尾の 追伸 で全て事足ります。
背景
現在 MNTSQ では SRE を中心にプロダクトセキュリティの向上施策を進めており、その中で GuardDuty の利用範囲拡充も目論んでいます。
ここで白羽の矢が立ったのが GuardDuty の機能のひとつである Runtime Monitoring です。詳細は AWS 公式ドキュメント(GuardDuty Runtime Monitoring) に譲りますが、EC2 / EKS / ECS においてインスタンスやタスクの振舞いを内部から観測し、脅威となりうる挙動の検出が可能なサービスです。 サポートされるサービスは前掲ドキュメントにもある通り EKS / ECS / EC2 で、EKS 以外は MNTSQ のワークロードにも合致します。
さて Runtime Monitoring の導入ですが、この方法にはいくつかの経路があります。Enabling GuardDuty Runtime Monitoring にその全容があり、実に多様な手法が用意されていることが伺えます。MNTSQ では
- 全ての AWS アカウントは AWS Organizations で管理している
- 導入対象は ECS とし、EC2 は追って導入を検討する
- ECS Runtime Monitoring 有効化にかかる手間は最小限のものとしたい。自動導入の仕組みがあれば積極的にこれを使いたい
- Runtime Monitoring を有効にする決定をした AWS アカウント内では全ての ECS クラスタを一律対象とする
という背景があり、以下の要領で有効化を進めることにしました。
- Runtime Monitoring 有効化対象のアカウントは明示的に指定する
- Enabling Runtime Monitoring for multiple-account environments の "For selective active member accounts only" で有効化設定をする
- GuardDuty エージェントの導入は自動でやってもらう
- Managing automated security agent for Fargate (Amazon ECS only) に解説があるとおり、Runtime Monitoring 有効化設定を投入した後に ECS サービスを更新すれば自動で GuardDuty エージェントがサイドカーコンテナとして起動してくる
なお、ECS on Fargate 構成において GuardDuty エージェントがサイドカーコンテナとして起動する際、ECS タスク定義への変更は特段発生しません。
ECS サービス / タスク定義の範囲外の箇所で aws-guardduty-agent- という接頭辞の名称をもつコンテナが自動で起動してくるようになります。詳細は How Runtime Monitoring works with Fargate (Amazon ECS only) の "GuardDuty adds a sidecar container" の節に説明があります。
さて2025年6月現在、MNTSQ で扱う ECS サービスでは
- ECS on Fargate
- ECS on EC2
の2種類の構成をとるものがあります。ECS サービスの数で言えば ECS on Fargate が圧倒的に多く、ECS on EC2 は一部用途（主に GPU を利用したい向き）で使われるのみです。 前述ドキュメントに従い ECS Runtime Monitoring の導入をすすめると、ECS on Fargate に関しては ECS サービス更新後に Reviewing runtime coverage statistics and troubleshooting issues に示される手法にて healthy（= GuardDuty エージェントが稼動し Runtime Monitoring の動作も開始した）なことが確認できるようになりました。
いっぽうでこの手法では ECS on EC2 構成の ECS サービスでは coverage が unhealthy のままになってしまう という気付きも得られました。さてどうしたことでしょう。
ECS Runtime Monitoring を ECS on EC2 構成で healthy にする
ECS と EC2 のそれぞれで Runtime Monitoring がどのように動作するかは以下ドキュメントに示されています。
- How Runtime Monitoring works with Amazon EC2 instances
- How Runtime Monitoring works with Fargate (Amazon ECS only)
いずれも GuardDuty エージェントが動作していることが前提で、EC2 の場合は Systemd ユニットとして、ECS の場合はサイドカーコンテナとして動作します 今回目指したい ECS on EC2 構成の場合でも Fargate ではないとはいえ ECS ではあるので、サイドカーコンテナとして GuardDuty エージェントは動作するのではないかと考えるのは自然なはずです。少なくとも本稿筆者はそう考えました。しかしながら実際に作業をしてみると
| 作業 | ECS on Fargate で Runtime Monitoring が healthy になった | ECS on EC2 で Runtime Monitoring が healthy になった |
|---|---|---|
| GuardDuty 側で ECS Runtime Monitoring を有効にした | × | × |
| エージェントの自動導入を有効にした | × | × |
| ECS タスクの入れ替えをした | × | × |
| ECS サービスを更新した | ○ | × |
| ECS コンテナインスタンスで GuardDuty エージェントを動作させた | ×（関係なし） | ○ |
という格好になりました。つまり ECS on EC2 構成の場合は ECS ではなく EC2 側での Runtime Monitoring 対応が必要 という洞察が得られました。 ちなみにこのとき ECS サービス上ではサイドカーコンテナとしての GuardDuty エージェントは稼動せず、EC2 インスタンス上で動作する GuardDuty エージェントがその役目を担っている模様です。
ECS コンテナインスタンスで GuardDuty エージェントを動作させる
どこで何が必要になるかが判れば話は早いです。事前準備としては以下を参照すればよいでしょう。
- How Runtime Monitoring works with Amazon EC2 instances
- Prerequisites for Amazon EC2 instance support
早い話が以下です。
- EC2 インスタンスプロファイルで SSM の Run Command によるコマンド実行が許可されるよう権限設定を行う
- 新しめの Linux カーネルが利用可能な状態で EC2 インスタンスを稼動させる
Linux カーネルのバージョンが見落されがちなので注意が必要です。筆者は見落しました。
ECS コンテナインスタンスを動作させる場合、おおよそのケースでは ECS-optimized AMI が利用されると思います。MNTSQ でも例に漏れず ECS-optimized AMI を使用し ECS コンテナインスタンスを稼動させています。この ECS-optimized AMI で上記ドキュメントに示される Linux カーネル 5.4 以上のもの*1 を使う方法を考える必要があります。
最も簡単なのは Amazon ECS-optimized Linux AMIs や Retrieving Amazon ECS-optimized Linux AMI metadata で案内されている、Linux カーネル 5.10 を標準で使用する ECS-optimized AMI に差し替えてしまうというものでしょう。弊社でもこの差し替えを行うことで対応としました。
まとめ
ECS on EC2 構成の場合は ECS ではなく EC2 側での Runtime Monitoring 対応が必要
という点、早々に気付ければ話は早かったのですが、「ECS が対象なのだから ECS 向けの有効化作業に何か抜け漏れがあるはずだ」と執着してしまい、試行錯誤をする羽目になりました。Runtime Monitoring に関する AWS 公式ドキュメントのうち ECS に言及されるものはほぼ全て ECS on Fargate が対象の模様で、ECS on EC2 構成に関しての言及が見られない点も少々難儀する箇所だったように思います。プラットフォームを自前で管理する場合の観点を今一度鍛えようと思える機会になりました。
ECS on EC2 構成で ECS Runtime Monitoring が一向に有効化できないという状況にお困りの方の一助となれば幸いです。
MNTSQ 株式会社 SRE 秋本
追伸
ECS on EC2 構成の場合は ECS ではなく EC2 側での Runtime Monitoring 対応が必要
という点、本稿筆者が本作業を行った際には先行情報となるものを見付けられず、本記事が有意義なものになると妄想していました。しかし今本記事を書きつつ探してみたところ、Turning on Runtime Monitoring for Amazon ECS という ECS のドキュメント（GuardDuty のドキュメントではない） で ECS on EC2 向けの解説がありました。もっと早く知りたかった……。
