Kubernetes ソフトウェア サプライ チェーンのセキュリティ保護

現代のソフトウェア開発手法では、ソフトウェア サプライ チェーンのセキュリティがこれまで以上に重要になっています。私たちのコードはオープンソース ライブラリに依存しており、オープンソース ライブラリは他のライブラリ (私たちが開発もコンパイルもしていない、どこから来たのかほとんどまたは全く分からない大量のコード) に依存しています。

これらのコードのいくつかはほとんどどこにでもあります。業界全体に大混乱をもたらした Log4Shell の脆弱性は、一般的な Java ログ記録コンポーネントである log4j の古いバグによって引き起こされました。私たちは、巨人の肩の上に産業を築いているのではなく、余暇と親切心からグローバル インフラストラクチャを機能させている少数のアプリケーションおよびコンポーネントの保守担当者の肩の上に産業を築いているのです。

分散開発はリスクを増大させる

これはメンテナーの作業を軽減するものではありません。これらは、小さなモジュールからコンテナベースのプラットフォーム全体まで、あらゆるものを提供する、現代のソフトウェア サプライ チェーンの重要な部分です。彼らのコードが重要であるため、彼らは過小評価され、低賃金で働いています。残念なことに、悪意のある人物がコードのメンテナンスを引き継ぐことを申し出て、信頼できるという履歴があるためにコードが自動的にインストールされることを期待してマルウェアを追加するというケースが何度かありました。

コードがチームの一部になるにつれて、今回のような攻撃が増えることが予想されます。自分自身とアプリケーションをどのように保護すればよいでしょうか?まず第一に、ソフトウェア サプライ チェーンは存在し、コードを孤立して構築しているわけではなく、これまでそうしたことは一度もなかった (あるいは一度もなかった) ということを理解する必要があります。オープンソースおよびサードパーティのライブラリは、ソフトウェアの作成方法において大きな役割を果たしており、今後ますます重要になっていきます。

ソフトウェア サプライ チェーンのセキュリティを確保するには、どのような手順を踏めばよいでしょうか?ソフトウェア部品表を管理するためのツールの提供については、ライブラリのコードのスキャン、静的および動的分析の使用、コードへのデジタル署名とハッシュの追加、すべてを管理されたリポジトリに配置するなど、多くの作業が行われてきました。しかし、1 つの点が不明のままです。この作業と使用しているコードをどのように検証すればよいのでしょうか。結局のところ、古くからあるセキュリティの格言の 1 つは「信頼はするが、検証もする」です。

ソフトウェアサプライチェーンのセキュリティ確保

使用するコードを信頼する必要がありますが、信頼できるかどうかも検証する必要があります。また、リポジトリ内のコードが変更されると Cloud Native Code が新しいビルドをリリースするため、厳しい時間的制約の中でこれを行う必要がありました。ここで重要なのは、現代の開発の自動化された性質です。GitHub などのプラットフォームがソフトウェア ライフサイクルの中心となり、継続的インテグレーションと継続的デリバリー (CI/CD) を提供します。

マイクロサービス アーキテクチャとコンテナの組み合わせ哲学に基づいて設計された Kubernetes などのテクノロジーを使用すると、状況はさらに複雑になります。私たちのコードはスタンドアロン コンテナーで実行できますが、ネストされた抽象ユーザーランドで実行され、各 Dockerfile は一連の依存関係を収集しますが、その多くは完全に文書化されていません。使用するコンテナ内の部品表を信頼できるかどうか。

推奨ホワイトペーパー:

はじめに: アーティファクト検証ワークフロー Microsoft のクラウド ネイティブ オープン ソース チームは、この問題の解決に役立つ新しい仕様の作成に取り組んでいます。 Approval は、Kubernetes アプリケーションのさまざまな成果物をサポートする検証フレームワークです。信頼できるセキュリティ メタデータのセットと署名された部品表を使用して、展開するすべてのものが意図したものと同じであることを確認します。

