Kubernetesセキュリティのベストプラクティス: ビルドからランタイムまでのハードニング

Kubernetesはデフォルトで許容的な設定になっているため、クラスターのセキュリティはあなたの責任です。ビルド、デプロイ、ランタイムの各フェーズにわたるKubernetesセキュリティのベストプラクティスを学びましょう。

Kubernetes Securityとは何ですか？

Kubernetes Securityとは、クラスター、その上で実行されるワークロード、およびそれを供給するパイプラインを保護するために、ビルド、デプロイ、ランタイム全体に適用する一連のコントロールです。これらがなければ、認証されていない1つのリクエストでクラスター全体が乗っ取られる可能性があります。これはIngressNightmareで、2025年3月にingress-nginxで公開された深刻度9.8の脆弱性です。このコントローラーは、Kubernetesクラスターの40%以上で稼働しています。

そのadmission webhookは認証なしでpodネットワーク上に存在し、ingress-nginxはデフォルトでクラスター内のすべてのSecretを読み取ります。ネットワークに到達できれば、クラスターを掌握できます。エクスプロイトチェーンも、盗まれたパスワードも不要でした。必要だったのは、設定どおりに動作する緩いデフォルト設定だけです。

Kubernetesが標準で提供するものと、本番クラスターに必要なものとの間にあるこのギャップを埋めるのがハードニングです。Kubernetes security best practicesは、ビルドするイメージから実行するワークロードまで、フェーズごとにそのギャップを埋める方法です。オーケストレーションはワークロード、シークレット、east-westトラフィックを1つのコントロールプレーンに集約するため、1つの設定ミスで実行中のすべてのサービスが露出する可能性があります。だからこそ、この作業はプラットフォームではなく利用者側の責任になります。

Kubernetes Securityが重要な理由

Kubernetesは自らをハードニングしません。 CISA/NSA Kubernetes Hardening Guidanceでは、すべての新規クラスターに見られる3つの示唆的なデフォルトが記載されています。匿名でのAPIサーバーログインが有効、Secretはetcdに暗号化されず保存、監査ログは無効です。共有責任モデルでは、4つのコントロールが利用者の手に委ねられます。role-based access control (RBAC)、network policy、secrets encryption、runtime controlsです。クラウドプロバイダーがこれらを設定してくれることはなく、ディストリビューションも同様です。これらのコントロールは設定内に存在し、時間とともにドリフトするため、チームは手作業で監査する代わりに、Kubernetes security posture managementで継続的に検証するようになっています。

認証されていないAPIサーバーに攻撃者が到達すると、etcd内のすべてのSecretを読み取り、任意のノードにpodをスケジュールし、監査ログが沈黙したままnamespace間を移動できます。そのため、最初のシグナルが侵害そのものである可能性があります。1つの露出したエンドポイントが数分でクラスター全体へのアクセスに変わるという、IngressNightmareと同じパターンです。

採用が進むほど、その影響も拡大します。Cloud Native Computing Foundation (CNCF) Annual Cloud Native Surveyは、コンテナ利用者の82%が現在本番環境でKubernetesを実行していると報告しています。2023年の66%から増加しています。クラスターが顧客向けサービス、規制対象データ、監査義務の経路上に置かれる中、1つの見落としたコントロールが侵害リスク、監査不合格、報告対象インシデントへとつながり、その説明責任はチームが負うことになります。何が危険にさらされているかを理解することは、クラスターのどの部分がそのリスクを担っているかを把握して初めて意味を持ちます。

Kubernetesクラスターの中核コンポーネント

インベントリ化していないものをハードニングすることはできません。各コンポーネントは固有のセキュリティ露出を持ち、その露出を理解することで、どこにコントロールを適用すべきかが分かります。

コントロールプレーンのコンポーネント:

• API server: 実行するすべてのkubectlコマンド、すべてのadmission webhook、すべてのservice account tokenリクエストはAPI serverを通過します。ここへの不正アクセスは、クラスター全体の制御を意味します。
• etcd: 依存するすべてのクラスター状態、設定、Secretを保存します。etcdへの読み取りアクセスは、機能的にはクラスター全体のroot権限に相当します。
• Scheduler and controller manager: schedulerが侵害されると、ローカルリソースを悪用するために特定ノードへワークロードを配置できます。controllerの操作により、デプロイメント、レプリカ数、リソース割り当てが気付かれずに変更される可能性があります。

