コンテナ・Kubernetes環境向けセキュリティ・モニタリング プラットフォーム

本文の内容は、2018年5月2日にSysdigのJorge Salamero Sanzが投稿したブログ(https://sysdig.com/blog/kubernetes-security-for-google-cloud-security-command-center/)を元に日本語に翻訳・再構成した内容となっております。

効果的なKubernetesにおけるセキュリティとは、セキュリティ対応チームが稼働中のコンテナにおけるセキュリティ上の脅威を迅速に検出するのみでなく、対応から検出 - 修復 - フォレンジックをいかに効率的に行えるかが肝要です。 Google Cloud Security Command Centerを通じて利用できるSysdigコンテナセキュリティ機能を利用すると、Google Kubernetes Engine（GKE）クラスタとGoogle Cloud Platform（GCP）のセキュリティアラートを1つのビューで表示し、適切なアクションを行えます。

Sysdig Secureは、コンテナの可視性とネイティブのGoogle Kubernetes Engineを統合することで、マイクロサービスに即したセキュリティポリシーを通じて、脅威をブロックし、コンプライアンスの強化、インフラストラクチャ全体の活動を監査する機能を提供します。 セキュリティイベントは、Google CSCCに送信される前に、すべてのコンテナおよびKubernetesメタデータの情報が追加されます。このプロセスは、関連するシグナルをGoogle Cloudのお客様に注意を促し、Sysdigイベントを他のセキュリティ情報ソースと関連付けて、単一の観点とそれに応じた対応をあらゆるレベルで可能にします。

Security Command CenterとSysdig Secureをインテグレーションする

このインテグレーションは、Sysdig Secureからイベントを受け取り、関連するすべてのメタデータを追加し、それらをGoogle CSCCの調査結果に転送します。 Sysdig Secureで自動的に作成および設定されたWebhook通知を介してイベントを非同期的に受信できますが、Sysdig Secure APIをポーリングして最後の1分以内に集約されたイベントを送信するように設定することもできます。

２種類のデプロイメントオプション：

• Google App Engineアプリケーションとして実行する方法が最も簡単なデプロイメント方法です。インフラストラクチャの要件や追加の設定は不要で、自動的にWebHookにHTTPSエンドポイントを提供します。
• Dockerコンテナイメージとしてパッケージ化されたイメージをKubernetes podとして実行することもできます。この場合は、HTTPS用のパブリック静的IPアドレスとTLS証明書を使用してIngressコントローラの設定が必要です。

では、AppEngineのデプロイメントステップを見ていきましょう：

1.- インテグレーションリポジトリをクローンします:

$ git clone https://github.com/draios/sysdig-gcscc-connector/

2.-設定を環境変数としてExposeします（エクスポートするにはこれを.envrcファイルにダンプするか、Google App Engineを使用する場合はapp.yamlファイルで設定します）。次に各設定オプションを見ていきましょう。

Sysdigユーザ API tokenは、Sysdig Secure -> Settings で確認する事ができます。

export SYSDIG_TOKEN="c6f6af86-93a5-418b-9d76-1229fcd92378"

gcloud organizations listからOrganization ID、CSCC製品が有効になっているプロジェクトIDを取得できます。次に、検出結果を作成するためのサービスアカウント名とアカウント認証情報を設定する必要もあります。 それらを生成するスクリプトを./scripts/generate_gcloud_keysの下にて提供ししています。

export ORG_ID="534901558763"
export PROJECT_ID="cscc544401558763"
export SERVICE_ACCOUNT="cscc-sa"

export SECURITY_SERVICE_ACCOUNT_INFO="$(cat $(pwd)/$SERVICE_ACCOUNT.json)"

次に、トリガーされたSysdig Secureイベントと相関するComputeインスタンスを照会するための設定が必要になります。 監視対象インスタンスを実行しているProject ID、instances IDを照会するためのサービスアカウント、およびインスタンスが見つかるコンピューティングゾーンを設定します。 また、ここで必要なアカウントの認証情報を設定する必要があります。作成するためのスクリプトは./scripts/generate_compute_keysの下にあります。

export COMPUTE_PROJECT_ID="arboreal-logic-197806"
export COMPUTE_SERVICE_ACCOUNT="compute-sa"
export COMPUTE_ZONE="europe-west3-a"

export COMPUTE_SERVICE_ACCOUNT_INFO="$(cat $(pwd)/$COMPUTE_SERVICE_ACCOUNT.json)"

最後に、WebHookを受信するためのパブリックエンドポイント、AppEngine URL、またはコネクタにルーティングされる設定済みKubernetes ingressの定義が必要です。 WebHookには認証ヘッダが必要ですが、これは統合によってSysdig Secure側で自動的に設定されます。ここではトークンを設定します。

export WEBHOOK_URL="https://arboreal-logic-198306.appspot.com/events"

export WEBHOOK_AUTHENTICATION_TOKEN="7a79416ed4d3776b74fcc070275ece208eeef29f"

設定が完了したら次のステップに進みましょう。

3.- AppEngineプロジェクトの作成とappのデプロイ：

Google Cloud環境ツールを設定していない場合は、まず最初に実行してください：

gcloud init

その次にappを作成します：

gcloud app create

最後にインテグレーションをデプロイします：

gcloud app deploy

これで完了です！ 新しく作成したGoogleクラウドセキュリティコマンドセンターの通知チャネルを使用するように設定したすべてのイベントがGoogle側に表示されます。

Sysdig Secureを使用してGoogle Kubernetes Engineでコンプライアンスを強化し、内部の脅威を検出する

Sysdig Secureを活用すると、コンテナにおけるセキュリティとフォレンジックを考慮したアプローチを取る事ができます。 ネイティブのGKE統合でコンテナの可視性を活用することで、脅威をブロックし、Kubernetesコンプライアンスを強化し、マイクロサービス全体のアクティビティを監査できます。 それでは、Kubernetes固有の、さまざまなセキュリティイベントを確認してみましょう。

許可されていないコンテナイメージをkube-system上で起動してみる

Sysdig Secureは、ホストまたはコンテナに関連付けられているメタデータによってポリシーの範囲を限定する独自の機能を実現しています。 これにより、組織は、namespace、deployment、または、podレベルでKubernetesのポリシーを設定できます。 これから説明する例は、kube-system namespace内で起動された、予期しないシステム以外のコンテナを削除します。

予期しないコンテナーが起動されたことを検出するためのポリシーは、スコープ kubernetes.namespace.name = kube-systemを使用します。 このスコープは、コンテナまたはイメージが物理的に実行されている場所に関係なく、ポリシーはそのnamespaceの一部であるすべてのコンテナに適用されます。 また、このポリシーを設定して、これらの予期しないコンテナの起動を阻止しています。

２つ目のポリシーは、kube-system namespace内で許可されているさまざまなイメージをホワイトリスト/ブラックリストに追加しています。 ここでは簡単に異なるkubernetesシステムコンテナのリストを追加することができます。GKE用の設定は以下となります：

gcr.io/google-containers/event-exporter, gcr.io/google-containers/prometheus-to-sd, gcr.io/google-containers/fluentd-gcp, gcr.io/google_containers/heapster-amd64, gcr.io/google_containers/addon-resizer, gcr.io/google_containers/k8s-dns-kube-dns-amd64, gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64, gcr.io/google_containers/k8s-dns-sidecar-amd64,  gcr.io/google_containers/cluster-proportional-autoscaler-amd64, gcr.io/google_containers/busybox, gcr.io/google_containers/kube-proxy, gcr.io/google_containers/kubernetes-dashboard-amd64, gcr.io/google_containers/defaultbackend

アドバイスポイント：通常のシステムコンテナがわからない場合は、Sysdig Monitor内のexploreテーブルをチェックして、どのコンテナがnamespace内で実行されているかを確認する事も可能です。

Kubernetes上で特権コンテナが起動された事を検知

特権コンテナは、ホスト全体にアクセスできるので、環境内でコンテナが起動されたときに通知を受けるようにして、コンテナの起動を阻止する事も可能です。

監視目的で必要となるSysdigエージェントやその他のインフラストラクチャレベルのコンテナのように、特権コンテナを起動する理由がいくつかあるかもしれませんが、これは通常のアプリケーションではほとんどありません。このポリシーでは、kubernetes.daemonSet.name！= sysdig-agentというスコープを使用しており、特権コンテナがこのスコープで起動された場合はユーザーに通知します。

本番環境でhotfixを検出する

時に、チームメンバーは、本番環境に対して fotfix を適用したい誘惑にかられる場合もあります。それらをトラッキングすることは本当に困難であり、予想外の結果が生じる可能性もあります。

Sysdig Secureは、docker execまたはkubectl execを介してクラスタ内で実行されたコマンドを監査し、バイナリイメージのようにコンテナイメージ上で不変でなければならないパスの実際の変更を警告することもできます。

コンテナファイルシステムの変更をキャプチャするルールは、とても簡単です：

また、永続ストレージがある特定のパスに例外を適用する必要がある場合は、Policy EditorのUIから簡単に追加できます。

Security Command Centerでセキュリティイベント対応を行う

Sysdigは、Googleとの提携をさらに進めることができてとてもエキサイトしておりますが、実は、それだけではありません。 Cota HealthcareのAshley Pennyインフラストラクチャー担当副社長は以下のように語っています：

Cota Healthcareのインフラストラクチャ担当バイスプレジデントを務めるAshley Pennyは、次のように述べています。「堅牢で費用対効果の高いプラットフォームのために、Google Cloud上で開発することを選択しました。 Sysdigは、1つのエージェントでKubernetesサービスを効果的に保護および監視できるため、完璧な補完関係として機能しています。 GoogleとSysdigが、この製品統合を通じてパートナーシップを深めていることをとても嬉しく思います。」

それでは、Security Command Centerを使用して、プロジェクト、クラスター、インスタンス、およびコンテナーイメージ間でイベントを調査および相関させる方法を見てみましょう。

1.-アカウント内のさまざまなプロジェクト、assets、sources:

Assetインベントリには、アカウントに含まれているさまざまなプロジェクトとそのプロジェクトにロールアップされているさまざまなAssetの概要が表示されます。 プロジェクトを選択することで、さらに掘り下げてさまざまなセキュリティの結果を確認できます。

2.- 環境における様々なセキュリティ調査結果をナビゲート

Findings sectionでは、一定期間内にインフラストラクチャ全体で発生したさまざまなセキュリティイベントを確認することができます。さらに各イベントをクリックすると詳細情報が表示されます。 Sysdigイベントは、Google Cloud Platformの2種類のリソースと関連付けられます。手動で起動されるインスタンスまたはGKEインスタンスプールの一部であるコンピュートインスタンス、およびGoogle Container Registryからのコンテナイメージです。

3. - FindingテーブルにおけるKubernetes context：

Sysdig Secureは、関連するすべてのインスタンス、コンテナーイメージ、Kubernetesスコープ、およびクラウドメタデータを使用して、コンテナーからのすべてのイベントの情報を補強します。 イベントをKubernetesにとってより意味のあるものにするために、セキュリティチームは、SysdigのさまざまなカスタムKubernetesプロパティを、検出結果テーブルに追加できます（Cluster ID、namespace、deployment、podなど）。

4.- 詳細情報を把握する：

検索結果をクリックすると、Sysdigから渡されたプロパティと同様にGCPからより多くの属性が表示されます。 このページはSysdig Secureへの情報参照リンクとしても役立ちます。

5.- SysdigSecureによって追加された詳細情報を見ることができます。例えば、コンテナフォレンジックとしてSysdigキャプチャーのコマンド監査や、post-mortem分析への活用、攻撃者がどのようにコンテナに侵入してきたか、何を実行してどのようなデータを盗まれたか等々、

結論

自社のKubernetesクラスタまたはマネージドGoogle Kubernetes Engineのいずれかで、Google Cloud Platformでインフラストラクチャを実行している場合は、Kubernetesとアプリケーションのセキュリティに注意する必要があります。 Sysdig SecureとGoogle Security Command Centerが連携することで、以下のことが可能になります。

1. Runtime分析による継続的なセキュリティ：予期しない送信接続、異常なファイルアクセス、不正なプロセス動作など、特定の不審なアクティビティは、デプロイメント後に問題を引き起こすことがよくあります。 システムコールレベルのインスツルメンテーションにより、ユーザーに対して完全に透過的で、いかなる種類のコンテナ変更もなしで、Sysdigはより深いコンテナー可視性を提供でき、デプロイメント後の疑わしいアクティビティの検出、警告、およびブロックに使用できます。
2. 手動でイベント情報の関連付けを行うのに費やす時間が短縮されます：GoogleCloud SCCを使用すると、ユーザーは自分のクラウド資産に対する統合された可視性を得て、クラウド資産に対する独自の脅威の見方をユーザーに提供できます。 GCSCCはSysdig Secureを含む多くのセキュリティツールと統合されており、インシデントフィードをよりよく理解するために必要なすべてのKubernetesコンテキストをもたらすため、他のGoogleが管理するクラウドサービスのセキュリティイベントと並行で確認できます。
3. Sysdigは、コマンド、プロセス、ネットワーク、およびファイルシステムの操作を含むすべてのアクティビティを記録し、攻撃された時点からpost-mortem分析とフォレンジックを可能にします。Kubernetesがスケジュールを変更したり削除したりしたために、コンテナがもう存在しなくても、アクティビティの記録、リーサーチに必要なすべてのものが見つかります。

Google CloudおよびSysdigの既存のすべてのお客様に、この新しいインテグレーションを試すことをお勧めします。

Sysdigに関するお問い合わせはこちらから