🔐

Sysdig Serverless Workload Agent 5.3リリース!アップデートのポイントと導入事例

2025/02/03に公開

1. はじめに

ログラスでは、ECS on Fargate 上でサービスが稼働しています。この環境において、Sysdig を導入し、コンテナのセキュリティ対策を強化しています。

先日、Sysdigが提供している、 Serverless環境向けのセキュリティーツールであるWorkload Agent 5.3 がリリースされたとのことなので、早速導入してみました。今回はその導入手順や、バージョン変更前と後で構成がどのように変わったかをご紹介します。

また、今回はRedashが稼働しているECS on Fargate環境における導入事例を中心に説明します。

Sysdig導入の背景についてご興味のある方は、以下の記事もぜひご覧ください!
https://enterprisezine.jp/article/detail/20612

2. そもそもSysdigとは

Sysdigは、クラウドセキュリティの監視や管理をサポートするセキュリティプラットフォームです。
具体的には、以下のような機能を提供しています。

  • クラウド検知と対応
  • 脆弱性管理
  • ポスチャー管理
  • 権限とエンタイトルメントの管理

さらに、Terraform Providerの提供や、リスク検知ルールのカスタマイズなども柔軟に行えるため、運用面において、非常に助かっています。

3. Sysdig Serverless Workload Agent 5.3で何が変わったのか

さて、実際にバージョンが上がったことで、何が変わったのかを早速ご説明していきます。
前提として、以前導入していたSysdig Workload Agentのバージョンは5.2でした。

Workload Agent 5.3のリリースにより、最も大きな変更点は、Serverless Orchestrator Agentの構築が不要になったことだと思います。

以下、変更前と変更後の構成を簡単な図で表したものです。

変更前の構成

従来、Sysdig導入する際は以下のような構成が必要でした。

  • Serverless Orchestrator Agentロードバランサを構築
  • Workload Agentを対象タスクのサイドカーして起動。収集したデータは、ロードバランサ経由で Serverless Orchestrator Agentに収集され、そこからSysdigへ通信される。

変更後の構成

5.3のリリースにより、次のような構成での構築が可能となりました。

  • Serverless Orchestrator Agentロードバランサ は不要になり、Workload AgentSysdigがOrchestratorを介さず通信する。

このように、構成がシンプルになり、ECSクラスタやロードバランサを構築する必要がなくなったため、コスト削減も期待できるようになりました。

4. Sysdig Serverless Workload Agent 5.3の導入過程

では実際に、Redashが稼働しているECS on Fargate環境にSysdig Serverless Workload Agent 5.3を新規で導入した手順についてご説明します。

導入準備

ログラスでは、インフラの構成管理に基本的に Terraform を使用しています。以下は、Sysdig導入に必要なコードの一部です。
Redashの構築に必要なALBやIAM Roleなどのコードは今回省きます。

// ECSクラスター
resource "aws_ecs_cluster" "redash" {
  name = "${var.env}-redash"
  setting {
    name  = "containerInsights"
    value = "disabled"
  }
}

resource "aws_ecs_cluster_capacity_providers" "redash" {
  capacity_providers = [
    "FARGATE",
    "FARGATE_SPOT",
  ]
  cluster_name = aws_ecs_cluster.redash.name
}


// Sysdigワークロードエージェント
data "sysdig_fargate_workload_agent" "redash_instrumented" {
  container_definitions = local.redash_container_definition

  // version 5.3.0を指定
  workload_agent_image = "quay.io/sysdig/workload-agent:5.3.0"

  sysdig_access_key = <SYSDIG_ACCESS_KEY>
  collector_host    = <COLLECTOR_HOST>
  collector_port    = <COLLECTOR_PORT>
}

// タスク定義
resource "aws_ecs_task_definition" "redash" {
  container_definitions = data.sysdig_fargate_workload_agent.redash_instrumented.output_container_definitions
  cpu                   = "256"
  execution_role_arn    = aws_iam_role.ecs_task_execution_role.arn
  family                = "redash"
  memory                = "1024"
  network_mode          = "awsvpc"
  requires_compatibilities = [
    "FARGATE",
  ]
  task_role_arn = aws_iam_role.ecs_task.arn
  skip_destroy  = true
}

// ECSサービス
resource "aws_ecs_service" "redash" {
  cluster                            = aws_ecs_cluster.redash.arn
  deployment_maximum_percent         = 200
  deployment_minimum_healthy_percent = 100
  desired_count                      = 0
  enable_ecs_managed_tags            = true
  enable_execute_command             = true
  health_check_grace_period_seconds  = 180
  launch_type         = "FARGATE"
  name                = "redash"
  platform_version    = "LATEST"
  propagate_tags      = "NONE"
  scheduling_strategy = "REPLICA"
  tags                = {}
  tags_all            = {}
  task_definition     = aws_ecs_task_definition.redash.arn
  triggers            = {}

  deployment_circuit_breaker {
    enable   = true
    rollback = false
  }

  deployment_controller {
    type = "ECS"
  }

  load_balancer {
    container_name   = "redash-service"
    container_port   = 5000
    target_group_arn = aws_lb_target_group.redash.arn
  }

  network_configuration {
    assign_public_ip = false
    security_groups = [
      aws_security_group.redash_ecs.id
    ]
    subnets = var.private_subnets
  }

  timeouts {}
  lifecycle {
    ignore_changes = [
      desired_count
    ]
  }
}

