Terraformを活用したSysdigによるコンテナセキュリティのコード化

デモを依頼
By 清水 孝郎 - APRIL 3, 2025
Topics: Sysdig機能

SHARE:

本文の内容は、2025年3月25日に Jorge Salamero Sanz が投稿したブログ(https://sysdig.com/blog/using-terraform-for-container-security-as-code/)を元に日本語に翻訳・再構成した内容となっております。

このブログ記事では、Sysdig Terraformプロバイダーを使用して、インフラストラクチャーのセキュリティ設定を管理・自動化する方法を学びます。Terraformプロバイダーとは、Terraformにおけるプラグインのようなもので、HCL言語で定義されたコードに基づき、さまざまなAPIと連携してインフラや設定を作成するために必要なロジックがすべて含まれています。

このプロバイダーを使用すると、次のことが可能になります。

  • 設定のバージョン管理: Sysdig 設定を Git リポジトリに保存して管理します。これにより、チームは変更について共同作業し、更新を確認し、リビジョンを追跡できます。必要に応じて、以前のバージョンに簡単にロールバックすることもできます。
  • 環境間での一貫性の確保: Terraform を使用して開発、ステージング、本番環境間で構成を複製し、一貫性を確保してドリフトを回避します。複数の環境を管理する場合でも、環境固有の変数を動的に渡すことで単一のプロバイダー ブロックを再利用でき、全体的な構成を簡素化できます。
  • 反復タスクの自動化:アラート、ポリシー、その他の構成の作成を自動化することで時間を節約します。
  • 統合ワークフロー: Sysdig Secure と Monitor の両方のリソースを単一のツールを使用して管理します。たとえば、Sysdig Secure でランタイム ポリシーを作成し、同じ Terraform 構成内で Sysdig Monitor で監視アラートを構成できます。これにより、複雑さが軽減され、ワー​​クフローの効率が向上します。

Sysdig Terraform プロバイダーのインストール

はじめに、Terraformのバージョンが0.13以上であることを確認してください。Terraformを初めて使用する場合は、以下の内容でmain.tfファイルを作成し、terraform initコマンドを実行してプロジェクトを初期化してください。

terraform {
  required_providers {
    sysdig = {
      source = "sysdiglabs/sysdig"
      version = ">=1.46.0"
    }
  }
}

これにより、環境が設定され、 Terraform Registryで利用可能なプロバイダーがダウンロードされます。

Sysdig プロバイダーの設定

Sysdig プロバイダーは、Sysdig Secure と Sysdig Monitor の両方のリソースとデータソースをサポートしています。Sysdig Secure はランタイム セキュリティ、コンプライアンス、脆弱性管理に重点を置いており、Sysdig Monitor は高度な監視、アラート、ダッシュボードですべてのメトリクスを分析する機能を提供します。

各サービスには独自のAPI トークンとエンドポイントが必要であり、ユーザーは対象を絞った構成で個別のユースケースに対応できます。

Secureの認証

provider "sysdig" {
  sysdig_secure_url      = "https://secure.sysdig.com"
  sysdig_secure_api_token = "<your_secure_api_token>"
}

Monitorの認証

provider "sysdig" {
  sysdig_monitor_url     = "https://app.sysdigcloud.com"
  sysdig_monitor_api_token = "<your_monitor_api_token>"
}

Secure認証とMonitor認証の組み合わせ

また、単一のプロバイダー ブロック内で Secure と Monitor の構成を組み合わせることもできます。このアプローチにより、ユーザーは 1 か所で Secure と Monitor の設定を定義できるため、管理が簡素化されます。また、extra_headersブロックを通じて追加の HTTP ヘッダーを含めることができるため、プロキシを使用する環境もサポートされます。

provider "sysdig" {
  sysdig_secure_url       = "https://secure.sysdig.com"
  sysdig_secure_api_token = "<your_secure_api_token>"

  sysdig_monitor_url      = "https://app.sysdigcloud.com"
  sysdig_monitor_api_token = "<your_monitor_api_token>"

  extra_headers = {
    "Proxy-Authorization" = "Basic xxxxxxxxxxxxxxxx"
  }
}

サポートされているリソースとデータソース

Sysdig Terraformプロバイダーは、Sysdig Platform、Sysdig Secure、Sysdig Monitor向けにさまざまなリソースおよびデータソースをサポートしています。以下はその概要です。

Sysdig プラットフォーム (MonitorとSecureの両方)

  • ユーザーおよびアクセス管理:ユーザー、ロール、サービス アカウント (例: sysdig_user、sysdig_custom_role) を管理します。
  • IP フィルタリング:プラットフォーム アクセスの IP 制限を構成します (例: sysdig_ip_filter)。

Sysdig Secure

  • ポリシー:ランタイム ポリシーと脆弱性ポリシーを作成します (例: sysdig_secure_policy)。
  • コンプライアンスコントロール:ポスチャーコントロールを定義します (例: sysdig_secure_posture_control)。
  • ルール: Falco 構文 (例: sysdig_secure_rule) を使用してランタイム ルールを実装します。
  • 通知チャネル:電子メール、Slack、その他の統合 (例: sysdig_secure_notification_channel_slack) のアラートを設定します。
  • マクロとリスト:複数の Falco ルール (例: sysdig_secure_macro、sysdig_secure_list) にわたってロジックを再利用します。

Sysdig Monitor

  • アラート:
    メトリクス、PromQLクエリ、または異常な動作から検知された異常（例： sysdig_monitor_alert_metric)によってトリガーされるアラートを作成します。
  • ダッシュボードとチーム:ダッシュボードとユーザー チームをコードで管理し、表示設定をコードとして構成します (例: sysdig_monitor_dashboard)。
  • 通知チャネル: PagerDuty、Webhook、電子メールなどのアラートの統合を構成します (例: sysdig_monitor_notification_channel_email)。