ワーカーノードのコンポーネント:

• kubelet: 各ノード上でpod specを実行するエージェントです。kubelet APIを露出したままにすると、攻撃者はコンテナを作成したり、ノード上で直接コマンドを実行したりできます。
• kube-proxy: サービスルーティングのためのネットワークルールを管理します。proxyルールの設定ミスにより、内部サービスが外部トラフィックに露出する可能性があります。
• Container runtime: ホスト上でコンテナを実行します。脆弱なruntimeは、それがサポートするすべてのコンテナとホスト自体を露出させると、 NIST SP 800-190は指摘しています。

Pods、containers、networking:

• Podはネットワークnamespaceを共有するため、pod内の1つのコンテナが侵害されると、ネットワークコントロールがなければ同じpod内の他のコンテナにアクセスできます。NetworkPolicyオブジェクトがなければ、異なるnamespace内のpodはデフォルトで自由に通信できます。 
• Container imageとinfrastructure-as-code (IaC)テンプレートは外部レジストリからクラスターに入ってきます。本番環境に取り込まれた汚染済みイメージは、それをスケジュールするすべてのノードに伝播します。各コンポーネントをその露出に対応付けることで、このガイドのハードニングコントロールがどこに適用されるかを正確に把握できます。

ビルドからランタイムまでのライフサイクル全体でKubernetes Securityがどのように機能するか

Kubernetesは、一時点のチェックではなく継続的なワークフローを通じて保護します。各フェーズは異なるカテゴリのコントロールを適用し、あるフェーズの出力が次のフェーズの入力になります。各ステップで何が起こるかを以下に示します。

1. ビルド時: 既知の脆弱性についてcontainer imageをスキャンし、IaCテンプレートをポリシーに照らして検証し、イメージに暗号学的署名を行い、software bill of materials (SBOM)を生成します。これらの予防的コントロールは、どのartifactもスケジュールされる前に、問題を発生源で止めます。
2. デプロイと設定: ワークロードを送信すると、admission controllerがスケジューリング前にポリシーに照らして評価します。RBACは、誰がリソースを作成、変更、読み取りできるかを決定し、network policyはどのpod同士が通信できるかを定義します。ビルド時に署名したイメージも、admission controlが実際に署名を検証して初めてここで保護されます。
3. コントロールプレーンとノードの設定: API server、etcd、kubelet、node OSを設定して、露出する範囲を減らします。認証、認可、暗号化は、他のすべてのフェーズが依存する信頼境界を設定するため、弱いコントロールプレーンは下流のすべてを弱体化させます。
4. ランタイム: 監視ツールは、実行中ワークロードにおける振る舞いの異常、設定ドリフト、既知の攻撃パターンを監視し、seccompおよびAppArmorプロファイルはコンテナが実行できるシステムコールを制限します。ランタイムは、ビルドとデプロイで見逃したギャップを検出する場所でもあります。

ランタイムの検出結果を、更新済みイメージ、更新済みIaC、更新済みadmission policyとしてビルドフェーズにフィードバックすると、このループは閉じます。このライフサイクルは、すべての引き継ぎが維持されて初めて機能します。1つの引き継ぎ失敗が何をもたらすかを以下に示します。

侵害されたKubernetesクラスターの影響

クラスターが侵害されると、その影響は単一のワークロードをはるかに超えて広がります。

• ラテラルムーブメントと影響範囲: クラスターでは、ネットワーク接続を共有する数十から数千のpodが稼働しています。RBACが過剰権限で、network policyが存在しない場合、1つのpodにアクセスした攻撃者はnamespaceやノードをまたいで横方向に移動できます。
• Secretの露出: etcdには、APIキー、データベース認証情報、TLS証明書、サービストークンが保持されています。Secretはデフォルトで暗号化されていないため、etcdへの読み取りアクセスを持つ攻撃者は、クラスター内のすべての認証情報を抽出できます。
• サプライチェーン伝播: 継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインを通じてデプロイされた汚染済みcontainer imageは、それをスケジュールするすべてのノードに到達します。数百のレプリカを実行するクラスターでは、1つの侵害されたイメージが数分以内にインフラ全体で悪意あるコードを実行する可能性があります。
• ワークロードとデータの侵害: 本番データベース、顧客向けアプリケーション、内部サービスは並行して稼働しています。1つのワークロードでの侵害が、機密データの露出、サービス可用性の低下、または将来の攻撃に向けた永続化につながる可能性があります。
• コンプライアンスおよび規制上の露出: クラスターが決済データ、医療記録、政府系ワークロードを処理する場合、PCI DSS、HIPAA、FedRAMP、およびSOC 2要件の対象になります。監査に不合格となる設定ミスのあるクラスターは、業務停止や金銭的な罰則につながる可能性があります。

