プレイブック

業界標準のセキュリティベストプラクティスに対してクラスター設定を評価します。

→`kube-bench`を使用して、コントロールプレーンとワーカーノードに対してCIS Kubernetes Benchmarkチェックを実行します。

理由: `kube-bench`は、この特定のタスクの標準ツールであり、包括的なCISガイドラインに対するチェックを自動化します。

リファレンス↗

すべてのAPIサーバーリクエストに対して強力な認証を強制します。

→`kube-apiserver`フラグを設定します: `--anonymous-auth=false`で未認証のリクエストを拒否し、`--client-ca-file`でクライアント証明書検証 (mTLS) を強制します。

理由: これらのフラグは、匿名アクセスを排除し、APIサーバーとの認証済みで暗号化された通信を強制するための基本的な制御です。

リファレンス↗

クラスターのetcdステートストアを不正アクセスおよびデータ盗難から保護します。

→すべてのクライアントおよびピア通信 (`--cert-file`, `--key-file`, `--peer-cert-file`) にmTLSを使用してetcdを設定します。APIサーバーの`--encryption-provider-config`フラグを介して、保存中のシークレットの暗号化を有効にします。

理由: etcdにはすべてのクラスターシークレットが含まれています。etcdノードが侵害された場合でも機密情報を保護するためには、転送中 (mTLS) および保存中のデータを暗号化することが不可欠です。

リファレンス↗

etcdの保存中の暗号化キーをゼロダウンタイムでローテーションします。

→1. 新しいキーを`EncryptionConfiguration`ファイルの最初のエントリとして追加します。 2. すべてのAPIサーバーを再起動します。 3. すべてのシークレットの再暗号化を強制します (`kubectl get secrets -A -o json | kubectl replace -f -`)。 4. 検証後、設定から古いキーを削除し、APIサーバーを再度再起動します。

理由: 設定の変更は新しい書き込みにのみ影響します。既存のデータは新しいキーで暗号化するために書き換えられる必要があります。古いキーを時期尚早に削除すると、データにアクセスできなくなります。

名前空間内でゼロトラストネットワークモデルを実装します。

→`podSelector: {}`と`policyTypes: [Ingress, Egress]`が空で、`ingress`または`egress`ルールがない`NetworkPolicy`を適用します。これにより、すべてのPodが選択され、すべてのトラフィックが拒否されます。

理由: このポリシーは「すべて拒否」のベースラインを確立し、必要なすべての通信に対して明示的な「許可」ルールを強制します。これはゼロトラストネットワークの基盤です。

リファレンス↗

Egress NetworkPoliciesがPodのDNS解決をブロックしています。

→クラスターDNSサービスへのトラフィックを許可する特定のエグレスルールを追加します。UDPおよびTCPプロトコルの両方でポート53へのエグレスを許可します。可能であれば、`namespaceSelector`と`podSelector`を介してkube-dns Podを選択します。

理由: NetworkPoliciesは細かく設定されます。IPブロックへの一般的なエグレスルールでは、DNSに必要な特定のプロトコル (UDP) がカバーされない可能性があり、解決の失敗につながります。

Ingress経由で公開されるサービスへの外部アクセスを保護します。

→`tls`セクションを追加してIngressリソースを設定します。このセクションは`kubernetes.io/tls`タイプのKubernetes Secretを参照します。SecretにはTLS証明書と秘密鍵が含まれている必要があります。

理由: これにより、TLS終端がIngressコントローラーで一元化され、クライアントからクラスター境界へのトラフィックが暗号化され、バックエンドサービスの証明書管理が簡素化されます。

ユーザーまたはアプリケーションに、必要最小限の権限のみを付与します。

→可能な限り、名前空間スコープの`Roles`と`RoleBindings`を使用します。`verbs`または`resources`で`cluster-admin`やワイルドカード (`"*"`) を避けます。`["pods"]`に対して`["get", "list"]`のような特定の権限を付与します。

理由: これにより、アカウントやトークンが侵害された場合の被害範囲を最小限に抑え、横移動や権限昇格を防ぎます。

リファレンス↗

Kubernetes APIと対話する必要がないPodの攻撃対象領域を削減します。

→ServiceAccountまたはPodのspecで`automountServiceAccountToken: false`を設定することにより、サービスアカウントトークンの自動マウントを無効にします。