高度なユースケース

構成の複製自動化

組織では、開発、ステージング、本番環境など、複数の環境を使用することがよくあります。Sysdig Terraform プロバイダーは、これらの環境間で構成を効率的に複製およびテストするのに役立ちます。例:

  • カスタム Falco ルール: ステージングでランタイム検知ルールをテストして検証してから本番環境に移行し、中断やノイズを削減します。
  • コンプライアンス ポリシー: Terraform を使用して、Rego ベースのポリシーを段階的にデプロイし、環境全体でポリシーを調整および検証します。

Terraformは、プロバイダーブロックとステートファイルを使用して、各環境が一貫した設定でプロビジョニングされるようにし、ドリフトを防ぎます。その宣言的なモデルにより、望ましい最終状態を定義するだけで、Terraformがその状態に一致するように必要な手順を自動で実行します。これにより手動によるミスが減り、プロセス全体の効率が向上します。さらに、必要な状態がコードとして定義されているため、Gitのようなバージョン管理システムに保存することで、過去の変更をすべて追跡し、新しい変更をレビューしたり、必要に応じてロールバックしたりすることが可能になります。

デバッグ

構成のトラブルシューティングやTerraformの実行時のデバッグを行うには、TF_LOG=DEBUGという環境変数を設定することで詳細なログを有効にできます。これにより、API呼び出しやその他の詳細が表示され、問題の特定に役立ちます。

チュートリアル: ゼロからコードとしてポリシーを作成する

ここで、Terraform とプロバイダーを使用して環境を構成したい人の立場になって考えてみましょう。まず、main.tfプロバイダーの構成を含むファイルの作成を開始します。

terraform {
  required_providers {
    sysdig = {
      source = "sysdiglabs/sysdig"
      version = ">=1.46.0"
    }
  }
}

provider "sysdig" {
  sysdig_secure_url      = "https://secure.sysdig.com"
  sysdig_secure_api_token = "<your_secure_api_token>"
}

実行するとterraform init次のメッセージが表示されます。

Initializing the backend...

Initializing provider plugins...

- Finding sysdiglabs/sysdig versions matching "1.46.0"...

- Installing sysdiglabs/sysdig v1.46.0...

- Installed sysdiglabs/sysdig v1.46.0 (signed by a HashiCorp partner, key ID 0A2458C5D4F39147)

Partner and community providers are signed by their developers.

If you'd like to know more about provider signing, you can read about it here:

https://www.terraform.io/docs/cli/plugins/signing.html

Terraform has created a lock file .terraform.lock.hcl to record the provider

selections it made above. Include this file in your version control repository

