2022 年のクラウド ネイティブ セキュリティの開発に関する 24 の洞察

今日、クラウド ネイティブ テクノロジーは、企業に迅速な配信の利点をもたらすだけでなく、新たなセキュリティ要件と課題ももたらします。一方では、新しいテクノロジー（コンテナ、オーケストレーション、DevOps、マイクロサービス）の導入により、イメージサプライチェーンの問題、コンテナエスケープの問題、クラスターの横方向の移動の問題、マイクロサービス境界の問題など、新しいセキュリティ問題が生じており、新しいセキュリティ保護対策の導入が必要になっています。一方、クラウドネイティブの継続的開発/統合開発モードへの移行に伴い、従来のセキュリティでは新しい開発リズムやセキュリティ要件に適応できなくなります。

本稿では、コンテナセキュリティ研究を長期にわたって追跡した後、さまざまな資料に基づいて、コンテナ開発、コンテナイメージセキュリティ、K8S開発の技術動向を整理して分析することに焦点を当て、業界のセキュリティ関係者と共有して、クラウドネイティブセキュリティの発展に貢献します。

1. コンテナエコシステムの発展に関する8つの洞察

従来の展開と比較して、セキュリティの専門家と管理者は、コンテナと基盤となるインフラストラクチャを含むコンテナ化された環境で保護する必要があるコンポーネントがますます複雑になっています。すべてのコンポーネントが開発の初期段階からライフサイクルの終わりまで確実に保護されるようにするには、セキュリティを開発パイプラインに統合する必要があります。

洞察 1: 半数以上の組織が 250 個を超えるコンテナを実行しており、6% の組織が 5,000 個を超えるコンテナを管理しています (図 1 を参照)。これは、ますます多くのワークロードが従来のアーキテクチャからコンテナへと移行していることを示しています。

図1 実行中のコンテナの数

洞察 2: ホストあたりのコンテナ数の中央値は増加しており、2020 年には前年比 33% 増、2021 年には前年比 12% 増の 46 個となっています (図 2 を参照)。多くの組織がハードウェア リソースの使用率向上の恩恵を受けています。

図2 ホストあたりのコンテナ数の中央値

洞察 3: コンテナの約 44% は 5 分未満しか存続しません (図 3 を参照)。多くのコンテナは、関数を実行するのに十分な時間だけ持続します。数秒は短いように思えるかもしれませんが、一部のプロセスでは十分です。これは、コンテナの一時的な性質がテクノロジーのユニークな利点の 1 つであり続ける一方で、監視、セキュリティ、コンプライアンスなどの新たな問題を含む新たな課題ももたらすことを示唆しています。

図3 コンテナのライフサイクル

洞察 4: コンテナ ランタイムの使用状況では、Docker の採用が 46% を占め、初めて 50% を下回りましたが、Docker は依然として組織内で最も広く使用されているコンテナ ランタイムです (図 4 を参照)。

図4 コンテナランタイム

洞察 5: コンテナ リポジトリの使用率に関しては、Quay が初めて Docker を上回り、顧客の採用率の 26% を占めました (図 5 を参照)。

図5 コンテナイメージリポジトリ

洞察 6: リソース使用量の制限に関しては、コンテナの 60% が CPU 制限を定義しておらず、51% がメモリ制限を定義していません。 CPU にバインドされたクラスターでも、平均して CPU コアの 34% が未使用でした (図 6 を参照)。

図6 コンテナ容量計画

洞察 7: オープンソース ソフトウェアの使用に関しては、コンテナ ベースのアプリケーション開発では、上位 12 のオープンソース テクノロジが使用されており (図 7 を参照)、上位 3 つは NGINX、GO、JMX です。

図7 コンテナオープンソースソフトウェア

洞察 8: コンテナ化されたサービスは継続的に改善されており (図 8 を参照)、そのサービス寿命は比較的安定しており、サービスの 31% は 2 週間以上持続します。

図8 コンテナ化されたサービスサイクル

2. コンテナイメージのセキュリティに関する8つの洞察

組織がより多くのコンテナ ワークロードを本番環境に移行するにつれて、DevOps ワークフローにセキュリティとコンプライアンスを統合する必要があることがわかります。コンテナ イメージはコンテナのセキュリティにおいて重要な役割を果たします。イメージから作成されたコンテナは、セキュリティの脆弱性、誤った構成、さらにはマルウェアなど、イメージのすべての特性を継承します。

洞察 1: イメージの 76% は最終的に root として実行されます (図 9 を参照)。

図9: ルートとして実行されているコンテナ

洞察 2: パブリック イメージ リポジトリの信頼度は高まっており、2020 年の 47% から 2021 年には 61% に増加しています (図 10 を参照)。

図 10 ミラーリポジトリからのプル (パブリックリポジトリとプライベートリポジトリ)

洞察 3: RHEL は、使用されているベース イメージの 36% を占め、圧倒的に最も人気のあるベース イメージです。一方、Alpine を使用しているのは 25% のみです (図 11 を参照)。 Alpine のようなスリムなベースイメージを使用することで、コンテナの攻撃対象領域を減らすことができます。

図11 基本イメージオペレーティングシステム

洞察 4: イメージ ライフサイクル データは、コード リリース間の時間の変化を反映しており (図 12 を参照)、コンテナー イメージの約半分が 1 週間以内に置き換えられます。

図12 コンテナイメージのライフサイクル

