IBM Cloud Monitoring: Sysdig Secureを使うとこんなに便利 - 第1回: Activity Audit
IBM Cloud Monitoring: Sysdig Secureを使うとこんなに便利 - 第2回: Runtime Policyのアクション
1. Runtime Policyのアクション概要
前回も説明した通り、Sysdig Secureには「実行時の挙動を検知する際のルールの組み合わせとその際のアクション」を定義しているRuntime Policyが存在する。
前回は、Suspicious Container Activityというポリシーの中に、Terminal shell in containerというルールが存在することについて言及したが、検知した際のアクションも指定できる。
- Policies -> Thread Detection -> Runtime PoliciesからSuspicious Container Activityを選択し、編集ボタンを押下する。
- 検知時のアクション項目として、以下が存在する。単なるイベントをコンソールで確認するだけであれば、
Nothing(notify only)だが、他に以下の項目が選択できるので、その挙動を確認してみる。- Containers
- Nothing(notify only)
- Kill
- Stop
- Pause
- Capture
- Notify
- Containers
2. Runtime Policyのアクション: Containers
[root@new-syasuda-tok1-vpc1 ~]# oc get pods
NAME READY STATUS RESTARTS AGE
samplephp-7cdd647b76-bv7wx 1/1 Running 0 81s
samplephp-7cdd647b76-jgtsg 1/1 Running 0 76s
[root@new-syasuda-tok1-vpc1 ~]# oc rsh samplephp-7cdd647b76-bv7wx
sh-4.4$ command terminated with exit code 137
[root@new-syasuda-tok1-vpc1 ~]# oc get pods
NAME READY STATUS RESTARTS AGE
samplephp-7cdd647b76-bv7wx 1/1 Running 1 (3s ago) 2m14s
samplephp-7cdd647b76-jgtsg 1/1 Running 0 2m9s
[root@new-syasuda-tok1-vpc1 ~]# oc get pods
NAME READY STATUS RESTARTS AGE
samplephp-7cdd647b76-bv7wx 1/1 Running 1 (56s ago) 3m7s
samplephp-7cdd647b76-jgtsg 1/1 Running 0 3m2s
[root@new-syasuda-tok1-vpc1 ~]# oc rsh samplephp-7cdd647b76-bv7wx
sh-4.4$ exit
[root@new-syasuda-tok1-vpc1 ~]# oc get pods
NAME READY STATUS RESTARTS AGE
samplephp-7cdd647b76-bv7wx 0/1 CrashLoopBackOff 1 (9s ago) 3m27s
samplephp-7cdd647b76-jgtsg 1/1 Running 0 3m22s
[root@new-syasuda-tok1-vpc1 ~]# oc get pods
NAME READY STATUS RESTARTS AGE
samplephp-7cdd647b76-bv7wx 1/1 Running 2 (92s ago) 4m50s
samplephp-7cdd647b76-jgtsg 1/1 Running 0 4m45s
[root@new-syasuda-tok1-vpc1 ~]# oc rsh samplephp-7cdd647b76-bv7wx
sh-4.4$
↓
↓しばらく待った後、以下に遷移
↓
[root@new-syasuda-tok1-vpc1 ~]# oc rsh samplephp-7cdd647b76-bv7wx
sh-4.4$ command terminated with exit code 137
（他のコンソールで実施）
[root@new-syasuda-tok1-vpc1 ~]# oc get pods
NAME READY STATUS RESTARTS AGE
samplephp-7cdd647b76-bv7wx 1/1 Running 3 (10s ago) 5m38s
samplephp-7cdd647b76-jgtsg 1/1 Running 0 5m33s
3. Runtime Policyのアクション: Capture
IBM Cloudで導入されるSysdig Agentは、デフォルトでSysdig Capture機能が無効になっている。
[root@new-syasuda-tok1-vpc1 ~]# oc get configmap sysdig-agent -n ibm-observe -o yaml | grep sysdig_capture_enabled
sysdig_capture_enabled: false
Capture機能を利用するためには、configmapを以下のように変更。
[root@new-syasuda-tok1-vpc1 ~]# oc get configmap sysdig-agent -n ibm-observe -o yaml | grep sysdig_capture_enabled
sysdig_capture_enabled: true
configmapの変更はPodには自動的に反映されないのでrolloutを実施。
oc rollout restart daemonset sysdig-agent -n ibm-observe
その上で、以下のようにRuntime Policyを変更して保存する。イベント発生5秒前からイベント発生後15秒を記録する。
この状態で、先ほどのPodにログインしてみると、以下のイベントが発生した。
- Actionsとして
Capture covering xxxxという記述があり、キャプチャーされたことがわかる。
-
Respondを押下すると、View Capture with Inspectが選択できる。
-
View Capture with Inspectを押下した結果。Inspectの画面が現れる。
- Inspectにて、
Spy Usersに移動した結果。コンテナ内部で実行されたコマンドがキャプチャーされている。
- Inspectにて、
Connectionsに移動した結果。コンテナ内部で実行されたネットワーク接続情報がキャプチャーされている。
- Inspectにて、
I/O Streamsを選択した結果。curlで実行されていたHTTPアクセスの情報が参照できる。
参考. ホストにおけるCaptureは実行されない
デフォルトでは、sysdig_capture_enabled: falseになっているが、これをsysdig_capture_enabled: trueに変更してagentを再起動(systemctl restart dragent)しても、イベント検知時にCaptureされることはなかった。このCapture機能は、コンテナ実行時にしか稼働されないのかもしれない。
customerid: c63e9a9a-7b13-4d44-a111-8b9f4373bd2f
collector: ingest.private.jp-tok.monitoring.cloud.ibm.com
collector_port: 6443
ssl: true
sysdig_capture_enabled: false
4. Runtime Policyのアクション: Notify
- Notificationには、SlackやWebhookやPagerDutyやTeamsなど、いろいろな通知方法があるが、今回はメールで通知するものとする。あらかじめ、以下のようにメールでのNotificationを構成をしておく。
- Runtime Policyのアクションとしてこのメール通知を選択。
この状態で、先ほどのPodにログインしてみると、以下のようなメールが通知されている。