理由: Podが侵害された場合でも、攻撃者はマウントされたトークンを利用してAPIサーバーにアクセスすることはできず、侵害されたPodを起点とするクラスターレベルの攻撃を防ぎます。

特定のユーザーまたはサービスアカウントがアクションを実行する権限を持っているかを確認します。

→`kubectl auth can-i <verb> <resource> --as=<user>`または`kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<ns>:<sa-name>`を使用します。

理由: このコマンドは、すべてのRoleとBindingを手動で解析することなく、有効な権限を正確にチェックするための偽装を可能にします。

コントロールプレーンおよびkubelet証明書を定期的にローテーションして、クラスターセキュリティを維持します。

→kubeadmクラスターの場合、`kubeadm certs renew all`を使用します。その他の場合、文書化された手動または自動ローテーション手順に従います。kubeletの構成を介して、kubeletクライアント/サーバー証明書のローテーションを有効にします。

理由: 定期的なローテーションは、攻撃者が侵害された証明書を使用できる時間枠を制限します。これは重要なセキュリティ衛生慣行です。

リファレンス↗

ワーカーノードが侵害されている疑いがあり、直ちに隔離する必要があります。

→まず、`kubectl cordon <node-name>`を使用して新しいPodがスケジュールされないようにします。次に、`kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data`を使用して、実行中のワークロードを安全に退避させます。

理由: cordonとdrainは、サービスからノードを削除するための標準的な非破壊的な手順であり、ワークロードを別の場所に再スケジュールすることを可能にしながら、侵害されたノードをフォレンジック分析のために保持します。

コンテナがホストカーネルに対して実行できるシステムコールを制限します。

→Podまたはコンテナの`securityContext`で、安全なベースラインとして`seccompProfile.type`を`RuntimeDefault`に設定するか、より厳格な制御のためにカスタム定義されたJSONプロファイルへのパスを持つ`Localhost`に設定します。

理由: Seccompは、コンテナ内からカーネルの攻撃対象領域を削減し、未使用または危険なシステムコールをブロックすることで、カーネルの脆弱性に対する悪用を防ぎます。

リファレンス↗

ファイル、ネットワーク機能、その他のリソースへのアクセスを制限することにより、コンテナプロセスを隔離します。

→アノテーション`container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>`を介して、コンテナにAppArmorプロファイルを適用します。プロファイルはノードに事前にロードされている必要があります。

理由: AppArmorは強制アクセス制御 (MAC) を提供し、侵害されたアプリケーションを封じ込め、不正なリソースへのアクセスを防ぐための重要な多層防御を追加します。

リファレンス↗

コンテナがrootとして実行されずに特定の特権操作 (例: ポート80へのバインド) を必要とします。

→`securityContext.capabilities`で、`drop: ["ALL"]`を設定し、次に`add: ["NET_BIND_SERVICE"]`を設定します。

理由: これは、rootとして実行する広範な権限を避け、必要な特定のLinux機能のみを付与することで、最小特権の原則に従います。

コンテナがホストシステムへのフルアクセスを取得するのを防ぎます。

→`securityContext.privileged: false` (デフォルトです) を設定します。Pod Security StandardsまたはOPA/Kyvernoを使用して、これをクラスター全体で強制します。

理由: 特権コンテナは、ほぼすべてのホスト機能とデバイスアクセスを持っており、事実上コンテナの隔離を無効にします。これはコンテナエスケープの主要な経路です。

名前空間レベルでPodのベースラインまたは厳格なセキュリティ設定を強制します。

→名前空間にラベルを適用します。例: `pod-security.kubernetes.io/enforce: restricted`。モードは`enforce`、`audit`、`warn`です。

理由: Pod Security Standards (PSS) は、非推奨となったPodSecurityPolicyに代わる組み込みの多段階セキュリティポリシーを提供し、セキュリティのベストプラクティスを簡単に強制できるようにします。

リファレンス↗

複数のセキュリティ制御を同時に適用してPodを強化します。

→`runAsNonRoot: true`、`allowPrivilegeEscalation: false`、および`readOnlyRootFilesystem: true`を組み合わせた`securityContext`を設定します。

理由: この多層防御アプローチは、root実行の防止、特権昇格ベクトル (setuidなど) のブロック、コンテナファイルシステムの不変性の確保という複数の保護層を重ねます。

