変化の速いクラウドネイティブ環境において、Kubernetesはコンテナオーケストレーションの事実上の標準となりました。私たちは次々とPodを立ち上げ、さまざまなレジストリからコンテナイメージを取得しています。しかし、イノベーションを急ぐあまり、ある重要な問いが置き去りになってはいないでしょうか。あなたのクラスタで実際に何が動いているのか、本当に把握できていますか?
もしその答えに、イメージの完全性に対する「信頼」や「思い込み」が含まれているなら、そのクラスタは盲目的な信頼の上に成り立っているかもしれません。サプライチェーン攻撃が高度化する今、それは極めて危険な姿勢です。
アプリケーションのパッケージングとデプロイにコンテナを使う組織が増えるにつれ、クラスタ上で動くコンテナイメージの完全性と真正性を担保することの重要性は飛躍的に高まっています。イメージ検証はもはや「あれば嬉しい」要素ではなく、堅牢なKubernetesセキュリティ態勢を支える、譲れない柱です。
なぜコンテナイメージを検証すべきか
コンテナイメージはKubernetesアプリケーションを構成する基本要素です。コード、依存関係、ランタイム環境を一つにまとめてくれる便利な仕組みですが、その手軽さは、十分に検証されていないイメージを使った場合に潜在的な脆弱性を持ち込む原因にもなります。
イメージ検証がもはや任意ではない理由は、次のとおりです。
- 🔓 サプライチェーン攻撃: 攻撃者はソフトウェアサプライチェーンを狙う傾向を強め、一見正規のイメージに悪意あるコードを混入させています。検証を行わないままでは、いつ被害を受けてもおかしくありません。
- 🐞 既知の脆弱性: 多くのイメージは、古い、あるいは脆弱性のあるパッケージを含むベースレイヤーに依存しています。未検証のイメージを使えば、知らぬ間にCVE(共通脆弱性識別子)にさらされかねません。
- 🔧 設定ミス: rootで実行されるイメージ、未使用ポートを公開しているイメージ、シークレットがハードコードされたイメージは、攻撃者にとって格好の侵入口になります。
- 🎯 ヒューマンエラー: 開発者が誤って古いバージョンや、似た名前の安全でないイメージを使ってしまうこともあります。厳格なチェックがなければ、こうしたミスが本番環境にそのまま流れ込みます。
- 📋 コンプライアンス違反: PCI DSS、SOC 2、HIPAAといった基準は、ソフトウェアの完全性と来歴の証明を求めています。未検証のイメージを稼働させていれば、監査で不合格となり、規制上のペナルティを受ける可能性もあります。
強力な検証の仕組みがなければ、Kubernetesクラスタは未確認のソフトウェアが野放しの無法地帯となり、組織は重大なリスクを抱えることになります。
Kyvernoはイメージ検証をどう実現し、どうシンプルにするのか
Kubernetesエコシステムには、「信頼」に頼らず検証可能な完全性を強制するための強力なツールが揃っています。その代表格が、Kubernetes専用に設計されたポリシーエンジンKyvernoです。
Kyvernoはアドミッションコントローラとして動作し、APIリクエストを横取りして、workloadsがクラスタに受け入れられる前にポリシーを適用します。そのため、デプロイ時にイメージ検証ポリシーを強制する用途に最適です。
Kyvernoでイメージ検証を行う主なメリットは次のとおりです。
- ✅ イメージ署名の検証: 暗号署名を必須化し、イメージが本物で改ざんされていないことを保証します。
- 📜 アテステーションの確認: スキャン状況やビルドの来歴など、イメージに関する署名済みメタデータを検証します。
- 🔒 レジストリの制限: 信頼できるソースのイメージのみを許可します。
- 🏷️ タグ運用ルールの徹底: 明示的なタグの利用(例:
latestを使わない)とバージョニング規約への準拠を強制します。
イメージ検証のためのKyvernoポリシー例
ここからは、いくつかの実用的なポリシー例を見ていきましょう。試す前に、クラスタにKyvernoがインストールされていることを確認してください。
シナリオ1:イメージを承認済みレジストリに限定する
シンプルながら効果的なポリシーとして、組織が信頼するレジストリ以外からのイメージ取得を禁止する方法があります。
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-image-registries
spec:
validationFailureAction: Enforce # 検証に失敗した場合はデプロイをブロック
rules:
- name: validate-registries
match:
any:
- resources:
kinds:
- Pod
- Deployment
- StatefulSet
- Job
- CronJob
validate:
message: "Images must be pulled from approved registries (gcr.io or my.private.registry)."
pattern:
spec:
containers:
- image: "gcr.io/* | my.private.registry/*" # 許可するレジストリのパターン
承認されていないレジストリのイメージが使われた場合は、明確な検証メッセージとともにデプロイがブロックされます。
シナリオ2:Cosignによるイメージ署名を必須化する
CosignはSigstoreプロジェクトの中核コンポーネントで、ソフトウェア成果物に対する暗号署名と検証を行い、その署名やアテステーションをOCIレジストリ内に保存できる、広く使われているツールです。イメージ検証用の公開鍵が、Kubernetes Secret経由またはURL経由でアクセスできる状態になっていることを確認してください。
Kyvernoは、verifyImagesルールを通じてCosignと直接統合し、コンテナイメージの署名とin-totoアテステーションを検証するポリシーを強制します。これにより、信頼され検証されたイメージのみがKubernetesクラスタにデプロイされる状態を確保できます。
以下のKyverno ClusterPolicyは、productionネームスペースにデプロイされるすべてのイメージが、特定の公開鍵で署名されていることを保証します。
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-image-signatures
spec:
validationFailureAction: Enforce
background: false
webhookTimeoutSeconds: 30
failurePolicy: Fail
rules:
- name: verify-image-signature
match:
any:
- resources:
kinds:
- Pod
namespaces:
- production
verifyImages:
- imageReferences:
- "registry.example.com/*:*" # 利用するイメージのパターンに合わせて調整
attestors:
- count: 1
entries:
- keys:
publicKeys: | # 公開鍵はポリシー内に直接定義することも、k8s://<namespace>/<secret_name>形式でクラスタ内の標準的なKubernetes Secretを参照することもできます。指定したSecretには、検証に使用する公開鍵を含むcosign.pubキーが必要です。
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEyourPublicKeyContentHere...
-----END PUBLIC KEY-----
署名済みのイメージは通常どおりデプロイできますが、未署名のイメージを実行しようとすると、次のようなポリシーエラーが発生します。
シナリオ3:脆弱性スキャンのアテステーションを検証する
ソフトウェアサプライチェーンの完全性を保つうえで欠かせないのが、イメージに対する定期的な脆弱性スキャンです。ビルド時のスキャンは出発点にすぎず、新たな脆弱性が判明するたびにスキャンを繰り返す必要があります。Kyvernoを使えば、最近脆弱性スキャンが完了したことを示すアテステーションをチェックすることで、これを強制できます。
以下は、Trivyが提供するKyverno ClusterPolicyの例で、Podイメージの脆弱性スキャンが1週間以内に実施されているかを検証します。
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-vulnerabilities
spec:
validationFailureAction: enforce
webhookTimeoutSeconds: 30
failurePolicy: Fail
rules:
- name: not-older-than-one-week
match:
any:
- resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "registry.example.com/*:*" # 利用するイメージのパターンに合わせて調整
attestations:
- predicateType: cosign.sigstore.dev/attestation/vuln/v1
conditions:
- all:
- key: "{{ time_since('','{{metadata.scanFinishedOn}}','') }}"
operator: LessThanOrEquals
value: "168h"
イメージが最近脆弱性スキャンを受けておらず、Cosignで署名された脆弱性スキャンのアテステーションが存在しない場合、KyvernoはPodの作成をブロックします。
ここで紹介したのはほんの一例です。Kyvernoは柔軟性が高く、特定のイメージタグやラベルのチェックはもちろん、アテステーションデータに基づいて深刻度の高い脆弱性を含むイメージを拒否するなど、よりきめ細かな制御が可能です。
イメージ検証は単なるベストプラクティスではなく、安全なクラウドネイティブ運用に欠かせない要件です。Kyvernoのようなツールは、盲目的な信頼から検証可能なセキュリティへと舵を切るための、強力かつ柔軟な手段を提供します。そして、workloadsを安全に保つだけでなく、適切にライトサイジングし、信頼性とコスト効率も高めたい場合には、PerfectScaleのようなプラットフォームがセキュリティツールを補完します。Kubernetesのworkloadsを継続的に分析し、パフォーマンスやコンプライアンスを損なうことなく最適化の機会を見つけ出します。
イメージ署名の検証、アテステーションのチェック、レジストリの制限を組み合わせて実装すれば、ソフトウェアサプライチェーンを狙うさまざまな脅威に対して強固な防御を築けます。
KyvernoのドキュメントとCosignを参考に、今日からコンテナworkloadsのセキュリティ強化を始めましょう。さらに詳しく知りたい方、当社のサービスにご関心のある方は、お気軽にこちらからお問い合わせください。