ハードニングは、単一の侵害による影響範囲を縮小し、 incident responseのタイムラインを短縮し、コンプライアンスプログラムが必要とする監査証跡を生み出します。これを実運用で達成するのは、Kubernetesの動作特性に起因する理由から、見た目以上に困難です。

Kubernetesの保護における課題

Kubernetes securityは、最も経験豊富なチームメンバーにとっても運用上困難です。このプラットフォームのエフェメラル性、宣言的設定モデル、分散アーキテクチャは、静的なセキュリティツールが対処するよう設計されていない摩擦を生み出します。

• エフェメラルで絶えず変化するワークロード: Podは継続的に作成、破棄、再スケジュールされます。午前9時時点のクラスターのpostureスナップショットは、午前9時5分の状態を反映していない可能性があります。
• 実行中コンテナに対する可視性ギャップ: コンテナはホストカーネルを共有しつつ、プロセス、ファイルシステム、ネットワークスタックを分離します。標準的なホストベース監視ツールは、通常のコンテナ動作と悪意ある活動を区別するためのコンテキストを欠くことがよくあります。
• 設定の複雑さとドリフト: 本番クラスターには、数百のYAMLマニフェスト、RBACバインディング、admissionルールが関与します。Gitで宣言した内容とクラスターで実行されている内容の間のドリフトは、追跡されない露出を生みます。
• マルチクラスターおよびマルチクラウドのスプロール: Amazon Web Services (AWS)、Azure、Google Cloud Platform (GCP)、オンプレミス環境にまたがってクラスターを実行する場合、それぞれ独自の共有責任境界を持つ異なるマネージドサービス全体で、一貫したポリシーを適用しなければなりません。
• 断片化したツール群: イメージスキャン、RBAC管理、network policy適用、ランタイム監視、コンプライアンスレポートには、共有データモデルを持たない別々のツールが必要になることがよくあります。アラート相関は利用者側の責任です。
• スキルと組織上の摩擦: 専門スキルは不足しており、2025年のCNCF調査では、クラウドネイティブ採用の最大の障壁が初めて技術的要因ではなく組織的要因、すなわち社内コミュニケーション、チームダイナミクス、リーダーシップの整合性であることが判明しました。誰も所有していないため、コントロールが適用されないのです。

これらの制約は、ツール選定と採用優先順位の両方を形作り、同じミスがクラスター間で繰り返される理由を説明します。

よくあるKubernetes Securityのミス

特定の運用者アンチパターンが、攻撃者に悪用される露出を生み出します。クラスター内で以下の各項目を特定し、排除してください。

• 特権コンテナまたはrootコンテナを実行すること。 特権コンテナは、Linuxカーネルの分離をすべて回避します。rootとして実行され、allowPrivilegeEscalation: trueが設定されたコンテナは、ホストへエスケープする可能性があります。
• cluster-adminまたはワイルドカードRBACを付与すること。ワイルドカード権限(resources: ["*"], verbs: ["*"])は、まだ存在しないAPIリソースにも自動的に拡張されます。Kubernetesドキュメントでは、このパターンを「DO NOT USE」としています。
• default-allowネットワーキングをそのままにすること。NetworkPolicyオブジェクトがなければ、異なるnamespace内のpodは自由に通信できます。
• Secretを平文マニフェストに保存すること。 認証情報をGitにコミットしたり、環境変数として渡したりすると、クラッシュダンプ、ログ、シェル履歴で露出します。
• イメージおよびIaCスキャンを省略すること。 スキャンされていないイメージをデプロイすると、脆弱性が未検証のまま本番環境に到達します。
• ハードニングを一度きりのゲートとして扱うこと。 ブートストラップ時にハードニングされたクラスターも、チームがワークロードを追加し設定を変更するにつれてドリフトします。継続的な適用がなければ、postureは劣化します。
• ノードおよびコントロールプレーンの設定を無視すること。 匿名APIサーバーログインを有効のままにすること、etcd暗号化を省略すること、監査ログを欠落させることは、明示的な是正を必要とするデフォルト状態です。