標準コンテナよりも強力な隔離で、信頼できないワークロードやマルチテナントワークロードを実行します。

→サンドボックス型ランタイムハンドラー (例: gVisor、Kata Containers) を指す`RuntimeClass`リソースを定義します。`spec.runtimeClassName`を使用してPodをそれに割り当てます。

理由: サンドボックス型ランタイムは、ユーザー空間カーネルまたは軽量VMを使用してシステムコールを傍受し、コンテナとホストカーネル間の追加の隔離層を提供します。

リファレンス↗

標準のKubernetes制御ではカバーされない、複雑なカスタムセキュリティポリシーを強制します。

→OPA Gatekeeperをデプロイします。`ConstraintTemplate` (Regoロジック) を使用してポリシーを定義し、`Constraint`リソースで適用します。

理由: GatekeeperはバリデートアドミッションWebhookとして機能し、特定のラベルの要求、ホストパスの不許可、リソース制限の強制など、任意のルールを強制できます。

リファレンス↗

最も安全な方法でPodにシークレットを提供します。

→シークレットをファイルとしてボリュームにマウントします。さらに高いセキュリティのために、secrets-store CSIドライバーを使用して、外部のVault (例: HashiCorp Vault、AWS Secrets Manager) からシークレットをPodに直接マウントします。

理由: ファイルとしてマウントすることは、環境変数 (ログに記録されたり公開されたりする可能性がある) よりも安全です。CSIドライバーは、シークレットをetcdにまったく保存しないようにします。

すべてのPod間ネットワークトラフィックを自動的に暗号化および認証します。

→IstioやLinkerdのようなサービスメッシュをデプロイします。メッシュは各Podにサイドカープロキシを注入し、mTLS暗号化、認証、ポリシー適用を処理します。

理由: サービスメッシュは、アプリケーションコードの変更を必要とせずに透過的なゼロトラストネットワークを提供し、すべての内部サービス通信を保護します。

既知の脆弱性 (CVE) を持つコンテナイメージのデプロイを防止します。

→TrivyやGrypeのようなスキャナーをCI/CDパイプラインに統合します。脆弱性が定義された重大度しきい値 (例: HIGHまたはCRITICAL) を超えた場合、ビルドを失敗させます。

理由: この「シフトレフト」アプローチは、脆弱性が本番環境に到達する前に早期に発見し、実行中のアプリケーションの攻撃対象領域を大幅に削減します。

リファレンス↗

信頼され、変更されていないコンテナイメージのみがクラスターにデプロイされることを保証します。

→CIビルドプロセス中に`cosign`でイメージに署名します。ポリシーエンジン (Kyverno、OPA Gatekeeper) をアドミッションコントローラーとして使用し、Podが作成される前に公開鍵に対して署名を検証します。

理由: 暗号署名は、イメージの整合性 (改ざんされていないこと) と信頼性 (信頼できるソースからのものであること) を強力に保証します。

リファレンス↗

コンテナイメージ自体の内部の攻撃対象領域を最小化します。

→最小限のベースイメージ (例: distroless、Alpine) を使用します。マルチステージDockerfileを使用してビルドツールを破棄します。`USER`命令で非rootユーザーを設定します。`.dockerignore`を使用して機密ファイルを除外します。

理由: 最小限のイメージは、含まれるパッケージやツールが少なく、潜在的な脆弱性が少なく、コンテナが侵害された場合に攻撃者が足がかりを得るのをより困難にします。

デプロイされるすべてのイメージが組織のプライベートレジストリから取得される必要があるというポリシーを強制します。

→アドミッションコントローラー (OPA GatekeeperやKyvernoなど) を使用して、すべてのコンテナスペックの`image`フィールドをレジストリホスト名の許可リストに対して検証するポリシーを作成します。

理由: これにより、開発者がDocker Hubのような公開リポジトリから信頼できない、またはスキャンされていないイメージをプルするのを防ぎ、すべてのコードが内部のセキュリティチェックを通過したことを保証します。

コンテナイメージ内のすべてのソフトウェアコンポーネントと依存関係のインベントリを維持します。

→`Syft`のようなツールをCI/CDパイプラインに統合し、SPDXやCycloneDXのような標準形式でソフトウェア部品表 (SBOM) を生成します。