so that Terraform can guarantee to make the same selections by default when

you run "terraform init" in the future.

Terraform has been successfully initialized!

ポリシー

私たちは、組織内のコンテナでターミナルシェルが実行されたことを検知したいと考えています。このイベントは通常セキュリティリスクを伴います。なぜなら、本番コンテナ内でシェルを起動することは、不正アクセス、構成ミス、あるいはコンテナ環境を悪用しようとする試みを示している可能性があるからです。

まずは、ポリシーの作成から始めましょう。

resource "sysdig_secure_custom_policy" "terminal_shell_in_container" {
  depends_on = [sysdig_secure_rule_falco.terminal_shell_in_container]
  
  name = "Terminal shell in container"
  description = "Detected a terminal shell being open within a container"
  severity = 4
  enabled = true

  actions {
    capture {
      name = "terminal-shell.scap"
      seconds_before_event = 5
      seconds_after_event = 10
    }
  }
}

全体的なポリシーは定義しましたが、ポリシーとはあくまでルールの集合体に追加の振る舞いを加えたものであり、この場合のようにイベントを取り巻くすべてのシステムコールをキャプチャするようになっています。しかし、これだけでは何も検知されません。したがって、ポリシーにルール（または複数のルール）を組み込む必要があります。

ルール

Falco ルール構文に従って、Terraform を使用して Sysdig Secure でカスタムルールを作成できます。Falco は、システムコールデータを活用して、疑わしいアクティビティを正確に検知できるようにします。この場合、コンテナ内で開かれているターミナルシェルを検知するカスタムルールを作成します。今すぐ構文を理解する必要はありません。Sysdig はすでに 1400 を超えるルールを提供しているため、いつでもデフォルトのルールを確認して独自のルールを作成できます。

resource "sysdig_secure_rule_falco" "terminal_shell_in_container" {
  name        = "Terminal shell in container" // ID
  description = "A shell was used as the entrypoint/exec point into a container with an attached terminal."
  tags        = ["container", "shell"]

  condition = "(evt.type in (execve, execveat) and evt.dir=<) and (container.id != host) and (proc.name in (ash, bash, csh, ksh, sh, tcsh, zsh, dash))"
  output    = "A shell was spawned in a container with an attached terminal (user=%user.name %container.info shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline terminal=%proc.tty container_id=%container.id image=%container.image.repository)"
  priority  = "notice"
  source    = "syscall"
}

ご覧のとおり、ルールの条件には複数のFalcoフィールドイベントが指定されており、必ずしも読みやすいとは言えません。さらに、変更が必要な場合には、そのロジックを再解釈する必要があります。加えて、検出対象のシェルがルール内にハードコードされている点も、改善の余地があります。

ここで活躍するのが、Falcoのリストとマクロの概念です。

シェルのリストの抽出

検知したいシェルのリストを抽出することで、ルールを強化できます。これにより、リストを一元化することで保守性が向上し、ルールを直接変更せずに将来的に更新しやすくなります。

resource "sysdig_secure_list" "shell_binaries" {
  name = "shell_binaries"
  items = ["ash", "bash", "csh", "ksh", "sh", "tcsh", "zsh", "dash"]
}

resource "sysdig_secure_rule_falco" "terminal_shell_in_container" {
  depends_on = [sysdig_secure_list.shell_binaries]
  
  name        = "Terminal shell in container" // ID
  description = "A shell was used as the entrypoint/exec point into a container with an attached terminal."
  tags        = ["container", "shell"]

  condition = "(evt.type in (execve, execveat) and evt.dir=<) and (container.id != host) and (proc.name in (${sysdig_secure_list.shell_binaries.name}))"
  output    = "A shell was spawned in a container with an attached terminal (user=%user.name %container.info shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline terminal=%proc.tty container_id=%container.id image=%container.image.repository)"
  priority  = "notice"
  source    = "syscall"
}

ご覧のとおり、ルールの条件を更新して、以前に作成したリストを参照し、 depends_on ステートメントを通じてルールがそのリストに依存するようにしました。

マクロを抽出して参照することで、条件をさらに簡素化できます。

マクロの抽出