これらはすべて、以下のプラクティスで修正可能です。クラスターに追加のワークロードをスケールさせる前に解消すべき露出のチェックリストとして扱ってください。

Kubernetes Securityのベストプラクティス

これらのKubernetes security best practicesは、 Kubernetes cluster hardeningの運用上の中核を成し、前述の同じ4つのライフサイクルフェーズごとに整理されています。各フェーズは前のフェーズが成立していることを前提とするため、順番に進めてください。

ビルドフェーズの保護

1. 脆弱性についてイメージをスキャンする。レジストリに到達する前に実施します。 container image scanningをCIパイプラインに統合し、脆弱なイメージがデプロイ可能なartifactにならないようにします。
2. 最小またはdistrolessのベースイメージを使用する。 Distrolessイメージには、アプリケーションとそのランタイム依存関係のみが含まれ、シェル、パッケージマネージャー、不必要なバイナリは含まれません。イメージは明示的なバージョンサフィックス(e.g., gcr.io/distroless/static-debian13)に固定し、latest tagは決して使用しないでください。
3. イメージに署名し、検証する。 CIでCosignまたはNotaryを使用してイメージに署名します。デプロイ時に署名されていない、または検証されていないイメージを拒否するようadmission controllerを設定してください。
4. IaCおよびKubernetesマニフェストをスキャンする。 Terraform、Helm chart、raw YAMLを、クラスターに到達する前にセキュリティポリシーに照らして検証します。
5. SBOMを生成する。すべてのイメージに対して生成し、来歴を確立するとともに、デプロイ後の脆弱性追跡を支援します。
6. シークレットをイメージに含めない。 認証情報、APIキー、証明書をcontainer imageやDockerfileに埋め込んではいけません。

これらのビルドフェーズのコントロールは、脆弱または未署名のartifactが実行される前にパイプラインから排除します。これらを通過したイメージも、クラスターが正しく受け入れて初めて安全であり、そこでデプロイ時設定が引き継ぎます。

クラスター設定とデプロイのハードニング

これらのKubernetes RBAC best practicesとネットワークコントロールは、デプロイ時ポリシーを強制されたガードレールへと変えます。

1. 最小権限のRBACを適用する。 明示的なverbとresource名を持つnamespaceスコープのRoleを作成します。ワイルドカード付与を排除してください。cluster-adminは緊急時用途に限定します。APIアクセスを必要としないservice accountにはautomountServiceAccountToken: falseを設定してください。

2. default-denyのnetwork policyを適用する。 ブートストラップ時に、すべてのnamespaceへ、ingressとegressの両方に対してdefault-deny-all Netwenforce mode with the restrictedorkPolicyを適用します。DNSのegress例外としてUDPポート53を含め、ワークロードごとに明示的な許可ルールを追加してください。

3. Restricted Pod Security Standardを適用する。 本番namespaceでは、Pod Security Admissionをenforceモードかつrestricted levelで使用します。これにより、特権コンテナをブロックし、runAsNonRootを要求し、seccompプロファイルを必須化し、ボリュームタイプを制限します。

4. OPA GatekeeperまたはKyvernoでadmission controlを追加する。 readOnlyRootFilesystem: true, allowPrivilegeEscalation: false、イメージレジストリの許可リスト、capability drop-ALLポリシーを適用します。既存ワークロードを監査するため、denyへ切り替える前にまずdryrunモードを使用してください。

5. etcdの保存時暗号化とともに、外部ストアでSecretを管理する。 エンベロープ暗号化にはkey management service (KMS) v2 providerを使用し、Secrets Store CSI Driver経由でSecretをボリュームとしてマウントします。これはtmpfsを使用するため、secretデータがノードディスクに到達しません。Secretを環境変数として渡すことは避けてください。

6. リソース制限を設定する。リソース枯渇を防ぐため、すべてのコンテナにCPUとメモリのrequestおよびlimitを定義します。

デプロイ時ポリシーが適用されると、ワークロードは最小権限とdefault-denyネットワーキングの下で実行されます。これらのガードレールが依存する信頼は、依然としてコントロールプレーンとその下のノードにあるため、次にそれらをハードニングします。

コントロールプレーンとワーカーノードの保護

