コンテナ セキュリティの基礎: 作業負荷

このシリーズを初めて読む場合は、最初から始めることをお勧めします。 
コンテナ セキュリティの基礎: 導入
コンテナ セキュリティの基礎: パイプライン
コンテナ セキュリティの基礎: オーケストレーション

ワークロードは比較的新しい用語であり、applicationsを説明するためによく使用されますが、インフラストラクチャ サービスを指すこともできます。 これは重要です。なぜなら、コンテナ クラスターでは、必ずしも開発者から提供されるとは限らないさまざまな「ワークロード」が実行される可能性があるからです。 コンテナ環境内でさまざまな目的で無料のオープンソース サービスが使用されるケースが増えています。 これは実際に IT 運用全体に当てはまります。IT 運用は、過去 1 年間で無料およびオープン ソース ソフトウェアのダウンロード数で第 1 位のカテゴリでした。

したがって、ワークロード セキュリティとは、コンテナ環境にダウンロード、開発、またはデプロイしたソフトウェアすべてを指します。 領事について考えてみましょう。 Kubernetes自体について考えてみましょう。 PrometheusとElasticsearch を考えてみましょう。 NGINXとistio を考えてみましょう。

また、Kubernetes 環境をサポートするためにデプロイした API ゲートウェイ、キャッシュ、イングレス コントローラーもそのリストに追加します。 ここで、徹底した部品表が重要になり、安全な環境を維持するために定期的に在庫を確認することが極めて重要になります。

リストができたら、主要なワークロード セキュリティの問題に対処します。

• 1. 認証はオプションではありません
  このシリーズ全体をフォローしてきた人にとっては、これはお馴染みのことでしょう。 コンテナのセキュリティのあらゆる側面に共通するテーマの 1 つは、「正面玄関をロックする」ことです。
  
  これらのサービスはすべて、クラスター内のワークロードとして実行されます。 これは多くの場合、API やデータにアクセスするためのデフォルトの資格情報または「オープン」な初期構成を意味します。 ワークロード セキュリティには、applicationの機能と操作に必要なすべてのコンポーネント、ソフトウェア、およびapplicationサービスが含まれます。 
  
  

• 2. 悪意のあるコンテンツは悪意のあるものである
  資格情報を要求し、アクセス制御を適用してドアをロックした後でも、悪意のあるコンテンツについて心配する必要があります。 これは、使用中のapplications、マイクロサービス、運用サービスにも当てはまります。 ユーザー (オペレーターまたは消費者) にインターフェースを提供するすべてのワークロードは、潜在的に危険にさらされています。

  ここではスキャンと演技が必須です。 HTTP かapplicationロジックかを問わず、application層の脆弱性を見つけることが最初のステップです。 それらを見つけたら、それに対して何か行動を起こす必要があります。 カスタム アプリの場合は、開発部門に送り返します。 サードパーティのコンポーネントの場合は、パッチ適用済み/アップグレード済みバージョンが存在するかどうかを確認します。 サードパーティのコンポーネントはコンテナ イメージで提供されることが多く、 Snyk の 2019 年のオープン ソース セキュリティの現状レポートで指摘されているように、その 44% に既知の脆弱性があり、より新しく、より安全なベース イメージが利用可能になっています。
  
  もう一度言いますが、修復しなければスキャンを実行してもセキュリティは向上しません。
  
  壁に穴が開いていて、泥棒が鍵のかかったドアを簡単に抜けられるような場合は、その穴を塞ぐ必要があります。 仮想壁の仮想穴を塞いでください。
  
  Webapplicationファイアウォールまたは API セキュリティ ゲートウェイを使用すると、開発者が脆弱性にすぐに対処できない場合や、サードパーティ プロバイダーによってまだ解決されていない場合に修復する手段を提供できます。
  
  これは、あらゆるワークロードに対するリクエストを、それを受け入れる前に検査して評価することであるため、「通話をスクリーニングする」と要約するのが最適です。
  
  
• 3. リソースの共有はリスクの共有を意味する
  従来の仮想化と同様に、コンテナは完全に分離されていません。 コンテナは最終的に同じ物理 OS を共有します。 つまり、共有 OS の脆弱性は、共有された脆弱性を意味します。

攻撃者が OS コンポーネントの脆弱性を悪用できる場合、1 つ以上のワークロードを侵害する可能性があります。 これらの脆弱性は、「ドアをロックする」または「電話をスクリーニングする」ことを怠ったために露呈する可能性があります。 これは、OS レイヤーの runc 脆弱性がインターネットをパニックに陥れたCVE-2019-5736で見られたような、非現実的なシナリオではありません。 

ここでの中核となるセキュリティ原則は、SELinux および RedHat コンテナ セキュリティの第一人者である Dan Walsh によって次のように述べられています。 「コンテナには何も入っていません」 。 

ノード外部のサービスおよびユーザーとのすべてのネットワーク トラフィックは、ホスト OS を通過する必要があることに注意することが重要です。 ノード上のポッドとコンテナ間のネットワークは、仮想ブリッジを使用した仮想ネットワークと iptables の巧みな使用によって実現されます。 しかし、最終的にはトラフィックはその物理ノードから出る必要があり、それはホスト OS での処理を意味します。 エージェント、プラグイン、その他のデーモンは、セキュリティや可視性の目的でそのトラフィックを監視またはキャプチャしている可能性があります。 これらは、 Pipeline Securityについて読んだ後に収集を開始したインベントリに追加する必要がある潜在的な侵害ポイントです。

• 4. 機密情報の記録
  コンテナのセキュリティに関する議論にログに関する警告が含まれるとは予想していなかったかもしれません。 しかし、それは起こります。その理由は、機密情報がログ ファイルに残ってしまうことがあるからです。 認証トークン、暗号化プロバイダーキー、資格情報。 これらはすべて、誤ってstderr上のワークロードによってログに記録されたり表示されたりする可能性があります。 多くの場合、これは認証エラーによる問題を追跡する必要があるためです。 一般的に、システムへの秘密情報のログ記録は推奨せず、可能であれば禁止する必要があります。
  
  開発者がこのリスクを認識できるようにするために、ログ記録設計ガイドを提供し、ログに書き込むことが許容される内容と許容されない内容を指定することを検討してください。

コンテナ コンテキストにおけるワークロード セキュリティの多くは、運用環境で実行されている他のapplicationワークロードのセキュリティと同じです。 アクセスを制御し、強力な認証を要求し、悪意のあるコンテンツを監視し、共有レベルおよびプラットフォーム レベルの脆弱性に注意してください。