本文の内容は、docs.sysdig.com上のAWS Fargate Serverless Agentsを元に日本語に翻訳・再構成した内容となっております。(2022年5月17日現在)
サーバーレス・エージェント
概要
サーバーレスの環境やクラウドプラットフォームの進化に伴い、利便性と抽象度が同時に向上し、新しいエージェントモデルが求められています。例えば、AmazonのECSやEKSでは、ユーザーは基盤となる仮想ホストマシンの管理を引き続き担当しています。しかし、Fargateのような環境では、ホストはクラウド事業者によって暗黙のうちに割り当てられており、ユーザーは、基盤となるコンピュートインフラの割り当てや設定、知識を持たずに、単にコンテナを実行するだけです。
この「サービスとしてのコンテナ」モデルは便利ですが、多くのユーザーがコンテナを放置し、コンテナ内のセキュリティイベントを監視しないため、シークレットの流出、ビジネスデータの漏洩、パフォーマンスへの影響、AWS/クラウドプロバイダーのコスト増などのリスクが発生します。また、ホストにアクセスできない環境では、標準的なエージェントをインストールすることができません。
このような理由から、Sysdigは、このようなコンテナベースのクラウド環境に導入可能な「サーバーレスエージェント」を新たに開発しました。
AWS Fargate ECS サーバーレスエージェント
アーキテクチャー
Sysdigのサーバーレスエージェントは、Falcoによるポリシーエンフォースメントでランタイム検知を行います。現時点では、サーバーレスエージェントはECS上のAWS Fargateで利用可能です。このエージェントは、オーケストレーター・エージェントと(複数の可能性のある)ワークロード・エージェントで構成されます。- Sysdig サーバーレス・オーケストレーター・エージェントは、各ECSクラスターにインストールされた収集ポイントで、サーバーレス・ワークロード・エージェントからデータを収集し、Sysdigのバックエンドに転送します。また、FalcoのランタイムポリシーとルールをSysdigのバックエンドからワークロードエージェントに同期させます。
- Sysdig サーバーレスワークロードエージェントは各タスクにインストールされ、オーケストレーターエージェントと通信するためにネットワークアクセスが必要です。
インストール:Fargate ECS
Fargate ECSの場合、サーバーレスエージェントの2つのコンポーネントは別々にインストールされます。- オーケストレーターエージェントについては、SysdigがCloudFormation Templateとして使用するyamlを提供しており、これをAWSコンソールからデプロイすることができます。組織がセキュリティを確保したい環境のVPCごとに、オーケストレーターのデプロイが1つ必要です。
- ワークロードエージェントについては、Fargateのタスク定義ごとに1つのワークロードエージェントが必要です。(10個のサービスと10個のタスク定義がある場合、それぞれにインスツルメンテーションが必要です)。
ここでは、サービスが既存のCFT(CloudFormation Templates)を使用しており、CFT内のすべてのタスク定義を計測する自動プロセスを使用してワークロードエージェントをインストールすることを想定しています。
前提条件
AWS側:- AWS CLIが設定されており、S3バケットを作成・使用する権限があること
- repoへのイメージのアップロード、CFTのデプロイ、Fargate用のタスク定義の作成のパーミッション
- Sysdigのサーバーレス・エージェントでインストルメントしたいFargateのタスク
- インターネットに接続可能な2つのサブネット。(Fargate上のサービスはオーケストレーター・エージェントに到達する必要があり、オーケストレーター・エージェントはSysdigのバックエンドと通信するためにインターネットに到達する必要があります。)
- NATゲートウェイまたはAWSインターネットゲートウェイで、オーケストレーターエージェントがSysdigにアクセスできるようにする。
Sysdig側:
- Sysdig Secure (SaaS)
- Sysdig エージェントキー
- 使用するエンドポイントは、SaaSのリージョンとIPレンジをご確認ください。
オーケストレーター・エージェントのインストール
- CloudFormationテンプレートのソースとして使用するSysdig Orchestrator Agent yamlを入手します。
- CloudFormation(CFN)の詳細については、AWSのドキュメントを参照してください。
- CloudFormationを使用して、目的のVPCごとにオーケストレーター・エージェントをデプロイします。
- AWS コンソールにログインします。「CloudFormation」と「Create Stack with new resources」を選択し、Template sourceに「orchestrator-agent.yaml」を指定する。
- スタックの詳細を指定して、サービスが稼働しているのと同じVPCにオーケストレーターエージェントをデプロイします。
Stack name:self-defined
Sysdigの設定
- Sysdig Access Key:Sysdigプラットフォームのagent key を使用します。
- Sysdig Collector Host: collector.sysdigcloud.com (デフォルト); Sysdig SaaSでは地域に依存します。Sysdig on-premではカスタムです。
- Sysdig Collector Port: 6443 (デフォルト)、オンプレミスの場合はカスタムでも可。
ネットワーク設定
- VPC Id :VPCを選択します。
- Subnet A & B: 選択したVPCに応じて、ドロップダウンメニューから選択します。
高度な設定
- Sysdig Agent Tags: タグのコンマ区切りリストを入力してください (例: role:webserver,location:europe)注意: タグは、AWS、Dockerなどのインフラストラクチャーのメタデータからも自動的に作成されます。
- Sysdig Orchestrator Agentのイメージ:
- quay-io/orchestrator-agent:latest (デフォルト)
- Collector SSL Certificateのチェック:デフォルト:true。Falseは、コレクターから受け取ったSSL証明書の検証が行われないことを意味し、開発目的でのみ使用されます。
- Sysdig Orchestrator Agent Port: 6667 (デフォルト)。オーケストレーターサービスがインスツルメンテッドタスクの接続をリッスンするポートです。
「Next」をクリックしてスタックの作成を完了し、デプロイメントが完了するのを待ちます(通常は10分以内です)。
「Output」では、「OrchestratorHost」と「OrchestratorPort」の値に注意してください。
備考:
- Serverless Agent Version 2.2.0では、CloudFormationテンプレートのSYSDIG_ORCHESTRATOR_PORT(デフォルト6667、CFTの他の部分にハードコードされています)またはSysdigOrchestratorAgentPort(代替)パラメータでオーケストレータポートを設定することが可能です。
- AWS Internet Gatewayを使用する場合(NAT Gatewayではなく)、orchestrator yamlのAssignPublicIp.ENABLEDの行をアンコメントします。
ワークロードエージェントのインストール
オプション1:自動化プロセス(Kilt)
- 前提条件:適切なVPCにオーケストレータエージェントをデプロイし、オーケストレータのホストとポートの情報を手元に用意します。
- お使いのOSに適したインストーラーをダウンロードします。
- インストーラーを使用して、サーバーレスワーカーエージェントのマクロを作成します。このマクロがタグ付けされたサービスには、サーバーレスワーカーエージェントが追加され、Fargateのデータが収集されます。
- AWS CLIにログインします。
- インストルメンテーションを適用するCFNマクロを作成します。前のタスクのアウトプットが必要になります。例を挙げます。
./installer-linux-amd64 cfn-macro install -r us-east-1 MySysdigMacro $OrchestratorHost $OrchestratorPort
- 作成したマクロを、自分のサービスに使用するCFTにrootで追加します。
- Use: Transform: MySysdigMacro.
- そのテンプレートの新しいデプロイメントはすべてインストルメント化されます。
- 備考:CFTのEntrypointとCommandを定義する。
このステップでは、マクロはオリジナルのCloudFormation Templateを調べ、インストルメントするContainerDefinitionsを探します。これには、オリジナルのエントリポイントをSysdigエントリポイントに置き換えることも含まれるため、CFTにはEntrypointとCommandを明示的に記述するのが理想的です。そうでない場合、マクロはイメージをプルしてデフォルトのEntrypointとCommandを取得しようとしますが、これはイメージが公開されている場合のみ機能します。これは、画像が公開されている場合にのみ機能します。そうでない場合、pull は失敗し、インスツルメンテーションは完了しません。
- 完了!
- インスツルメンテーションが完了すると、FargateのイベントがSysdig Secure Eventsのフィードに表示されるようになります。
オプション2:自動化プロセス Terraform
また、以下に説明するように、Terraformレジストリ上のSysdig Providerを使用してワークロードエージェントを デプロイすることもできます。- 1. 前提条件 :オーケストレーターエージェントを適切なVPCにデプロイし、オーケストレーターホストとポート情報を手元に用意しておきます。
- Sysdig Terraformプロバイダーをセットアップします。
terraform { required_providers { sysdig = { source = "sysdiglabs/sysdig" version = ">= 0.4.0" } } } provider "sysdig" { sysdig_secure_api_token = var.sysdig_access_key }
- sysdig_fargate_workload_agent データソースに、コンテナ定義、オーケストレーターホスト、オーケー ストレーターポートを渡す。
- 入力するコンテナ定義は、CloudFormation の命名規則に従い、JSON 形式で記述する必要があります。
- オーケストレーターエージェントをデプロイする場合、ポートは常に6440になります。
- オーケストレーターエージェントをデプロイする場合、ホストはSysdigリージョンのコレクターエンドポイントです(例:US Eastの場合は “collector-static.sysdigcloud.com”)。その他のリージョンについては、SaaS リージョンと IP レンジを参照してください。
data "sysdig_fargate_workload_agent" "instrumented" { container_definitions = file("container-definitions/hello.json") sysdig_access_key = var.sysdig_access_key workload_agent_image = "quay.io/sysdig/workload-agent:latest" orchestrator_host = module.sysdig_orchestrator_agent.orchestrator_host orchestrator_port = module.sysdig_orchestrator_agent.orchestrator_port }
- Fargateのタスク定義に、インスツルメンテッドJSONを含めます。
resource "aws_ecs_task_definition" "fargate_task" { ... network_mode = "awsvpc" requires_compatibilities = ["FARGATE"] container_definitions = "${data.sysdig_fargate_workload_agent.instrumented.output_container_definitions}" }
- 完了
インストルメンテーションが完了すると、Sysdig Secure EventsのフィードにFargateのイベントが表示されるようになるはずです。
(https://docs.sysdig.com/en/docs/installation/serverless-agents/aws-fargate-serverless-agents/manage-serverless-agent-logs) を参照してください。
ワークロードエージェント用環境変数
最も一般的に使用される変数には、以下のものがあります。- SYSDIG_ORCHESTRATOR: (必須) 出力されたOrchestratorHostの値を使用します。
- SYSDIG_ORCHESTRATOR_PORT: (必須) 出力された OrchestratorPort の値を使用します。
- SYSDIG_EXTRA_ARGS: インストルメンテーションに必要な追加の引数を渡すために使用します。
- SYSDIG_EXTRA_CONF: インストルメンテーションに必要な設定を追加するために使用します。
- SYSDIG_LOGGING: この変数を追加し、必要であればデバッグに設定します。それ以外の値では、起動時に最小限のログを出力します。こちらもご参照ください。サーバーレスエージェントのログを管理する
ワークロード・エージェントにおけるマニュアルインストルメンテーション
場合によっては、KiltやTerraformのインストーラーを使用せず、次のいずれかを行うことをお勧めします。- タスク定義のインストーラ、または
- コンテナイメージのインストーラ(稀です)
オプションA: インストルメントのタスク定義
- インストールの概要と前提条件を確認します。
- 上記のように、Orchestrator Agentをインストールします。OrchestratorHostとOrchestratorPortの値をメモしておきます。
- ワークロードエージェントを手動でデプロイするために、CloudFormationのタスク定義を実装します。
- 既存のCloudFormationタスク定義に新しいコンテナを追加します。
- この例では、イメージ名にSysdigInstrumentationを使用します。
- エントリーポイント/コマンドフィールドは空欄で構いません。
- quay.io/sysdig/workload-agent:latestからイメージを取得します。
- インストルメント化したいコンテナを編集します。
- SysdigInstrumentationからボリュームをマウントします。
- コンテナにSYS_PTRACEケイパビリティを追加します。必要であれば、AWSドキュメントを参照してください。
- コンテナのエントリーポイントとして、/opt/draios/bin/instrumentを設定します。
- 注:イメージでエントリポイントを使用している場合は、その前に次のように追加します:/opt/draios/bin/instrument,your,original,entry,pointentry、point
- 環境変数でSysdigインストルメントを設定します。
タスク定義例
CloudFormation タスク インストゥルメンテーションの前に `TestApp:
Type: AWS::ECS::TaskDefinition
Properties:
NetworkMode: awsvpc
RequiresCompatibilities:
- FARGATE
Cpu: 2048
Memory: 8GB
ExecutionRoleArn: !Ref TestAppExecutionRole
TaskRoleArn: !Ref TestAppTaskRole
ContainerDefinitions:
- Name: App
Image: !Ref TestAppImage
EntryPoint:
- /bin/ping
- google.com
Tags:
- Key: application
Value: TestApp
マニュアルインストルメンテーション後のタスク
TestApp:
Type: AWS::ECS::TaskDefinition
Properties:
NetworkMode: awsvpc
RequiresCompatibilities:
- FARGATE
Cpu: 2048
Memory: 8GB
ExecutionRoleArn: !Ref TestAppExecutionRole
TaskRoleArn: !Ref TestAppTaskRole
ContainerDefinitions:
- Name: App
Image: !Ref TestAppImage
EntryPoint:
### Added for manual instrumentation
- /opt/draios/bin/instrument
### End added propertis
- /bin/ping
- google.com
### Added for manual instrumentation
LinuxParameters:
Capabilities:
Add:
- SYS_PTRACE
VolumesFrom:
- SourceContainer: SysdigInstrumentation
ReadOnly: true
Environment:
- Name: SYSDIG_ORCHESTRATOR # Required
Value: <host orchestrator output, region dependent>
- Name: SYSDIG_ORCHESTRATOR_PORT # Required
Value: "6667"
- Name: SYSDIG_ACCESS_KEY
Value: ""
- Name: SYSDIG_COLLECTOR
Value: ""
- Name: SYSDIG_COLLECTOR_PORT
Value: ""
- Name: SYSDIG_LOGGING
Value: ""
- Name: SysdigInstrumentation
Image: !Ref WorkloadAgentImage
### End of added properties
Tags:
- Key: application
Value: TestApp
オプションB:コンテナイメージ内のインストルメント
また、ビルド時にワークロードエージェントをコンテナに含めることもできます。そのためには、Dockerfileを更新して、必要なファイルをコピーします。ARG sysdig_agent_version=latest
FROM quay.io/sysdig/workload-agent:$sysdig_agent_version AS workload-agent
FROM my-original-base
COPY --from=workload-agent /opt/draios /opt/draios
コンテナのエントリポイントに /opt/draios/bin/instrument コマンドをプレインストールします。
ENTRYPOINT ["/opt/draios/bin/instrument", "my", "original", "entry", "point"]
ログに関する注意事項
ワークロードログからインストルメンテーションログを分離するために、インストルメンテーションエントリポイントはログを localhost:32000 に送信しようとしますが、そこではワークロードログと混合されます。- 手動インストールでインスツルメンテーションログを分離したい場合、オプションAを使用することをお勧めします。
- ログスパムを回避するには、SYSDIG_LOGGINGをsilentに設定します。
アップグレード:Fargate ECS用
備考
サーバーレスエージェントをアップグレードするには、両方のコンポーネントの2つ目のバージョンをインストールしてから、実行中のタスクをすべて終了し、新しいバージョンで再起動します。その後、古いCloudFormationとKiltの残留物を削除してクリーンアップします。
- CloudFormation Templateのソースとして使用するSysdig Orchestrator Agentのyaml を入手します。
現時点では、yamlのメタデータにはエージェントのバージョンが明記されていませんが、このリンクから常に最新のファイルをダウンロードします。 - Orchestrator Agentをインストールするための手順を実行します。
なお、ステップ2.4では、OrchestratorHostとOrchestratorPortの値が一意になるようにします。 - ワークロードエージェントのインストールの手順を実行します。
- TerraformでインストールしたWorkload Agentは自動的に_latestに更新されます。)手動でインスツルメンテーションを行う場合は、手動でやり直す必要があります)
- ステップ4で、マクロに一意な名前を付けます(Transform: MyV2SysdigMacro)
- これで、サーバーレスエージェントコンポーネントのバージョンが2つになりました。以前のバージョンから切り替える準備ができたら、次のステップに進んでください。
- すべての実行中のタスクを停止し、CloudFormataionを使用して以前のスタックを削除します。更新されたCFTで新しいスタックを再デプロイします。(Transform: MyV2SysdigMacro)
- マクロのクリーンアップ:インストーラーを使って、以前のkiltマクロを削除します。
./installer-linux-amd64 cfn-macro delete MySysdigMacro