コントロールプレーンは、1つの弱い設定が他のすべてに影響する唯一の場所です。以下の各項目を設定し、ブートストラップ時に一度だけではなく、定期的に検証してください。

ハードニング手順	設定内容	ソース
API server access	強力な認証と相互TLSを必須化し、API serverをパブリックインターネットから切り離す。	CIS Benchmark
Anonymous auth	--anonymous-auth=false を設定する	CISA/NSA guidance
Audit logging	API監査、メトリクス、アプリケーション、seccompログを有効化し、それらをクラスター外に集約してアラート化する	CISA/NSA guidance
etcd	保存時暗号化を有効にし、相互TLSを必須化し、API serverのみが到達できるファイアウォールの背後に分離する	CIS Benchmark
kubelet	APIアクセスを制限し、read-onlyポートを無効化し、ノードレベル設定を適用する	CIS Benchmark
Node baseline	使用中リリース向けのCIS Kubernetes Benchmarkにコントロールプレーン、etcd、ノードを整合させ、継続的な頻度でスキャンする	CIS Benchmark
Versions	Kubernetes、node OS、container runtimeを定期的な頻度でパッチ適用する	—

コントロールプレーンをロックダウンし、ノードにパッチを適用すれば、基盤は安定します。それでもライブワークロードは宣言状態からドリフトしたり、内部から攻撃を受けたりする可能性があり、それを検出するのがランタイムコントロールです。

ランタイムセキュリティと脅威検知

強力なKubernetes runtime securityは、静的コントロールでは検出できないものを捉えます。

1. ランタイムの振る舞いを監視する。 異常なsyscall、予期しないプロセス実行、ネットワーク接続、ファイル変更を監視するコンテナネイティブなランタイムセキュリティツールを導入します。NIST SP 800-190は、従来のintrusion prevention system (IPS) およびweb application firewall (WAF) ツールはコンテナに適した保護を提供しないと述べています。
2. 設定ドリフトを検出する。 実行中ワークロードをGit内の宣言状態と比較します。元のイメージまたは設定から逸脱したコンテナをフラグ付けしてください。
3. seccompおよびAppArmorまたはSELinuxプロファイルを適用する。 少なくともRuntimeDefault seccompプロファイルを使用します。まず一部ノードでカスタムプロファイルを展開し、検証後にクラスター全体へ拡大してください。
4. read-only root filesystemを実行し、不必要なcapabilityを削除する。 すべての本番コンテナにreadOnlyRootFilesystem: trueおよびcapabilities: drop: [ALL]を設定します。
5. runAsNonRootを強制する。 pod security contextでrunAsNonRoot: trueを必須化します。デプロイ時オーバーライドのみに依存するのではなく、ビルド時に非rootユーザーとして実行するようイメージを構築してください。
6. 自律応答と継続的な監査ログを有効化する。 ランタイムアラートを監査ログと相関させて攻撃タイムラインを再構築します。検出結果をビルド時ポリシーへフィードバックし、ループを閉じてください。

これら4つのフェーズを組み合わせることで、継続的にハードニングされたクラスターが実現します。業界ベンチマークは、各フェーズで「正しく設定されている」状態を定義しており、クラスターをそれらに照らして測定すべきです。

Kubernetes Securityの標準とコンプライアンス

業界で認知されたベンチマークは、上記のプラクティスを運用可能な形にし、Kubernetesコンプライアンスプログラムに必要な監査証跡を提供します。

標準	対象範囲	関連性
CIS Kubernetes Benchmark	コントロールプレーン、etcd、ワーカーノード、ポリシー	PCI DSS、FedRAMP、SOC 2、FISMA、およびNIST National Checklist Programで認知
CISA/NSA Kubernetes Hardening Guidance	ビルド、デプロイ、ネットワーク、RBAC、ログ、ランタイム	連邦政府および重要インフラクラスター向けの権威ある政府ベースライン
Pod Security Standards	3つの階層にわたるpodレベルの権限制限	Kubernetes組み込みの適用メカニズム。CISA/NSA guidance Table Iに直接対応
NIST SP 800-190	コンテナライフサイクルセキュリティ	コンテナコントロールをNIST SP 800-53 Rev 5 (AU-2, CM-2, SC-7, IR-4, and others) に対応付け

Kubernetesがデフォルトの本番プラットフォームとなった今、コンプライアンスフレームワークは、Kubernetes固有のコントロールを一般的なインフラセキュリティの一部ではなく、独立した監査領域として扱う傾向を強めています。 