// Sysdigへの通信を許可
resource "aws_security_group_rule" "workload_agent_egress_rule" {
  type      = "egress"
  protocol  = "all"
  from_port = 0
  to_port   = 0
  cidr_blocks = [
    "54.190.202.108/32",
    "54.203.169.53/32",
    "54.70.9.188/32"
  ]
  security_group_id = aws_security_group.redash_ecs.id
  description       = "for Sysdig"
}

workload agent構築には、Sysdigが提供している、sysdig_fargate_workload_agent Data Sourceを使用しています。

こちらもバージョン1.42.0以前と後では、渡せる引数に変更が加わっています。
以下を見ると、引数名に加え、アクセスキーも渡せるような変更が加えられているのが、わかるかと思います。

バージョン1.42.0以前

data "sysdig_fargate_workload_agent" "instrumented_containers" {
  container_definitions = "[]"

  image_auth_secret    = ""
  workload_agent_image = "quay.io/sysdig/workload-agent:latest"

  orchestrator_host    = module.fargate-orchestrator-agent.orchestrator_host
  orchestrator_port    = module.fargate-orchestrator-agent.orchestrator_port
}

バージョン1.43.0以降

data "sysdig_fargate_workload_agent" "instrumented_containers" {
  container_definitions = "[]"

  workload_agent_image = "quay.io/sysdig/workload-agent:latest"

  collector_host    = <COLLECTOR_HOST>
  collector_port    = <COLLECTOR_PORT>
  sysdig_access_key = <SYSDIG_ACCESS_KEY>
}

今回Serverless Orchestrator Agentの構築は行わないので、バージョン1.43.0以降のデータソースを使用しています。

注意点

  • Redashが稼働しているECS on Fargateのネットワーク設定
    Redashはプライベートサブネット内で稼働しており、外部との通信にはNAT Gatewayを使用しています。このため、Sysdigのドキュメントに記載されているIP Rangeを参考に、適切なSecurity Groupの設定を行う必要があります。

  • Redashの起動設定
    Redashは内部的に
    ENTRYPOINT ["/app/bin/docker-entrypoint"]を指定して実行されます。そのため、Sysdigの提供するsysdig_fargate_workload_agent Data Sourceを使用すると、Entrypointが上書きされてしまい、コンテナが正しく起動しない可能性があります。

  • プライベートレジストリからのイメージ取得時の注意点
    プライベートレジストリからRedashのイメージを取得する際、ENTRYPOINTとCommandを明示的に記載する必要があります。上記の理由で、Sysdigのsysdig_fargate_workload_agentを使用すると、エントリポイントが上書きされてしまい、コンテナがうまく起動しない可能性があるためです。
    詳細については、公式ドキュメントを参照してください。

  • Orchestrator Agentの非推奨化
    Orchestrator Agentは将来的に非推奨となる記載が公式ドキュメントにもあるので、早めに対応したほうが良さそうです。

回避策

  • sysdig_fargate_workload_agentを使用する際の回避方法
    プライベートレジストリからRedashイメージを取得し、sysdig_fargate_workload_agentを使用する場合に発生する問題を回避する方法の一つとして、ECSのタスク定義でRedashのENTRYPOINTに相当するコマンドをCommandとして明記することが有効です。

この設定を行うことで、ENTRYPOINTにはSysdigのworkload agent起動コマンドが、CommandにはRedashの起動コマンドが記載されるため、互いが干渉せず、問題なくコンテナを起動することができます。

最終的なタスク定義の例としては、以下のようになります:

    {
      "name": "redash-service",
      "command": [
        "/app/bin/docker-entrypoint", // RedashのEntrypointで実行されていた内容
        "server"
      ],
      "entryPoint": ["/opt/draios/bin/instrument"], // Sysdig Workload Agent起動用エントリポイント

動作確認

導入準備が整ったら、Terraformを使用して差分を適用し、SysdigダッシュボードでWorkload Agentの動作確認を行います。

ダッシュボード上でIntegrations > Data Sources > Sysdig Agentsを確認し、追加したworkload agentが追加されていれば、Sysdigの導入は完了です。

以下は、適用後に確認したダッシュボードのスクリーンショットです。バージョン5.3.0
問題なく動作していることが確認できます。

5. まとめと今後の展望

Sysdig Serverless Workload Agent 5.3 の導入によって、次のような効果が得られました。

  • 構成管理の簡素化: Serverless Orchestrator Agentが不要となり、システム構成がシンプルになりました。
  • コスト削減: 必要なリソースが減ったため、コストの削減が期待できます。

今後は、古いバージョンのSysdig で稼働しているコンテナや、まだSysdigを導入していないコンテナへの導入を進める予定です。

さらなる効率化とセキュリティ強化を目指してSysdigの運用を続けていきます!

株式会社ログラス テックブログ

Discussion