コンテナセキュリティの基礎：ワークロード

このシリーズを初めてお読みになる場合は、最初からご覧になることをおすすめします：
コンテナセキュリティの基礎：概要
コンテナセキュリティの基礎：パイプライン
コンテナセキュリティの基礎：オーケストレーション

ワークロードは比較的新しい用語で、アプリケーションを表す際によく使われますが、インフラストラクチャサービスを指す場合もあります。この点は重要です。コンテナクラスターでは、開発者が提供したとは限らないさまざまな「ワークロード」が実行されている可能性があるためです。コンテナ環境では、さまざまな目的で無償のオープンソースサービスを利用するケースが増えています。これはIT運用全般にも当てはまり、過去1年間に無償のオープンソースソフトウェアがダウンロードされた用途別カテゴリーでは、IT運用が第1位でした。

したがって、ここでいうワークロードセキュリティとは、コンテナ環境にダウンロード、開発、またはデプロイしたあらゆるソフトウェアを対象とするセキュリティを意味します。たとえば、Consul、Kubernetes自体、PrometheusやElasticsearch、NGINXやistioなどです。

さらに、Kubernetes環境を支えるためにデプロイしたAPIゲートウェイ、キャッシュ、Ingressコントローラーも、そのリストに加えてください。ここで重要になるのが、網羅的な部品表です。また、セキュアな環境を維持するには、定期的なインベントリの作成が不可欠です。

リストを作成したら、次はワークロードセキュリティに関する主要な問題に対処します。

• 1. 認証は必須
  このシリーズを最初からお読みいただいている方には、すでにおなじみの内容でしょう。コンテナセキュリティのあらゆる側面に共通するテーマの1つは、「入口を施錠する」ことです。
  
  これらのサービスはすべて、クラスター内でワークロードとして実行されます。そのため、APIやデータへのアクセスにデフォルトの認証情報が使用されていたり、初期構成が「オープン」になっていたりすることが少なくありません。ワークロードセキュリティの対象には、アプリケーションの機能と運用に必要なすべてのコンポーネント、ソフトウェア、アプリケーションサービスが含まれます。
  
  
• 2. 悪意のあるコンテンツは有害
  認証情報を必須とし、アクセス制御を適用して入口を固めた後も、悪意のあるコンテンツへの警戒は必要です。これは、使用中のアプリケーション、マイクロサービス、運用サービスのいずれにも当てはまります。ユーザー（運用担当者か一般利用者かを問いません）向けのインターフェースを提供するワークロードは、すべて潜在的なリスクにさらされています。そこで不可欠なのが、スキャンとその結果に基づく対応です。まず、HTTPまたはアプリケーションロジックに関するアプリケーション層の脆弱性を特定します。脆弱性が見つかったら、対処が必要です。カスタムアプリであれば、開発部門に差し戻します。サードパーティ製コンポーネントであれば、パッチ適用済みまたはアップグレード済みのバージョンがあるかどうかを確認します。サードパーティ製コンポーネントはコンテナイメージとして提供されることが多く、Snykの「2019 State of Open Source Security」レポートによると、その44%に既知の脆弱性があり、より新しく、セキュリティが強化されたベースイメージが提供されています。
  
  繰り返します。スキャンを実行しても、修復しなければセキュリティは向上しません。
  
  壁に穴があり、侵入者が施錠されたドアを簡単に迂回できるなら、その穴を塞ぐはずです。同様に、仮想の壁にある仮想の穴も塞いでください。
  
  開発者が脆弱性にすぐ対処できない場合や、サードパーティプロバイダーがまだ脆弱性を解消していない場合は、WebアプリケーションファイアウォールまたはAPIセキュリティゲートウェイを使用することで、修復手段を確保できます。
  
  これは「着信を選別する」と表現するのが最も適切です。受け入れる前に、あらゆるワークロードへのリクエストを検査し、評価するためです。
  
  
• 3. リソースの共有はリスクの共有を意味する
  従来の仮想化と同様に、コンテナは完全には分離されていません。最終的に、コンテナは同じ物理OSを共有します。つまり、共有OSの脆弱性は、コンテナ共通の脆弱性となります。

攻撃者がOSコンポーネントの脆弱性を悪用できた場合、1つ以上のワークロードが侵害される可能性があります。こうした脆弱性は、「戸締まり」や「着信の選別」が不十分なために露呈することがあります。これは決して非現実的なシナリオではありません。実際、CVE-2019-5736では、OSレイヤーのruncの脆弱性によってインターネット全体に動揺が広がりました。

ここでのセキュリティの基本原則について、SELinuxとRedHatのコンテナセキュリティの第一人者であるDan Walshは、次のような有名な言葉を残しています。「コンテナは封じ込めない」。

ノード外部のサービスやユーザーとの間のネットワークトラフィックは、すべてホストOSを経由する必要がある点に注意が必要です。ノード上のPodとコンテナ間の通信は、仮想ブリッジとiptablesを巧みに活用した仮想ネットワークによって実現されます。しかし最終的には、トラフィックがその物理ノードから外部へ出る際に、ホストOSで処理されます。エージェント、プラグイン、その他のデーモンが、セキュリティや可視性の確保を目的として、そのトラフィックを監視またはキャプチャしている場合があります。これらは侵害につながる可能性があるため、「パイプラインセキュリティ」を読んだ後に作成し始めたインベントリに追加してください。

• 4. 機密情報のログ記録
  コンテナセキュリティの説明に、ログに関する警告が含まれるとは予想していなかったかもしれません。しかし、機密情報がログファイルに記録されることがあるため、注意が必要です。認可トークン、暗号化プロバイダーのキー、認証情報などは、いずれもワークロードによって誤ってログに記録されたり、stderrに出力されたりする可能性があります。多くの場合、これは認証エラーに起因する問題を追跡する必要があるためです。原則として、シークレットをシステムログに記録しないよう求め、可能であれば禁止してください。
  
  開発者がこのリスクを確実に認識できるよう、ログ設計ガイドを提供し、ログへの記録が許容される情報と許容されない情報を明記することを検討してください。

コンテナ環境におけるワークロードセキュリティの多くは、本番環境で稼働する他のアプリケーションワークロードと同様です。アクセスを制御して強力な認証を必須とし、悪意のあるコンテンツを監視するとともに、共有リソースやプラットフォームレベルの脆弱性に注意してください。