CIS GKE BenchmarkやCIS OpenShift Benchmarkのようなプラットフォーム固有ベンチマークは、マネージドサービス固有のコントロールで一般ベンチマークを拡張します。標準を理解することはベースラインです。より難しい問いは、Kubernetes Securityが次にどこへ向かうかです。

Kubernetes Securityの今後のトレンド

今日導入するコントロールは変化する土台の上にあり、3つのトレンドがチームによるKubernetes security best practicesへの取り組み方を再形成しています。

1. AIワークロードが攻撃対象領域を移動させる。 クラスターがAIおよび機械学習ワークロードのデフォルトの実行基盤になるにつれ、GPUスケジューリング、モデルartifact、大規模トレーニングデータセットが新たな標的になります。データとモデルのサプライチェーン保護は、別個の懸念ではなく、クラスターのハードニングの一部になりつつあります。
2. ソフトウェアサプライチェーンの完全性が必須になる。SBOM生成、署名済みartifact、来歴証明は、規制産業や政府調達において、任意の成熟度指標からベースライン要件へと移行しています。
3. 自律的なランタイム防御が手動トリアージに取って代わる。 クラスター活動の量と速度は、人手によるレビューを上回ります。通常のワークロード活動と異常を区別し、アナリストを待たずに応答するBehavioral AIは、差別化要素からデフォルトへと移行しつつあります。

これらの各トレンドは同じ方向を指しています。ライフサイクルのより早い段階での自動化の強化と、ランタイムでの自律性の向上であり、そこにプラットフォームツールの価値があります。

SentinelOneでKubernetes Securityを強化

このガイドで扱ったKubernetesネイティブのコントロール、RBAC、NetworkPolicy、Pod Security Standards、etcd暗号化、監査ログは、クラスターのハードニングの基盤を形成します。SentinelOneはその上に、posture management、supply-chain scanning、K8s admission control、runtime threat detectionを追加し、それぞれがこのガイドで挙げた弱点に対応します。

Singularity Cloud Securityは、Kubernetesクラスターが実行される前にスキャンします。ビルド時スキャンは、CI/CDパイプライン、バージョン管理システム、コンテナレジストリと直接統合されます。既知の脆弱性と750種類を超える露出したシークレットをチェックします。同じスキャンは、Terraform、Helm、CloudFormation、Kubernetes YAMLを含むinfrastructure-ascodeテンプレートも対象とし、ポリシー違反を早期に検出します。Kubernetes Admission ControllerはAPI serverにおける最終ゲートキーパーとして機能し、未承認または既知の悪意あるイメージがデプロイされる前にブロックします。

Kubernetes Security Posture Management (KSPM) は、クラスター全体の可視性ギャップを埋めます。クラスター、ノード、namespace、deployment全体にわたる統合インベントリを構築し、過度に許容的なアクセスやリスクの高い設定を可視化します。次にOffensive Security Engine™が実際の攻撃をシミュレートし、Verified Exploit Paths™を通じて、攻撃者が実際に到達可能な設定ミスを確認します。セキュリティチームは、すべての検出結果をトリアージする代わりに、悪用可能なものを優先できます。同じルールエンジンがAdmission Controllerも支えるため、ポリシーはpostureからデプロイまで一貫します。

ランタイムでは、extended Berkeley Packet Filter (eBPF) 上に構築されたSingularity Cloud Workload Securityが、マシンスピードで異常な振る舞いを検出します。自動応答により、アナリストを待たずに悪意あるプロセスを停止し、感染ファイルを隔離します。Graph ExplorerはKubernetesの攻撃対象領域全体の関係性を可視化するため、チームは何が露出しているかを正確に把握できます。ランタイム検知が悪意あるイメージをフラグ付けすると、その検出結果は自動的にAdmission Controllerへフィードバックされます。その後、そのイメージは将来のすべてのデプロイでブロックされ、1回の検知が永続的なポリシーになります。Purple AIは、1つのデータレイク上のクラウドワークロードテレメトリに対して、自然言語による threat huntingとイベント要約を提供するため、アナリストはツール間を行き来する代わりに平易な言葉でクエリできます。

本番環境でクラスターのどこが露出しているかを確認してください。 SentinelOneのデモをリクエストして、自社環境でのKubernetes posture managementとruntime threat detectionをご確認ください。