resource "sysdig_secure_list" "shell_binaries" {
  name = "shell_binaries"
  items = ["ash", "bash", "csh", "ksh", "sh", "tcsh", "zsh", "dash"]
}

resource "sysdig_secure_macro" "shell_procs" {
  depends_on = [sysdig_secure_list.shell_binaries]
  
  name = "shell_procs"
  condition = "(proc.name in (${sysdig_secure_list.shell_binaries.name})"
}

resource "sysdig_secure_macro" "spawned_process" {
  name = "spawned_process"
  condition = "(evt.type in (execve, execveat) and evt.dir=<)"
}

resource "sysdig_secure_macro" "container" {
  name = "container"
  condition = "(container.id != host)"
}

resource "sysdig_secure_rule_falco" "terminal_shell_in_container" {
  depends_on = [sysdig_secure_macro.shell_procs, sysdig_secure_macro.spawned_process, sysdig_secure_macro.container]
  
  name        = "Terminal shell in container" // ID
  description = "A shell was used as the entrypoint/exec point into a container with an attached terminal."
  tags        = ["container", "shell"]

  condition = "(${sysdig_secure_macro.shell_procs.name} and ${sysdig_secure_macro.spawned_process.name} and ${sysdig_secure_macro.container.name})"
  output    = "A shell was spawned in a container with an attached terminal (user=%user.name %container.info shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline terminal=%proc.tty container_id=%container.id image=%container.image.repository)"
  priority  = "notice"
  source    = "syscall"
}

resource "sysdig_secure_custom_policy" "terminal_shell_in_container" {
  depends_on = [sysdig_secure_rule_falco.terminal_shell_in_container]
  
  name = "Terminal shell in container"
  description = "Detected a terminal shell being open within a container"
  severity = 4
  enabled = true

  rules {
    name = sysdig_secure_rule_falco.terminal_shell_in_container.name
    enabled = true
  }

  actions {
    capture {
      name = "terminal-shell.scap"
      seconds_before_event = 5
      seconds_after_event = 10
    }
  }
}

これで、適用する最終コードが完成しました。マクロによって条件の可視性が向上していることに注目してください。マクロに名前を付けることで、その目的を明確に識別できます。このアプローチにより、複雑な条件が簡素化され、更新やデバッグがはるかに管理しやすくなります。

次に、terraform applyを使用してこれらのリソースをTerraformで適用することができます。

Plan: 6 to add, 0 to change, 0 to destroy.
sysdig_secure_macro.spawned_process: Creating...
sysdig_secure_macro.container: Creating...
sysdig_secure_list.shell_binaries: Creating...
sysdig_secure_macro.spawned_process: Creation complete after 9s [id=26732344]
sysdig_secure_list.shell_binaries: Still creating... [10s elapsed]
sysdig_secure_macro.container: Still creating... [10s elapsed]
sysdig_secure_list.shell_binaries: Creation complete after 16s [id=26732345]
sysdig_secure_macro.shell_procs: Creating...
sysdig_secure_macro.container: Still creating... [20s elapsed]
sysdig_secure_macro.container: Creation complete after 23s [id=26732346]
sysdig_secure_macro.shell_procs: Still creating... [10s elapsed]
sysdig_secure_macro.shell_procs: Creation complete after 20s [id=26732347]
sysdig_secure_rule_falco.terminal_shell_in_container: Creating...
sysdig_secure_rule_falco.terminal_shell_in_container: Creation complete after 7s [id=26732348]
sysdig_secure_custom_policy.terminal_shell_in_container: Creating...
sysdig_secure_custom_policy.terminal_shell_in_container: Creation complete after 0s [id=10410832]

Apply complete! Resources: 6 added, 0 changed, 0 destroyed.

Sysdig Secure で結果を確認できます。ルールが添付されたポリシーが作成されました。

Sysdig Terraform プロバイダー

これは、次の例のように、Sysdig がコンテナ内でターミナルが開かれたことを検知するとすぐにトリガーされます。

まとめ

Sysdig Terraformプロバイダーは、セキュリティ設定の管理と自動化を簡素化し、環境全体での一貫性とコンプライアンスを確保します。詳細な使用例、高度な構成、サポートされているすべてのリソースおよびデータソースの一覧については、Sysdig Terraformプロバイダーのドキュメントをご参照ください。