Amazon Elastic Container Service (ECS) の実行環境に AWS Fargate を用いた構成（以下、ECS Fargate ）は、AWS でコンテナの実行環境を整える際の強力な選択肢のひとつです。
Fargate を用いることで、ユーザが考慮すべきセキュリティリスクは（ EC2 を用いるよりも）少なくなりますが、すべてがカバーされるものではありません。
今回は、ECS Fargate で実行されるワークロードを Sysdig の Serverless Agent を使って保護するための方法を連載記事でご紹介します。

モチベーション

Fargate を利用することで、ECS / EKS のユーザはコンテナを実行するための仮想マシンを設定・運用する必要がなくなります。
そのため、仮想マシンの観点では、例えばセキュリティパッチ適用、マルウェア対策、アクセス制御などをユーザが行う必要はありません。
仮想マシンがユーザにとって透過的な存在となるため、セキュリティリスクを引き起こす脅威の一部を考慮する必要がなくなります。

一方、実行するコンテナのセキュリティ対策は依然としてユーザの責務です。
例えば、ECS Fargate の環境においても、以下のようなセキュリティリスクへの対応を検討する必要があります。

正常なリクエストを装い、脆弱性を悪用して不正なコードを実行させる第三者からの攻撃
悪意のあるコードを含むライブラリが混入し、意図せず外部へ機微情報を送信してしまう
SSH などでコンテナにアクセスする権限を持った者が不正にデータを持ち出す

近年、ECS Fargate のようなサーバレスコンピューティング環境においても、上記のようなリスクの顕在化を検知・抑止する目的で、コンテナセキュリティを専門とする各社から対策製品や機能が提供されるようになってきています。
ECS Fargate の環境をサポートしているコンテナセキュリティ製品の代表例としては、Sysdig, Prisma Cloud, Aqua などが挙げられます。

Sysdig の概要

Sysdig は CNCF のオープンソースプロジェクトのひとつである Falco ¹ をベースとした、コンテナセキュリティのための SaaS です。
エージェントを対象の環境にインストールすることで収集したメトリクス・メタデータ・セキュリティイベントを SaaS バックエンド ² に転送し、ポリシに違反したセキュリティイベントのアラートやコンプライアンスの準拠チェックなどを行うことができます。
ランタイムポリシは記述形式に Falco ルールを用いた Sysdig Secure Rules と呼ばれるルールセットで定義され ³ 、エージェントはこのポリシに基づいてワークロードの挙動に対するイベント検出・キャプチャ・抑止などのアクションを行います。

以下は公式ドキュメントから引用した Sysdig のアーキテクチャ図です。

引用元

Sysdig では、保護するワークロードの実行環境に応じて 2 種類のエージェントが提供されています。

Sysdig Agent : ユーザが個別の仮想マシンの可視性を持つ EC2、オンプレミス、ベアメタル環境向けのエージェント（通常、Sysdig のエージェントと言うとこちらを指す）
Serverless Agent : サーバレスコンピューティング環境向けのエージェント（現在サポートされている環境は Fargate のみ）

エージェントが別々に用意されている理由には、Sysdig の Deep Instrumentation の仕組みが関係しています。
Sysdig Agent は、ホストにカーネルモジュールや eBPF プローブをインストールすることでシステムコールなどのカーネル内のイベントを収集します。
収集されたイベントはイベントバッファを通じてユーザランドのライブラリ ( libscap / libsinsp ) ⁴ に連携され、フィルタリングや加工を行ってから Sysdig のエンドポイントにデータを送ることで、ワークロードのセキュリティイベントを評価・可視化します。

引用元

一方、Fargate では同じこと（ホストにカーネルモジュールや eBPF プローブをインストール）ができません。
ものによっては CloudTrail や IDS / IPS の情報から検知できるセキュリティイベントもあるかと思いますが、より詳細で確実な分析を行うためにワークロードのシステムコールを観測することが必要となる場合があります。
このような背景から、Sysdig ではサーバレスコンピューティング環境向けの専用のエージェントが用意されています。

Serverless Agent では、ptrace を使ってシステムコールの観測を行う pdig ⁵ というライブラリが利用されています。
Fargate のプラットフォームバージョン v1.4.0 ( 2020 年 4 月リリース ⁶ ) が CAP_SYS_PTRACE の Linux capability をサポートしたことで、この実装が可能になりました。

Sysdig の Serverless Agent による ECS Fargate ワークロードの保護

Sysdig Serverless Agent を以下のように構成することで、ECS Fargate 環境のワークロードを保護することが可能です。

引用元

Sysdig Serverless Agent は 2 つのコンポーネントで構成されています。

Orchestrator Agent : (複数の) Workload Agent からセキュリティイベントを受信し、Sysdig Platform (SaaS エンドポイント等) に送信する。VPC 毎に必要
Workload Agent : 保護するアプリケーションと同じタスクにデプロイし、セキュリティイベントを収集、Orchestrator Agent に送信する。Fargate タスク定義毎に必要

Workload Agent は ptrace を用いてセキュリティイベントを収集するため、タスク定義にいくつかの設定を追加する必要が出てきます。
手動で設定することも可能ですが、アプリケーションの CloudFormation テンプレートに Workload Agent とその他必要な設定の一式を自動挿入してくれるマクロが Sysdig から提供されていますので、こちらを利用することも可能です。
マクロは AWS Lambda で実装されており、CloudFormation テンプレートの Transform セクションから呼び出すことで、アプリケーションのタスク定義に自動挿入する仕組み ⁷ となっています。

加えて、Sysdig Serverless Agent を利用するためには、X86_64 アーキテクチャを使用した Fargate タスクを定義する必要があります。
エージェントが ptrace に利用している pdig ライブラリのサポート対象は、現状 x86_64 のみとなっているためです。⁸
Fargate は、2021年11月のアップデートにより、従来から提供されてきた X86_64 アーキテクチャに加え、Graviton2 を使った ARM64 アーキテクチャ ⁹ も実行環境として利用可能になっています（タスク定義の runtimePlatform -> cpuArchitecture で指定、デフォルトは X86_64 ）が、Sysdig を利用する際には選択肢が限定される点に留意しておく必要があります。

なお、Serverless Agent のコンテナイメージは Quay で公開されています。¹⁰
記事執筆時点の最新は、Orchestrator Agent と Workload Agent のいずれも 2.3.0 となっています。
直近数回のリリース履歴を見るに、3 ヶ月程度で新しいバージョンがリリースされているようです。

docs.sysdig.com