イメージやその他のコンポーネントは、Notary V2 署名および検証ツールと ORAS (OCI Registry as Storage) アーティファクト仕様を活用します。 ORAS は、コンテナだけでなくあらゆるものの保存を対象とする OpenContainer Initiative レジストリ定義の一部です。これは、ソフトウェア部品表を整理する方法として有効です。興味深いことに、Bindle 分散アプリケーション インストーラー定義と ORAS マニフェストには共通点があり、SBOM から検証済みの分散アプリケーション インストーラーへの移行が簡単になります。これらを組み合わせることで、Kubernetes クラスター内の認証シナリオの一部として解析および使用できるサプライ チェーン グラフが提供されます。

これらの概念を結び付け、ソフトウェア部品表にポリシーを適用し、さまざまなサプライ チェーンにわたってコードとその依存関係を検証するワークフロー エンジンを追加します。本質的には、コンテナ イメージ全体のポリシー ワークフローを管理するオーケストレーターです。拡張可能であるため、Kubernetes で使用されるものと同様の使い慣れたプラグイン モデルを使用して、パブリック レジストリとプライベート レジストリ全体で動作します。

ポリシー主導の承認

Proparly が使用するポリシー モデルは使い慣れたツールに基づいており、独自の構成を使用して基本的なポリシーを迅速に展開できるだけでなく、Open Policy Agent を使用して構築されたより複雑なポリシーも展開できます。また、アプリケーション開発ライフサイクルのさまざまな段階で機能し、CI/CD システムに接続してビルド時に成果物を検証したり、Kubernetes に接続してビルドと実行の間でコードが変更されないようにしたりします。スタック全体で機能する検証モデルを用意し、ビルド、リポジトリ、レジストリ、および実行時にコードに対して発生するサプライ チェーン攻撃を回避できるようにすることが重要です。

ソフトウェア ライフサイクル全体にわたって 1 つのツールで検証を処理することは、ポリシーを 1 回だけ記述すれば済むため重要です。さまざまなシナリオにさまざまなツールを使用すると、ポリシーの転記や翻訳のエラーのリスクが高まります。単一のツールと単一のポリシー形式を使用すると、このリスクを回避するのに役立ちます。また、コードを配信する前に「前提条件は何か」を調査するのに役立つ外部戦略テスト ツールを用意することもできます。

最初の戦略を構築する

Approval チームは、Kubernetes で Gatekeeper とともに Approval を使用する方法を示すデモ コードを GitHub リポジトリに用意しています。これは Helm チャートを使用してインストールされ、いくつかのサンプル構成テンプレートが付属しています。これらを使用して、署名のないすべての画像をブロックするなどのアクションをテストできます。 Gatekeeper は署名されていないコンテナ イメージを拒否し、実行されないようにします。

ポリシー ファイルは YAML で記述されているため、Visual Studio Code やその他のツールで編集し、コード フォーマット ツールを利用できます。これらは、検証を通じて段階的に成果物を生成するシンプルなルール エンジンとして構築されています。それらは承認されたレジストリからのものですか?異なる署名に対してアーティファクトを複数回チェックしますか?独自のプライベート レジストリ内のアーティファクトは、パブリック レジストリ内のアーティファクトよりも信頼されますか?複数のチェックを実行すると、すべての検証エンジンが一致しますか?実行時検証のルールは簡単に定義できますが、さまざまな信頼のルートからの署名を使用してさまざまな成果物の状態を判断する必要がある CI/CD システムで実行される実行時検証の場合は、そう簡単にはいかない可能性があります。

Approval は現在、ソフトウェア BOM 内のすべての要素を管理するためのツール セットを提供する興味深い初期提案です。長期的に隠れる可能性のあるゼロデイの影響を防ぐことはできませんが、影響を受けるコードを迅速に特定し、そのコードが使用および実行されないようにするルールを作成できます。

サプライチェーンのリスクが注目される中、業界はこのような提案を慎重に検討し、公の場で作業を行うことが不可欠です。 Microsoft が Cloud Computing Foundation と承認を共有することを約束したのは喜ばしいことです。これにより、より広範な Kubernetes 開発コミュニティから必要なレビューが得られるはずです。

参考記事:

https://docs.ceph.com/en/latest/dev/cephfs-snapshots

https://knowledgebase.45drives.com/kb/kb450160-cephfs-snapshots/