あなたのKubernetesクラスタは信頼で動いているか？イメージ検証はもはやオプションではない理由

今日の動きの速いクラウド・ネイティブのエコシステムでは、Kubernetesがコンテナ・オーケストレーションのデファクト・スタンダードになっている。私たちはPodを素早くスピンアップし、多くの場合、さまざまなレジストリからコンテナイメージを引き出します。しかし、革新を急ぐあまり、重大な疑問が残る： クラスタ内で何が実行されているのか、本当にわかっているのだろうか？

その答えに信頼やイメージの完全性に関する仮定が含まれている場合、あなたのクラスターは盲信的に動いている可能性がある。

企業がアプリケーションのパッケージ化とデプロイをコンテナに依存するようになるにつれ、クラスタで実行されるコンテナイメージの完全性と信頼性を確保することが最重要課題となっています。イメージの検証は単なる "nice-to-heave "ではなく、堅牢なKubernetesセキュリティ体制の柱として譲れないものです。

なぜコンテナイメージを検証する必要があるのか？

コンテナイメージはKubernetesアプリケーションの構成要素です。あなたのコード、その依存関係、そして実行環境をカプセル化します。しかし、この利便性は、イメージが適切に吟味されていない場合、潜在的な脆弱性ももたらします。

画像認証がもはやオプションではない理由がここにある：

• サプライチェーン攻撃： 攻撃者は、ソフトウェアのサプライチェーンを標的とし、正規の画像に悪意のあるコードを埋め込むことが増えています。検証を行わないと、下流で被害者が発生することになります。
• 🐞 既知の脆弱性： О 既知の脆弱性：多くのイメージは、古いパッケージや脆弱なパッケージを含むベースレイヤーに依存しています。未検証のイメージは、あなたの知らないうちに CVEs (Common Vulnerabilities and Exposures: 共通の脆弱性と暴露) にさらされる可能性があります。
• 設定ミス： ┧ 設定の誤り：root として実行されるイメージ、未使用のポートの公開、ハードコードされたシークレットは、攻撃者にとって容易なアクセスポイントを作ります。
• 🎯 ヒューマンエラー： 人為的ミス：開発者が誤って、古い、あるいは似たような名前の、しかし安全でないイ メージ・バージョンを使ってしまうかもしれません。厳密なチェックがなければ、間違いが本番環境に紛れ込んでしまいます。
• 📋 コンプライアンスの失敗： PCI DSS、SOC 2、HIPAA などの基準では、ソフトウェアの完全性と出所の証明が義務付けられています。検証されていないイメージの実行は、監査の失敗や規制上の罰則を意味します。

強力な検証システムがなければ、Kubernetesクラスターがチェックされていないソフトウェアの無秩序な環境となり、組織が大きなリスクにさらされる可能性がある。

カイバーノはどのように画像検証を解決し、簡素化するか

Kubernetesエコシステムは、信頼を超えて検証可能な完全性を強制するための強力なツールを提供している。そのような傑出したソリューションの1つが、Kubernetesのために特別に設計されたポリシーエンジンであるKyvernoだ。

Kyvernoはアドミッションコントローラとして動作し、ワークロードがクラスタにアドミッションされる前にAPIリクエストをインターセプトしてポリシーを適用します。このため、デプロイ時に画像検証ポリシーを適用するのに理想的です。

カイバーノを画像認証に使用する主な利点：

• ✅画像署名を検証する： 画像が本物であり、改ざんされていないことを保証するために、暗号署名を強制します。
• 📜証明書のチェック： スキャンステータスやビルド証明など、画像に関する署名されたメタデータを検証します。
• 🔒登録を制限する：信頼できるソースからの画像のみを許可します。
• 🏷️タグ付けの標準を実施する： 画像に明示的なタグを使用し（例：latest ）、バージョン管理規約に従うようにする。

画像検証のためのカイバーノポリシーの例

実際のポリシーの例をいくつか見てみましょう。これらの例を使う前に、Kyvernoがクラスタにインストールされていることを確認してください。

シナリオ1：承認されたレジストリに画像を制限する

よりシンプルで効果的なポリシーは、画像が組織の信頼できるレジストリからのみ提供されるようにすることです。

---
apiVersion: kyverno.io/v1
種類クラスタポリシー
というメタデータがある：
 name: 制限画像登録
スペック
 validationFailureAction：Enforce # バリデーションに失敗した場合、デプロイメントをブロックする
 のルールがある：
 - 名前：validate-registries
 と対戦する：
 どんなことでも：
 - リソースがある：
 種類だ：
 - ポッド
 - 配備
 - ステートフルセット
 - 仕事
 - クロンジョブ
 を検証する：
 というメッセージが表示されます："画像は承認されたレジストリ（gcr.ioまたはmy.private.registry）から取得する必要があります。"
 パターンがある：
 スペック
 の容器がある：
 - のイメージになります："gcr.io/* | my.private.registry/*"# レジストリのパターン

