Sysdig Serverless Workload Agent 5.3リリース!アップデートのポイントと導入事例
1. はじめに
ログラスでは、ECS on Fargate 上でサービスが稼働しています。この環境において、Sysdig を導入し、コンテナのセキュリティ対策を強化しています。
先日、Sysdigが提供している、 Serverless環境向けのセキュリティーツールであるWorkload Agent 5.3 がリリースされたとのことなので、早速導入してみました。今回はその導入手順や、バージョン変更前と後で構成がどのように変わったかをご紹介します。
また、今回はRedashが稼働しているECS on Fargate環境における導入事例を中心に説明します。
Sysdig導入の背景についてご興味のある方は、以下の記事もぜひご覧ください!
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 AgentとSysdigが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