Containers & Kubernetes

コンテナ セキュリティの探索: 信頼に足るものしか実行しない

548e Container security full.png

※この投稿は米国時間 2020 年 2 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

脆弱性からクリプトジャッキングまで、そしてさらに多くのクリプトジャッキングに至るまで、2019 年全体を通じてコンテナを使用するユーザーにとっては油断できないセキュリティ イベントが数多く発生しました。ほとんどのコンテナベースの環境の管理には Kubernetes が使用されているため(ハイブリッド環境も増加中)、Forrester Research による 2020 年の予測において「増加しつつあるハイブリッド クラウド環境でアプリとデータを保護する」ことの必要性を指摘されたことは驚くことではありません。

Google Cloud のコンテナ セキュリティ対策チームでは、Google Kubernetes Engine を使用してクラウドで実行している場合でも、Anthos を使用してハイブリッドで実行している場合でも、お客様のコンテナを十分に保護し、またお客様にもコンテナ セキュリティについての知識を深めていただきたいと考えています。そこで、2020 年を開始するにあたり、Kubernetes 環境の保護方法に関するアドバイスと、GKE の最新の機能とリソースの詳細をご紹介します。

ハードウェアからサービスまで、信頼できるものだけを実行する

2019 年に確認された脆弱性の多くは、コンテナのサプライ チェーンを不正使用したり、過度に信頼されている別のコンポーネントを介して権限を昇格させたりするものでした。つまり、信頼できるものを実行し、コンテナに多層防御の原則を適用することが重要といえます。これを実現するために、シールドされた GKE ノードが現在一般公開されています。また、間もなく Workload Identity の一般公開も行われる予定です。これは、GKE アプリケーションを、多層防御などのセキュリティ原則のベスト プラクティスに従う他の Google Cloud サービスに対して認証させる方法です。

これらの機能を詳しく見てみましょう。

シールドされた GKE ノード

シールドされた GKE ノードは、クラスタで実行されているノードが Google データセンターで検証されたノードであることを確認します。Shielded VM の概念を GKE ノードに拡張することで、シールドされた GKE ノードは GKE ベースライン セキュリティの次の 2 点を強化します。

  • ノード OS の出所のチェック: 暗号で確認可能なチェックにより、ノードの OS が Google データセンターの仮想マシン上で実行されていることを確認する

  • ルートキットとブートキットに対する保護の強化: セキュアブートとメジャード ブート、仮想トラステッド プラットフォーム モジュール(vTPM)、UEFI ファームウェア、整合性モニタリング

新しいクラスタの作成時や既存のクラスタのアップグレード時に、これらのシールドされた GKE ノードの保護機能を有効にできます。詳細については、ドキュメントをご覧ください。

Workload Identity

GKE アプリケーションは、データ ウェアハウスなどの別のサービスを使用してジョブを実行している可能性があります。たとえば、「信頼できるものだけを実行する」という流れで、アプリケーションがデータ ウェアハウスとやりとりする場合に、そのウェアハウスはアプリケーションの認証を要求します。しかしこれまでは、実施するアプローチはセキュリティ原則に則っていませんでした。つまり、権限が緩すぎたり、不正使用された場合に甚大な影響を受けたりする可能性があったのです。

Workload Identity は、有効期間が短い認証情報を Google 管理サービス アカウントで使用し、ワークロード認証を自動化することで、最小権限の原則に従うだけでなく、甚大な影響を受ける可能性を低減します。Workload Identity の詳細については、ベータ版リリースに関するブログ、およびドキュメントをご覧ください。Workload Identity は、間もなく一般公開される予定です。

信頼できないワークロードに対するセキュリティ強化

時には実行中のワークロードを自信を持って保証できないこともあります。たとえば、アプリケーションは組織外部で作成されたコードを使用しているかもしれませんし、Software as a Service(SaaS)アプリケーションが未知のユーザーから入力を取り込んでいるかもしれません。このようにワークロードを信頼できない場合、ワークロードとホストリソース間を分離する 2 番目のレイヤが、多層防御セキュリティ原則に従う一部となっています。これに対応するために、Google では GKE Sandbox を一般公開してリリースしています。   

GKE Sandbox

GKE Sandbox は、オープンソースのコンテナ ランタイムである gVisor を使用して、アプリケーションの変更やコンテナとの対話方法を変更することなく、コンテナを追加の分離レイヤで実行します。gVisor はユーザー空間のカーネルを使用してシステムコールをインターセプトして処理することで、コンテナとホスト間のやり取りを減らし、攻撃にさらされる可能性を低減します。一方で、GKE Sandbox はマネージド サービスとしてこのような内部機能を抽象化するため、複数の保護レイヤを 1 ステップで簡素化できます。GKE Sandbox を使ってみましょう。  

コンテナ セキュリティの知識を高める

コンテナと Kubernetes を使用してアプリケーションをモダナイズする企業が増えつつある中、意思決定者とビジネス リーダーは、ビジネスへの適用方法と安全性を維持する方法を理解する必要があります。  

コンテナ セキュリティの基本概念

コンテナと Kubernetes を初めて使用する読者向けに作成された、コンテナ セキュリティがビジネスにとって重要な理由は、サプライ チェーンやランタイム セキュリティなど、コンテナ セキュリティの基本概念について説明しています。Kubernetes を自分で実行している場合でも、GKE や Anthos などのマネージド サービスを使用している場合でも、このホワイト ペーパーを読むことで、Kubernetes のようなオープンソース ソフトウェアが脆弱性にどのように対応し、組織にとってそれが何を意味するのか、という関係性を把握できるようになります。  

新しい GKE マルチテナンシーのベスト プラクティス ガイド

1 つ以上のクラスタがテナント間で共有されるマルチテナンシーは、大半の場合、コスト削減または生産性向上の手段として実装されています。その一方で、複数のテナント、または対応するコンピューティング リソースやストレージ リソースを持つクラスタを誤って構成すると、これらのコスト削減を無駄にするだけでなく、組織をさまざまな攻撃ベクトルにさらすことになりかねません。Google では、信頼性、セキュリティ、モニタリングに着目してマルチテナント クラスタを設定するための新しいガイド、「GKE エンタープライズ マルチテナンシーのベスト プラクティス」をリリースしました。この新しいガイドを参照し、対応する Terraform モジュールを確認して、マルチテナンシーのセキュリティを強化しましょう。

クラウド ネイティブ セキュリティに対する Google の内部的なアプローチ方法

業界がモノリシック アプリケーションに基づくアーキテクチャから分散型の「クラウド ネイティブ」マイクロサービスに移行しているように、Google でも境界ベースのセキュリティからクラウド ネイティブ セキュリティへの取り組みが進められています。

次にご紹介する新しい 2 つのホワイトペーパーでは、クラウド ネイティブ セキュリティの背後にあるセキュリティ原則を含め、内部で行われていたアプローチの詳細を公開しています。Google のクラウド ネイティブ セキュリティ モデルの詳細については、BeyondProd をご覧ください。また、コードの出所を確認しコード ID を使用する方法の説明については、Binary Authorization for Borg をご覧ください。

2020 年をコンテナ セキュリティの年に

セキュリティへの取り組みは継続的なものです。GKE を使い始めたばかりでも、すでに Anthos を使用してクラウド全体でクラスタを実行している場合でも、Google のコンテナ セキュリティ機能で最新情報を入手し、クラスタのセキュリティの強化ガイドで実装方法を確認してください。

- By Kubernetes および Anthos プロダクト管理ディレクター Aparna Sinham、Google Cloud プロダクト管理ディレクター Sampath Srinivas