承認されていないレジストリからのイメージが使用された場合、明確な検証メッセージが表示され、デプロイはブロックされます。

シナリオ2：コサインによる画像の署名の確保

Sigstoreプロジェクトの主要コンポーネントであるCosignは、ソフトウェア成果物に暗号的に署名・検証し、これらの署名と証明をOCIレジストリ内に保存するための広く採用されているツールです。Kubernetes SecretsまたはURL経由で、イメージ検証用の公開鍵にアクセスできるようにする。

KyvernoはverifyImagesルールを介してCosignと直接統合し、コンテナイメージの署名とイントート認証を検証するポリシーを実施します。これにより、信頼され検証されたイメージのみがKubernetesクラスタにデプロイされます。

以下は、production ネームスペースに配置されたすべてのイメージが特定の公開鍵で署名されていることを保証するKyvernoClusterPolicy です：

---
apiVersion: kyverno.io/v1
種類クラスターポリシー
というメタデータがある：
 name: チェック画像署名
スペック
 validationFailureAction：強制する
 background: false
 webhookTimeoutSeconds：30
 failurePolicy：失敗
 のルールがある：
 - name: 検証画像署名
 と対戦する：
 どんなことでも：
 - リソースを提供する：
 種類だ：
 - ポッド
 の名前空間を使用します：
 - 生産
 verifyImages：
 - 画像参照：
 - "registry.example.com/*:*"# 画像パターンに合わせる
 証言者
 - カウント1
 エントリー
 - キーだ：
 publicKeys：| #公開鍵はポリシーで直接定義するか、クラスタ内の別の場所にある標準的なKubernetes Secretをk8s://の形式で指定して参照します。<名前空間>/<シークレットネーム>. 名前付きSecretは、検証に使用する公開鍵を含む鍵cosign.pubを指定しなければならない。
 -----公開鍵の開始
 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEyourPublicKeyContentHere...
 -----公開鍵の終わり

署名されたイメージは通常通り配備することができ、署名されていないイメージを実行しようとすると、次のようなポリシーエラーが発生します：

シナリオ3：脆弱性スキャンの証明の検証

ソフトウェアのサプライチェーンの完全性を維持するための重要な側面は、イメージに対して定期的に脆弱性スキャンを実施することである。最初のビルド時のスキャンは出発点ですが、スキャンは新しい脆弱性が出現するたびに繰り返さなければなりません。Kyvernoは、イメージが最近の脆弱性スキャンを正常に受けたことを証明する証明書をチェックすることで、この実施を支援します。

TrivyのKyvernoClusterPolicy 、Podイメージの脆弱性スキャンが1週間を超えないよう、検証チェックを実施している。

---
apiVersion: kyverno.io/v1
種類クラスターポリシー
というメタデータがある：
 name: チェック脆弱性
スペック
 validationFailureAction: enforce
 webhookTimeoutSeconds：30
 failurePolicy：失敗
 のルールがある：
 - 名前：not-older-than-one-week（1週間以内
 と対戦する：
 どんなことでも：
 - リソースがある：
 種類だ：
 - ポッド
 verifyImages：
 - 画像参照：
 - "registry.example.com/*:*"# 画像パターンに合わせる
 を証明する：
 - predicateType: cosign.sigstore.dev/attestation/vuln/v1
 という条件がある：
 - すべて
 - キー: "{{ time_since('','{{metadata.scanFinishedOn}}','') }}"
 演算子：LessThanOrEquals
 値を指定します："168h"

Kyvernoは、イメージの脆弱性スキャンが最近行われておらず、コサインによる脆弱性スキャンの証明書がない場合、ポッドの作成をブロックします。

これらはほんの一例です。Kyvernoの柔軟性により、特定の画像タグやラベルをチェックしたり、認証データに基づいて深刻度の高い脆弱性のある画像を拒否するなど、よりきめ細かな制御が可能です。

結論

画像検証は単なるベストプラクティスではなく、セキュアなクラウドネイティブオペレーションにとって基本的に必要なものである。Kyvernoのようなツールは、盲目的な信頼から検証可能なセキュリティへと移行するための強力かつ柔軟な方法を提供します。画像署名検証、認証チェック、レジストリ制限を実装することで、ソフトウェアサプライチェーンを標的とするさまざまな脅威に対する強力な防御を構築することができます。

Kyvernoのドキュメントと Cosignをご覧になり、コンテナワークロードのセキュリティを今すぐご確認ください。より詳しい情報をお知りになりたい場合、または弊社のサービスにご興味をお持ちの場合は、お気軽にお問い合わせください。こちらからお問い合わせください。