洞察 5: コンテナ ワークロードでは、62% のコンテナでシェルが検出され、38% のコンテナが機密マウント ポイントで開始されていることが検出されました (図 13 を参照)。これは、コンテナがホスト システム上の重要なファイルを変更できることを意味します。

図13 コンテナランタイムセキュリティ警告

洞察 6: イメージの 52% は実行時にスキャンされ、42% は CI/CD パイプラインで最初にスキャンされます (図 14 を参照)。 Qingteng 氏は、新たに明らかになった脆弱性を発見するために、イメージの作成、配布、運用の各段階ですべてのコンテナを継続的に再スキャンすることを推奨しています。

図14 スキャン画像の位置

洞察 7: 本番環境で実行されているイメージの 85% に、少なくとも 1 つのパッチ可能な脆弱性が含まれています。さらに、イメージの 75% に「高」または「重大」なパッチ可能な脆弱性が含まれていました (図 15 を参照)。

図15: 実行時に脆弱性を修正できる

洞察 8: 関心のあるアラートの中で、Kubernetes.node.ready が依然として最もよく使用されており、CPU 使用率と稼働時間インジケーターがそれに続きます (図 16 を参照)。

図16 トップ10アラート

3. K8Sセキュリティ開発に関する8つの洞察

組織における Kubernetes の使用は成熟しつつありますが、Kubernetes は多くの構成と管理を必要とする複雑なプラットフォームです。 Kubernetes ワークロードを保護するには、セキュリティ対策を実装して、主要なアーキテクチャの脆弱性とプラットフォームの依存関係に対処する必要があります。

Pod は Kubernetes における最小のデプロイメント ユニットであり、1 つ以上のコンテナーで構成されます。ポッドは、コンテナの脆弱性を悪用するネットワーク攻撃者にとって、最初の実行環境となることがよくあります。このような状況を踏まえ、ネットワーク攻撃者が脆弱性を悪用することを困難にし、侵入による影響範囲を制限するために、Pod のセキュリティを強化する必要があります。

洞察 1: Kubernetes はオーケストレーション ツールの使用において絶対的な主流となり、K8S の使用率は 96% に達しています (図 17 を参照)。

図17 オーケストレーションツール

洞察 2: 過去 2 年間で、組織あたりのポッドの平均数は 2 倍に増加しており (図 18 を参照)、Kubernetes ホストの平均数も同様に相対的に増加しています。

図18 組織あたりのポッド数

洞察 3: 全体的に、ほとんどのユーザーは比較的少数のクラスターを持っており、49% のユーザーは 1 つのクラスターのみを持っています。さらに、各クラスター内のノード数は比較的少なく、ほとんどの場合、1 ～ 5 個のノードしかありません。これは、多くの企業がまだ Kubernetes の使用の初期段階にあることを示しています (図 19 を参照)。将来、企業はより多くのクラスターと、各クラスター内のより多くのノードへと移行するでしょう。

図19 クラスターの数と各クラスター内のノード数

洞察 4: クラスターあたりのポッド数は大幅に増加しており、組織の 54% がクラスターあたり 100 を超えるポッドを実行しています (図 20 を参照)。ノードあたりのポッドの平均数は減少しており、チームがワークロードを処理するためにより多くの小さなノードを展開していることを示しています。

図20 クラスターポッドの数とノードポッドの数

洞察 5: Kubernetes 組織はホストごとに 16 個のポッドを実行しますが、ECS を使用する組織はホストごとに 5 つのタスクを実行します。両環境の数値は 2020 年から 2021 年にかけて一貫しており、組織がアプリケーションをサポートするために適切な数のポッドとタスクを見つけていることを示しています。また、Kubernetes Pod と ECS タスクは平均 1.5 個のコンテナを実行していることもわかりました (図 21 を参照)。

図21 環境ごとのホスト密度

洞察 6: Kubernetes は、メトリックに基づいてポッドを水平方向または垂直方向に自動的にスケーリングし、可用性とパフォーマンスに優れたコンテナ アプリケーションを構築できます。ポッドの総数を水平方向にスケーリングすると、アプリケーションが需要の変動に対応できるようになります。一方、個々のポッドの CPU とメモリを垂直方向にスケーリングすると、アプリケーションの全体的なパフォーマンスとコストを管理するのに役立ちます。 Kubernetes 組織の約 40% が HPA (水平スケーリング) を使用していますが、VPA (垂直スケーリング) を使用している組織は 1% 未満です (図 22)。

図22. Kubernetesの自動スケーリング使用状況の経時変化

洞察 7: 組織は平均 13 個の StatefulSet と 28 個の PVC (永続ボリューム要求) を使用しており (図 23 を参照)、ステートフル アプリケーションを含むさまざまなワークロードをサポートするために Kubernetes への依存度が高まっていることを示しています。

図 23 Kubernetes ステートフル セットと PVC の使用

洞察 8: Prometheus は、Kubernetes、OpenShift、Istio などのプロジェクトのメトリクスに広く使用されています。 3 つの主流ソリューションである JMX、StatsD、Prometheus のうち、Prometheus は 3 年連続で増加しました。前年比で、Prometheus メトリクスの使用率は昨年の 62% から 83% に増加しました。新しいプログラミング フレームワークの採用が拡大するにつれて、JMX メトリック (Java アプリケーション用) と StatsD などの代替メトリックは引き続き減少しており、JMX は昨年の 19% と比較して今年はわずか 4% に急落しています (図 24 を参照)。

図24 指標タイプの平均使用率​