理由: SBOMはサプライチェーンセキュリティにとって不可欠であり、依存関係に新しい脆弱性が発見された場合に、影響を受けるすべての資産を迅速に特定できるようにします。

Kubernetes YAMLマニフェストが適用される前に、セキュリティ設定ミスを特定します。

→CIパイプラインで、`trivy config`や`kubesec`のようなツールを使用して、Kubernetesマニフェストファイルに、rootでの実行、特権昇格の許可、機密ホストパスのマウントなどの危険な設定がないかをスキャンします。

理由: この事前チェックにより、インフラストラクチャ・アズ・コードのセキュリティ問題を、実行中のクラスターで脆弱性を生み出す前に発見できます。

実行中のコンテナ内またはクラスターノード上での疑わしいアクティビティを検出してアラートを発します。

→FalcoをDaemonSetとしてデプロイします。FalcoはeBPFまたはカーネルモジュールを使用してシステムコールを監視し、そのルールセット (例: コンテナ内のシェル、予期しないネットワーク接続) に基づいて異常な動作を警告します。

理由: Falcoはランタイム動作へのリアルタイムの可視性を提供し、静的スキャンでは検出できないコンテナエスケープ、クリプトマイニング、データ流出などの脅威の検出を可能にします。

リファレンス↗

デフォルトのFalcoルールが誤検出を多発しています。

→カスタムのFalcoルールファイルを作成して、デフォルトのルールを上書きします。ルール条件に例外を追加し、特定のプロセスやコンテナイメージ (例: `and not container.image.repository contains "debug"`) のような既知の正常な動作を除外します。

理由: ルールのチューニングは、ランタイムセキュリティを運用化するために不可欠です。ノイズを減らすことで、セキュリティチームは実用的で優先度の高いアラートに集中できます。

Kubernetes APIに対して行われたすべてのアクションの、時系列で不変のログを記録します。

→`--audit-policy-file`および`--audit-log-path`フラグを提供することで、`kube-apiserver`で監査ロギングを有効にします。ポリシーを構成して、何をどのレベルでログに記録するかを定義します。

理由: 監査ログは、セキュリティ分析、インシデント調査、およびコンプライアンスにとって不可欠です。それらは、誰が何をいつ行ったかを示す決定的な記録を提供します。

リファレンス↗

シークレットの内容自体をログに記録せずに、Secretsのような機密リソースへのアクセスを監査します。

→Secretsの監査ポリシールールを`level: Metadata`を使用するように設定します。これにより、ユーザー、タイムスタンプ、リソース、および動詞がログに記録されますが、リクエストおよびレスポンスの本文は省略されます。

理由: これにより、機密データを監査ログに書き込むことによって新たなセキュリティリスクを生じさせることなく、誰がシークレットにアクセスしているかについて説明責任が提供されます。

すべてのクラスターコンポーネントおよびアプリケーションからのログを集約し、一元的な分析のために使用します。

→ログ収集エージェント (例: Fluentd、Vector) をDaemonSetとしてデプロイし、ノードからログを収集して、集中型SIEMまたはログ管理システム (例: Elasticsearch、Splunk) に転送します。

理由: 一元化されたロギングは、インシデント調査中にクラスター全体のイベントを関連付けるため、およびコンプライアンスのための長期記録を維持するために不可欠です。

Falcoのセキュリティアラートを外部システムに転送し、通知と対応を行います。

→Falcoとともに`Falcosidekick`をデプロイします。Falcoからアラートを受信し、Slack、PagerDuty、またはSIEMのような出力に転送するように設定します。

理由: Falcosidekickは、Falcoのリアルタイムアラートを既存の運用およびセキュリティワークフローに統合するための柔軟で堅牢なメカニズムを提供します。

実行中のコンテナが変更されたかどうかを検出し、それが侵害を示している可能性があります。

→`readOnlyRootFilesystem: true`で不変コンテナを強制します。Falcoのようなランタイムセキュリティツールを使用して、予期しない場所へのファイル書き込みを監視し、アラートを発します。

理由: 不変モデルでは、コンテナはランタイム時に変更されません。それらは置き換えられます。このパターンからの逸脱は、潜在的なセキュリティ侵害の強力な指標となります。