ブログ

Google Cloud Runサーバーレスワークロードの保護

Google Cloudとコンテナの継続的なセキュリティ

本文の内容は、2019年11月14日にSysdigのMateo Burilloが投稿したブログ(https://sysdig.com/blog/securing-google-cloud-run/)を元に日本語に翻訳・再構成した内容となっております。

Google Cloud Runは、ステートレスコンテナを自動的にスケーリングするサーバーレスコンピューティングプラットフォームです。この投稿では、Cloud Runサービスのライフサイクル全体を保護する方法を紹介します。

Sysdigは、Cloud Runプラットフォーム向けの Secure DevOpsワークフローを提供し、セキュリティを組み込み、可用性を最大化し、サーバーレスライフサイクル全体のコンプライアンスを検証する仕組みを提供します。Sysdig Secure Devops Platformは、企業が要求する規模、パフォーマンス、使いやすさを備えた設計されており、オープンです。

Sysdigは、今年初めにGoogle CloudのAnthosのサポートを発表しました。 Anthosは、Cloud Runサーバーレステクノロジーを新しいネイティブコンポーネントとして統合しました。これはSysdigにおいても全てサポートされています。Sysdigエージェント自体はGoogle Cloud Platform Marketplaceで入手できるため、この統合はさらに簡単になります。

Anthosを使用してこの投稿の例ではユースケース例を説明しますが、Cloud Runサーバーレスプラットフォームは、管理されたGoogle Cloud Run環境、Google Kubernetes Engine(GKE)、GKEオンプレミス、マルチクラウドにもデプロイできます Cloud RunはKnativeに基づいており、アプリケーションがポータブルであり、オープンスタンダードに準拠していることを保証しています。

プラットフォームの簡単な紹介から始めましょう。

Google Cloud Anthos

Anthosは、ハイブリッドクラウド環境向けに設計されたアプリケーション管理プラットフォームです。

Anthosは、マネージドクラウドとオンプレミスデプロイメント間のギャップを埋め、物理サーバー、オンプレVM、Compute Engine VMなどで統一されたコントロールプレーンと一貫した開発および運用エクスペリエンスを提供します。

Kubernetes、Istio、Knativeなどのユビキタスクラウドネイティブテクノロジーの上に構築されたAnthosは、必要に応じてコンテナワークロードをシームレスに実行し、アプリケーションの移行、モダナイゼイション、セキュリティコントロールを簡素化します。

Google Cloud Run

Cloud Runは、サーバーレスコンピューティングのシンプルさと抽象化を、コンテナ化されたワークロードの柔軟性と単一のソリューションに結合するという考えに基づいて構築されています。

Cloud Runを使用すると、コンテナを通常の方法で定義します(つまり、Dockerfileを記述します)が、インフラストラクチャとライフサイクル管理は抽象化され、ネイティブサーバーレスエクスペリエンスが提供されます。また、Cloud Runは、トラフィックに応じてゼロから増減するサービススケールをほぼ瞬時に自動的に管理します。

厳密なサーバーレスフレームワークを使用すると、サポートされている言語、ライブラリ、およびコードフレームワークの定義済みセットから選択する必要がある特定の制約に従う必要があります。標準のコンテナ化されたソリューションを使用すると、この点でより柔軟になりますが、サーバーのプロビジョニング、構成、および管理という追加の運用投資が伴います。 Cloud Runは両方の長所を提供し、サービスコードの開発方法を制限することなく、サーバーレスプラットフォームのシンプルさを提供します。

3つの簡単な手順で、互換性のあるプラットフォーム上でGoogle Cloud Runアプリケーションを構築およびデプロイできます。

  • Define:Dockerfileを記述しているコンテナを作成します。ベースオペレーティングシステム、フレームワークとライブラリ、リスニングポートなどを選択できます。
  • Publish:gcloudコマンドラインツールを使用すると、公開されたコンテナイメージがCloud Platformプロジェクトに関連付けられたGoogle Container Registryに保存されます。
  • Deploy:サービス名とリージョンとともに、イメージのrun deployサブコマンドを実行します。デプロイが成功すると、コマンドラインにサービスのURLが自動的に表示されます。あなたのサービスは稼働していて準備ができています!

より具体的な例を説明する前に、Cloud Runサービスをデプロイする際に留意すべき技術的な考慮事項がいくつかあります。

  • Cloud Runコンテナはステートレスです。これにより、プラットフォームはそれらをサーバーレス機能として扱うことができます。
  • コンテナは、PORT環境変数で定義されたポートでHTTP要求を受け入れる必要があります。
  • 同じコンテナイメージを実行している場合でも、設定が異なると、異なるリビジョンIDでコンテナインスタンスが作成されます。この一意の識別子は、特にどのワークロードが予期しない方法で動作しているか、いつ起動されたか、YAMLに完全な定義が含まれているかを判断するのに非常に役立ちます。以下の例でその機能を活用して、セキュリティフォレンジックフェーズで実行とインスタンスを関連付けます。

Cloud RunにおけるサーバーレスセキュリティとSysdig

コンテナは本質的には一時的なものであり、Cloud Runコンテナは二重になっています。それらがサーバーレス機能として管理され、オンデマンドで拡大縮小されるためです。2019年のコンテナ利用レポートに基づくと、コンテナの52%が5分以内かそれ以下の生存となっています。

これは、Cloud Runのセキュリティを緩和する必要があるのか、それともセキュリティコントロールが超高速のサービスデプロイメントパイプラインの負担になるという意味ですか? いいえ、このワークフローに合わせて調整されたツールを使用するだけです。

Sysdig Secureは、Cloud Runサーバーレスライフサイクルのすべてのステージにセキュリティとコンプライアンスを組み込みます。

  • Sysdigインスツルメンテーションは、Pod/コンテナーの観点から完全に透過的であるホストカーネルと直接通信します。
  • ホストごとにこの単一のエージェントを用いて可視性、監視、およびセキュリティを実現します。監視イベントとセキュリティイベントを相互に関連付け、全体像を示す単一のプラットフォームとなります。
  • Sysdigは、コンテナ固有のメタデータとKubernetesメタデータをネイティブに理解するため、NameSpace、コンテナID、サービスIDなどによってデータを即座に整理し、セグメント化できます。

Cloud RunとSysdigが一緒に実行される事を理解するために、3つの一般的なセキュリティユースケースを紹介しましょう。

  • Cloud Runコンテナにおける高度なイメージスキャン
  • サーバーレスCloud Runワークロードのランタイムセキュリティ
  • サーバーレスコンテキストでのフォレンジックとインシデント対応

Cloud Runコンテナの高度なイメージスキャン

前述したように、Cloud Runに使用されるコンテナイメージを定義および構築した後にプロジェクトのGoogle Cloud Registryで公開する必要があります。

この手順は非常に簡単です。次の手順に従ってDockerアクセス認証情報を設定し、Google CloudプロジェクトIDに基づいてイメージにタグを付けます。

docker push gcr.io/<your_project_id>/hello:latest
s01.png

次に、Sysdig Secureバックエンドを設定して、Cloud Runプロジェクトに使用しているのと同じリポジトリにアクセスする必要があります。

Sysdig Secureインターフェースから、イメージスキャンセクション(左側)にアクセスし、レジストリ資格情報をクリックします。

s02.png

このインターフェイスから、新しいコンテナレジストリを追加できます。先に進み、Cloud Runに使用するGCRリポジトリを構成しましょう。

s03.png

フォームでは、リポジトリパスを設定し、レジストリタイプとしてGoogle Container Registryを選択し、アカウントに関連付けられたJSON認証キーを取得する必要があります。オプションで、そのリポジトリからイメージをダウンロードして、接続性と資格情報をテストできます。

フォームを保存すると、Sysdig SecureによってCloud Runイメージをプルおよび分析できるようになります。 その特定のイメージのレポートを見ると:

s04.png

以下を参照できます。

  • このイメージの基本ディストリビューション/バージョン
  • OSレベルで見つかった脆弱性
  • 非OSレベルで発見された脆弱性(Python、npm、ruby gemなど)
  • このイメージのポリシー評価基準と最終決定(パス|フェイル)
  • このイメージなどのコンテンツとファイルのインベントリ

イメージ内のCVEを検出することは最初のステップに過ぎません。独自のカスタマイズされたポリシーを構成したり、クエリを実行して、ランタイム環境または静的環境でCVEまたはパッケージに関するレポートを作成できます。

サーバーレスCloud Runワークロードにおけるランタイムセキュリティ

イメージスキャンと脆弱性レポートはクラウドネイティブセキュリティの重要な部分ですが、セキュリティチームはランタイム時に攻撃を検出して対応する必要があります。

  • 新しいゼロデイ脆弱性が公開されています
  • マルウェアは検出されずにスキャンフェーズを通過することができた
  • コンテナまたはホストは、特権エスカレーションを利用するためにインタラクティブにアクセスされます
  • アプリケーションバイナリは安全ですが、デプロイメント構成は安全ではありません。等々、

これらの脅威に適切に対応するために、コンテナ固有のランタイムセキュリティが必要なセキュリティシナリオが多数あります。

Google Cloud Runサービスはシンプルです。実行する必要があるバイナリ、開く必要があるポート、アクセスする必要があるファイルなどをすぐに把握できます。Sysdigランタイム用の振る舞いベースで定義できる言語を使用すると、Cloud Runサービスに最小特権ポリシーを採用でき、現在許可されているすべてに自動的にフラグが立てられます。

Sysdigは、Cloud Runコンテナでサポートされるサーバーレスアプリケーションを含む、すべてのコンテナとホストのランタイム時の動作をライブで分析します。この情報はすべてランタイムルールエンジンに送られ、ルール違反が検出されるとアラートがトリガーされます。

これを簡単な例で説明しましょう。 Google Cloud Run for Anthosを使用して「hello」サービスを開始しました。

s05.png

上のイメージでわかるように、同じサービスには異なるリビジョンIDがあります。構成を変更してサービスを再起動するたびに、新しい一意のIDが割り当てられます。

Sysdigを使用すると、すぐにCloud Runサービスをサポートするコンテナーを完全に可視化できます。Sysdigプラットフォームのモニターまたはセキュアインターフェイスのいずれかにアクセスすると、Kubernetesメタデータ(NameSpace、Deployment、annotations, label)を使用して階層的に編成された既存のCloud Runコンテナーを表示できます。

s06.png

Sysdigエージェントは、実行中のすべてのコンテナーのKubernetesラベルとタグをキャプチャします。 Cloud Runコンテキストの場合、これらのタグは、すぐに関連する2つのユースケースに使用できます。

  • クラスター内の他の「通常の」コンテナとは別に、Cloud Run管理コンテナを分類および通知する
  • これにより、スコーピング先のコンテナの「タイプ」に応じて、異なる視覚化、セキュリティ警告、メトリクスしきい値などを定義できます。
  • クラスターで実行されていた現在または過去のコンテナーのリビジョンIDを取得し、この情報をセキュリティアラートまたはサービスパフォーマンスイベントと関連付けます。

単純な「hello」コンテナがプロセスを実行しているだけであることがわかります。

root         1  0.0  0.1 110760 11976 ?        Ssl  11:18   0:10 /hello

そのコンテナ内で他のバイナリが実行された場合に警告するホワイトリストルールを作成しましょう。

Sysdig Secureのランタイムルールライブラリにアクセスして、新しいランタイムルールを作成できます。

s07.png

syscallストリームがホワイトリストにないバイナリを検出するたびにトリガーする新しいルールを作成します。

s08.png

次に、このルールをスコープして実行可能にし、ランタイムポリシーを作成します。

s09.png

タグ リビジョンに文字列helloが含まれるコンテナにこのポリシーを適用します。同じサーバーレスサービスのすべての異なるリビジョンIDで機能しますが、クラスターに存在する他の通常のコンテナには影響しません。

このポリシーをトリガーしましょう。たとえば、コンテナ内でlsを実行すると、すぐに次のようなイベントを受け取ります。

s10.png

イベントの詳細を確認すると、次を表示できます。

  • 完全なKubernetesスコープ(host, namespace, pod name, revision ID)
  • コマンド監査情報(PID、PPID、シェルID、UID、cwd)
  • コンテナID、Kubernetesの完全なコンテナ名、イメージSHA256ダイジェスト

簡単にするために、この例では基本的なランタイムルールを示しました。 Falcoランタイム言語を使用すると、syscall、コンテナラベル、kubernetes属性、リスト、サブ条件付きマクロなど、シナリオで実施する必要がある高度なトリガー条件を記述できます。

s11.png

サーバーレスコンテキストでのフォレンジックとインシデント対応

Google Cloud Runは、サーバーレスで自動スケーリングされたオンデマンド環境です。 これは、セキュリティインシデントに注意が向けられると、影響を受けるワークロードがおそらく長期間なくなることを意味します。そのようなシナリオでインシデント対応とフォレンジックをどのように実行しますか? CSIシリーズに似ていますが、ボディはありません。

繰り返しますが、それは仕事に適切なツールを使用するだけの問題です。 ポリシーがトリガーされたときに実行できる自動化されたアクションがいくつかある前に表示したポリシー定義に戻ります。

s12.png
  • 常にイベントストリームでイベントを通知し、コンテナを直接停止するか、さらに調査するために一時停止します。
  • イベント情報(電子メール、webhook、slack、pagerdutyなど)をプッシュするいくつかの通知チャネルがあります。
  • 完全なアクティビティキャプチャを作成することもできます。 セキュリティイベントが発生した後だけでなく、キャプチャする前にキャプチャできることが可能です。

これはフォレンジックにとって重要な詳細です。セキュリティトリガーの前に一連のイベントを再構築できるようにする必要があります。 多くの攻撃の前には、認識と情報発見の手順があります。

この例では、予期しないアウトバウンド接続先を使用します。 Cloud RunサービスはいくつかのGoogle Cloud APIにアクセスする必要があることを知っており、それらをホワイトリストに登録できますが、疑わしい他の宛先にアクセスしようとすると(ビットコインマイニングがハイジャック?クラスター内の通常のPodに接続しようとしますか? K8S APIにコンタクトしようとしていますか?)。今回は、ポリシーイベントに関連付けられたSysdigキャプチャを構成します。

ここで、ポリシーをトリガーします。より現実的なものにするために、セキュリティポリシーをトリガーした後、Google Cloudコンソールに新しいサービスリビジョンをデプロイします。

s13.png

古いサービスリビジョンには到達するトラフィックがないため、自動的に0に縮小されました。

ただし、古いリビジョンに対してアラートがトリガーされました。

s14.png

Sysdig Secureに存在する情報とGoogle Cloud Runコンソールを関連付けて、以下を発見できます。

  • アラートをトリガーした特定のサービスリビジョンID、いつトリガーしたか、特に違反したランタイムルール。
  • そのリビジョンを誰がいつ起動し、いつどの構成が使用されていたか。

そして、これはフォレンジック調査の最初のステップに過ぎません。このポリシーイベントに添付すると、セキュリティインシデント中に実行されたすべてのシステムコールでキャプチャが見つかります。

s15.png

アラートがトリガーされた正確な瞬間だけでなく、それ以前にも一致するインタラクティブなアクティビティがあるようです。 実行されたインタラクティブコマンドを詳しく見てみましょう。

s16.png

非常に不審なアクティビティで、最後のコマンド(curl)は実際にポリシーをトリガーしたものでした。このインターフェイスからドリルダウンして、攻撃中に実行されたアクションのきめ細かい詳細を見つけることができます。接続が開かれ、新しいプロセスが生成され、ポートをリッスンし、ファイルが変更され、それらのファイル内で変更されたコンテンツさえも把握可能です:

s17.png

まとめ

Google Cloud Runプラットフォームは、サーバーレスプラットフォームとコンテナの間のスイートスポットにあります。Sysdigでは、プラットフォームのモニタリングとセキュリティの両方の柱について、Google Cloud Anthosのサポートを拡大し、AnthosのCloud Runのサポートを提供しています。

Sysdigプラットフォームは、Google Cloud Runワークフローに多くの利点をもたらします。

  • 透過的ななインスツルメンテーション。GoogleCloudサービスを軽量でシンプルなものにし、サーバーレスの原則を守ります。
  • プライベートGoogleコンテナレジストリのネイティブサポート。イメージスキャン、カスタムイメージチェック、インターフェースからの脆弱性レポートを可能にします。
  • 一時的でステートレスなワークロードに対処するために特別に調整された、クラウド固有のきめ細かいフォレンジック。

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

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top