認定Kubernetesセキュリティスペシャリスト（CKS）スタディガイド

第6章. サプライチェーンのセキュリティ

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

これまでの章では、主にKubernetesクラスタとそのコンポーネントのセキュリティ、クラスタノードの実行に使用されるOSインフラ、既存のコンテナイメージを使用してクラスタノード上でワークロードを実行するための演算子に焦点を当ててきた。本章では一歩引いて、コンテナイメージを設計、構築、最適化するためのプロセス、ベストプラクティス、ツールについて掘り下げていく。

独自のコンテナイメージを作成せず、別のチームや企業が作成した既存のコンテナイメージを利用することもある。コンテナイメージを使用してワークロードを実行する前に、既知の脆弱性を手動または自動化された方法でスキャンすることは、審査プロセスの一部であるべきだ。ここでは、構築済みコンテナイメージのセキュリティリスクを特定、分析、緩和するために使用される CKS 試験に関連するいくつかのオプションについて説明する。

この章では、高いレベルで以下の概念をカバーする：

• ベース画像のフットプリントを最小限に抑える

• サプライチェーンの確保

• ユーザのワークロードを静的に分析する

• 既知の脆弱性について画像をスキャンする

ベース画像のフットプリントを最小限に抑える

コンテナ・イメージの構築プロセスは、表面的には簡単そうに見えるが、悪魔はしばしば細部に宿る。コンテナ・イメージを構築する際に、不必要にサイズが大きすぎたり、脆弱性に満ちていたり、コンテナ層のキャッシュに最適化されていなかったりするのを避けることは、このトピックを始めたばかりの人にはわからないかもしれない。この章では、コンテナ・エンジンDockerの助けを借りて、これらの側面すべてに対処していく。

シナリオコンテナの脆弱性を悪用する攻撃者

Dockerfileを定義する際に最初に決めなければならないことのひとつが、ベース・イメージの選択だ。ベースイメージはオペレーティングシステムと追加の依存子を提供し、シェルアクセスを公開することもある。

Docker Hubのようなパブリック・レジストリで選択できるベース・イメージの中には、サイズが大きく、アプリケーションをその中で実行するのに必ずしも必要でない機能が含まれている可能性が高いものもある。オペレーティングシステム自体や、ベースイメージで利用可能な依存関係は、脆弱性を露呈する可能性がある。

図6-1では、攻撃者はコンテナにアクセスすることで、コンテナに関する詳細を把握することができた。これらの脆弱性は、より高度な攻撃のための発射台として利用することができる。

図6-1. コンテナ・イメージの脆弱性を悪用する攻撃者

最小限の機能と依存関係を持つベースイメージを使用することを推奨する。次の2、3のセクションでは、より最適化されたベースイメージを作成するメソッドについて説明する。このメソッドは、ビルドがより速く、コンテナレジストリからのダウンロードがより速く、そして最終的には、単に肥大化を抑えることで攻撃対象領域を小さくすることにつながる。次のセクションでは、最も重要なテクニックについて触れる。Dockerfileの書き方のベストプラクティスについては、 ...