ツアーを見る

サーバー、VM、コンテナ向けのAI搭載クラウドワークロード保護（CWPP）。実行時の脅威をリアルタイムで検知・阻止します。

主なポイント

Kubernetesは緩いデフォルト設定で提供されるため、クラスターセキュリティは利用者の手に委ねられます。このガイドのKubernetes security best practicesは4つのフェーズにまたがります。ビルド時のイメージスキャンと署名、デプロイ時のRBACとNetworkPolicy、コントロールプレーンでのetcd暗号化と監査ログ、そしてランタイムでの振る舞い監視です。 

設定をCIS BenchmarkおよびCISA/NSA guidanceに整合させ、上記で特定した一般的なミスを排除し、ランタイムの検出結果をビルド時ポリシーへフィードバックしてループを閉じてください。そこまで到達すれば、推測は不要になります。どのnamespaceについても、どの日であっても、何が適用され、何がドリフトし、それに対して何を行ったかを示せるようになります。

よくある質問

デフォルトで安全でないKubernetes設定はどれですか？

すべての新しいKubernetesクラスターには、3つの設定が安全でない状態で含まれています。CISA/NSA Kubernetes Hardening Guidance v1.2では、それらとして次を文書化しています: 匿名でのAPIサーバーログインが有効、Secretsがetcdに暗号化されずに保存される、監査ログが無効になっている、の3点です。 

NetworkPolicyオブジェクトがなければ、Pod間通信は無制限です。これらは自分でハードニングする必要があります。共有責任モデルの下では、クラウドプロバイダーもKubernetesディストリビューションも、これらの制御を自動的に適用してはくれません。

Kubernetesセキュリティとコンテナセキュリティの違いは何ですか？

コンテナセキュリティとKubernetesセキュリティは、同じスタックの異なるレイヤーで機能します。コンテナセキュリティは、イメージとコンテナインスタンスに重点を置きます。具体的には、脆弱性スキャン、ランタイム分離、ケーパビリティの削減、ホストカーネルの保護です。 

Kubernetesセキュリティは、個々のコンテナとそれらを取り巻くクラスターの両方にまたがり、RBAC、アドミッション制御、ネットワークポリシー、etcd、オーケストレーションの監査ログを追加します。コンテナセキュリティは、より広範なKubernetesセキュリティ分野の一部です。

Pod Security Standardsは、非推奨となったPod Security Policiesとどのような関係がありますか？

Pod Security Policies (PSPs) はKubernetes v1.21で非推奨となり、v1.25で削除されました。Pod Security Standards (PSS) は3つのポリシーティア（Privileged、Baseline、Restricted）を定義し、ラベルを介して名前空間レベルでポリシーを適用する組み込みのアドミッションコントローラーであるPod Security Admission (PSA) によって強制されます。 

PSAはv1.25で安定版になりました。クラスターがv1.25以降で稼働していて、PSAを設定していない場合、Podレベルの強制レイヤーなしで運用していることになります。

Kubernetesクラスターにはどのコンプライアンスベンチマークが適用されますか？

Kubernetesクラスターには、4つの主要なコンプライアンスフレームワークが適用されます。CIS Kubernetes Benchmark は、PCI DSS、FedRAMP、SOC 2、および FISMA によって認識されています。CISA/NSA Kubernetes Hardening Guidance は、政府のベースラインとして機能します。 

NIST SP 800-190 は、コンテナのコントロールを NIST SP 800-53 Rev 5 のコントロールファミリーにマッピングします。Pod Security Standards は、CISA/NSA ガイダンスに直接対応する組み込みの強制適用メカニズムを提供します。

EKS、AKS、GKEのようなマネージドサービスは、クラスターセキュリティを代わりに処理してくれますか？

マネージド Kubernetes サービスは、コントロールプレーンの可用性、パッチ適用、および一部のインフラストラクチャ セキュリティを担います。RBAC ポリシー、NetworkPolicy オブジェクト、Pod Security Admission、Secrets の暗号化、およびランタイム監視については、引き続きお客様の責任です。 

責任共有モデルが適用されます。プロバイダーはコントロールプレーンのインフラストラクチャを保護し、お客様はワークロード、構成、およびアクセス制御を保護します。プラットフォーム固有の CIS Benchmarks には、各マネージド サービスで適用すべき追加のコントロールが記載されています。