本文の内容は、2020年3月12日にSysdigのFede Barcelonaが投稿したブログ(https://sysdig.com/blog/sysdig-terraform-provider/)を元に日本語に翻訳・再構成した内容となっております。
この記事では、Sysdig Terraformプロバイダーを活用してSecure GitOpsの原則に従い、インフラストラクチャ内のコードとしてセキュリティを使用してアラート、ルール、およびポリシーを定義する方法を示します。
設定を台無しにすると、ひどい結果になる可能性があります。 ネスターはセキュリティエンジニアであり、会社のすべてのイメージスキャンポリシーを設定しています。それらのポリシーの1つで、彼は誤って誤ったオプションを選択し、脆弱なイメージが実稼働クラスターにデプロイされ始めました。このエラーは、ある日セキュリティイベントがネスターのダッシュボードにあふれ始めるまで気付かれず、誰かがこれらの脆弱性を悪用しています！ ネスターは今、どのようにして問題の原因を見つけることができますか？ミスがいつ、誰によって行われたのか、彼はどのようにして知ることができますか？ 彼は将来この問題を回避するために何が出来るのでしょうか？
ネスターがGitOpsの原則に従っていた場合、その構成はすべてコードとして行われ、gitリポジトリ（真実の唯一の情報源）にコミットされ、チーム全体でレビューされます。彼のエラーがレビューに合格した場合、簡単な調査により、混乱した構成を誰が、いつ変更したかが明らかになり、問題の修正は構成の変更を元に戻すのと同じくらい簡単です。
Terraformは、インフラストラクチャをコードとして定義する優れたツールであり、GitOpsの実装によく使用されます。SysdigのTerraformプロバイダーはこれを拡張し、Sysdig MonitorからのアラートやSysdig Secureからのルールとポリシーなど、Sysdig要素の一部をTerraformリソースとして定義できるようにします。
Sysdig Terraformプロバイダーを使用すると、GitOpsワークフローにセキュアを含めることができます。この記事では、成功するためのガイドを提供します。
Sysdig Terraformプロバイダーのインストール
Sysdig Terraform Providerをインストールするには、リポジトリをクローンして自分でビルドするか、プリコンパイル済みバージョンをダウンロードします。
ビルドする場合は、Goプログラミング言語1.12以上がシステムにインストールされている必要があります。
次に、terraform-provider-sysdig実行可能ファイルを、Windowsでは％APPDATA％\terraform.d\plugins、他のシステムでは〜/.terraform.d/pluginsにあるユーザープラグインディレクトリに手動で移動します。
Sysdig Terraformプロバイダーの使用
まず最初に、Sysdigプロバイダーを使用することと、以下のすべての構成がこのモジュールによって処理されることをTerraformに伝える必要があります。そうするには、provider.tfというファイルを作成します。
provider "sysdig" { }
これでTerraformはプロバイダーを使用して、ファイル内のすべてのリソース定義を処理できます。TerraformがSysdigバックエンドに対して必要なすべてのアクションを実行できるように、Sysdig MonitorとSysdig Secure APIトークンが必要です。そのため、provider.tfファイルに次の情報を書き込みます。
provider "sysdig" {
sysdig_monitor_api_token = "<your monitor token>"
sysdig_secure_api_token = "<your secure token>"
}
プレーンテキストファイルにシークレットを配置したくない場合は、SYSDIG_MONITOR_API_TOKENおよびSYSDIG_SECURE_API_TOKEN環境変数を使用してトークンを提供できます。これらの2つの方法のいずれかでこれらのトークンを提供しない場合、Terraformはインタラクティブに実行されたときにそれらを入力するように求めます。
この例では、コンテナで生成されたSSH接続とシェルを検出できるルールのペアを作成します。
rules.tfファイルでいくつかのルールを定義することから始めます。1つのルールは、ポート22へのインバウンドおよびアウトバウンド接続を検出し、もう1つのルールは、生成されるシェルプロセスを検出します。
resource "sysdig_secure_rule_network" "disallowed_ssh_connection" {
name = "Disallowed SSH Connection detected" // ID
description = "Detect any new ssh connection to a host"
tags = ["network"]
block_inbound = true
block_outbound = true
tcp {
matching = true
ports = [22]
}
}
resource "sysdig_secure_rule_process" "terminal_shell" {
name = "Terminal shell detected" // ID
description = "A shell was used as the entrypoint/exec point"
tags = ["shell"]
processes = ["ash", "bash", "csh", "ksh", "sh", "tcsh", "zsh", "dash"]
}
次に、policy.tfというファイルにポリシーを作成して、これらのルールの適用方法を定義します。このポリシーは、影響を受けるコンテナを停止し、さらにトラブルシューティングを行うためにキャプチャをトリガーします。
resource "sysdig_secure_policy" "terminal_shell_or_ssh_in_container" {
name = "Terminal shell or SSH detected in container"
description = "Detects a terminal shell or a ssh spawned in a container"
enabled = true
severity = 0 // HIGH
scope = "container.id != \"\""
rule_names = [sysdig_secure_rule_network.disallowed_ssh_connection.name,
sysdig_secure_rule_process.terminal_shell.name]
actions {
container = "stop"
capture {
seconds_before_event = 5
seconds_after_event = 10
}
}
}
指定されたスコープでは、ポリシーはコンテナ内で実行されるプロセスにのみ適用されます。
scope = "container.id != \"\""
これらのリソースをバックエンドに適用するために、テラフォームの適用を行ってみましょう。
Terraformは、rules.tfとpolicy.tfで定義したものと一致する3つのリソースを作成することを示しています。
planをapplyした後、Terraformは3つのリソースが正常に作成されたことを報告します。ポリシーは以前に作成されたルールを使用するため、最後に作成されるルールです。
リソースが作成されました。SysdigSecureでどのように見えるか見てみましょう。
これで、セキュリティをコードとして使用して、コンテナインフラストラクチャのターミナルシェルまたはSSH接続から保護されます。ただし、このポリシーがトリガーされた場合、通知チャネルを定義しない限り気付かないでしょう。notification.tfというファイルに、メール用とスラック用の2つの通知チャネルを作成してみましょう。
resource "sysdig_secure_notification_channel" "devops-email" {
name = "DevOps e-mail"
enabled = true
type = "EMAIL"
recipients = "devops@example.com"
notify_when_ok = false
notify_when_resolved = false
}
resource "sysdig_secure_notification_channel" "devops-slack" {
name = "DevOps Slack"
enabled = true
type = "SLACK"
url = "https://hooks.slack.com/services/32klj54h2/34hjkhhsd/wjkkrjwlqpfdirej4jrlwkjx"
channel = "#devops"
notify_when_ok = false
notify_when_resolved = false
}
それらをポリシーにバインドし、policy.tfファイルを変更して、notification_channelsプロパティに注意してください。
resource "sysdig_secure_policy" "terminal_shell_or_ssh_in_container" {
name = "Terminal shell or SSH detected in container"
description = "Detects a terminal shell or a ssh spawned in a container"
enabled = true
severity = 0 // HIGH
scope = "container.id != \"\""
rule_names = [sysdig_secure_rule_network.disallowed_ssh_connection.name,
sysdig_secure_rule_process.terminal_shell.name]
actions {
container = "stop"
capture {
seconds_before_event = 5
seconds_after_event = 10
}
}
notification_channels = [sysdig_secure_notification_channel.devops-email.id,
sysdig_secure_notification_channel.devops-slack.id]
}
テラフォームのapplyを行うと、2つの新しいリソースが作成され、既存のポリシーが変更されることがわかります。
「yes」を入力すると、Terraformは通知チャネルを作成してポリシーにバインドし、Monitor and Secureの状態がコードで定義された状態と一致するようにします。
Sysdig UIに表示されるこれらの新しいリソースを見ることができます。
Sysdig Terraformプロバイダーで作成されたリソースのクリーンアップ
作成されたすべてを破壊したいですか？もちろん、Terraformはterraform destroyでシームレスに処理します：
「yes」と入力すると、すべてが破棄されます。
Terraformは、作成したリソースのみを追跡し、インフラストラクチャで手動で作成された他のリソースを認識しないことに気をつけてください。
まとめ
ご覧のとおり、Terraformを使用したリソースの作成、変更、削除は非常に簡単で、変更を追跡して元に戻すことができます。これが、GitOpsの世界におけるコードとしてのセキュリティの真の力です。
オープンソースであるSysdig Terraformプロバイダーを今すぐ試してみてください。どうぞ気軽にコントリビュートしてください。 また、Sysdigのエコシステム統合の全体のリストをご覧ください。