kube-benchによるKubernetesベンチマーキング

kube-benchによるKubernetesベンチマーキング は何をしますか？

概要

kube-bench（Aqua Security製）は、CIS Kubernetes Benchmarkに文書化されたチェックを実行して、Kubernetesクラスタが安全にデプロイされているかどうかを確認するオープンソースツールです。制御プレーンコンポーネント（APIサーバー、コントローラマネージャー、スケジューラ、etcd）、kubeletおよびワーカーノード設定、クラスタ全体のポリシー設定を検査し、各チェックをPASS、FAIL、WARN、INFOで報告し、CISガイダンスに基づいた修復推奨事項を提供します。テストはYAMLファイルで構成駆動されるため、kube-benchは新しいKubernetesバージョンとベンチマークリビジョンを追跡し、マネージドディストリビューション（EKS、GKE、AKS、ACK、OpenShift、RKE、k3s）をサポートします。

クラスタをCISベンチマークに対してハードニングすることで、T1610（コンテナの展開） に対する攻撃面が直接削減されます。これは、攻撃者がコンテナをデプロイしてコードを実行したり防御を回避したりする手法であり、例えば特権コンテナ、ホスト名前空間、匿名APIアクセス、安全でないkubelet設定などを悪用します。ハードニングされていないクラスタではこれらの設定が露出しています。

kube-benchは、ノード上のスタンドアロンバイナリとして、コンテナ内で、または最も一般的には、ホストファイルシステムをマウントして関連する設定ファイルを読み取るKubernetes Jobとして実行できます。出力は人間可読なテキスト、JSON、JUnit、AWS Security Finding Format（ASFF）として利用でき、PostgreSQLデータベースにプッシュして傾向追跡を行うこともできます。

使用するタイミング

• 新しいKubernetesクラスタのセキュリティベースラインをCIS Kubernetes Benchmarkに対して確立する場合。
• 制御プレーンとノードのハードニングに関する定期的なコンプライアンス監査を実施する場合。
• ハードニング変更を適用した後の修復を検証する場合（再実行してチェックが PASS になったことを確認）。
• クラスタのコンプライアンススキャンをCI/CDや継続的モニタリングパイプラインに統合する場合。
• SOC 2、PCI DSS、または内部ハードニングコンプライアンスの証拠を準備する場合。

前提条件

• クラスタへのアクセス：制御プレーン/ワーカーノードへのSSHアクセス（バイナリモード）、またはJobを作成する権限を持つkubectl（クラスタ内モード）。
• クラスタのKubernetesバージョンの知識（kube-benchは自動検出しますが、--version/--benchmarkで指定可能）。
• kube-benchのインストール（Aqua Security公式の方法）：

# バイナリリリース（Linux）
KB_VERSION=0.10.7
curl -L -o kube-bench.tgz \
  "https://github.com/aquasecurity/kube-bench/releases/download/v${KB_VERSION}/kube-bench_${KB_VERSION}_linux_amd64.tar.gz"
tar -xzf kube-bench.tgz
sudo mv kube-bench /usr/local/bin/
sudo cp -R cfg /etc/kube-bench/cfg

# Goインストール経由
go install github.com/aquasecurity/kube-bench@latest

# ノード上でワンオフコンテナとして実行（ホスト設定をマウント）
docker run --rm --pid=host \
  -v /etc:/etc:ro -v /var:/var:ro \
  -t docker.io/aquasec/kube-bench:latest run --targets node

# 確認
kube-bench version

目的

• クラスタのKubernetesバージョンに適したベンチマークに対してkube-benchを実行する。
• 制御プレーン（master）、ノード、etcd、制御プレーンポリシー、およびマネージドサービスのターゲットをスキャンする。
• 機械可読なJSON/JUnit出力を生成してパイプラインやダッシュボードに投入する。
• FAILおよびWARNの結果をトリアージし、CIS修復ガイダンスを適用する。
• 再実行して修復がPASSになったことを検証する。

MITRE ATT&CKマッピング

テクニックID	名前	戦術	関連性
T1610	コンテナの展開	実行 / 防御回避	kube-benchで実施されるCISベンチマークハードニングは、特権/ホスト名前空間のデプロイ、匿名APIアクセス、安全でないkubelet設定を制限し、これらは攻撃者が悪意のあるコンテナをデプロイする際に悪用します。

ワークフロー

1. デフォルトスキャンの実行（自動検出）

該当するすべてのターゲットを実行し、kube-benchにKubernetesバージョンとベンチマークを自動検出させます：

sudo kube-bench

2. Kubernetes Jobとして実行（クラスタ内）

kube-benchリポジトリから提供されるJobマニフェストを適用し、ポッドログから結果を読み取ります：

# 汎用Job
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# 待機後、結果を取得
kubectl get pods -l app=kube-bench
kubectl logs -l app=kube-bench

# プラットフォーム固有のJobも利用可能（例：EKS）
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml

3. 特定のコンポーネントをターゲットにする

run --targetsを使用して、スキャンを特定のコンポーネントグループに限定します：

# 制御プレーン（APIサーバー、スケジューラ、コントローラマネージャー）
sudo kube-bench run --targets master

# ワーカーノード（kubelet、プロキシ）
sudo kube-bench run --targets node

# etcdデータストア
sudo kube-bench run --targets etcd

# クラスタ全体のポリシー（RBAC、Podセキュリティ、ネットワークポリシー）
sudo kube-bench run --targets policies

# 複数のターゲットを組み合わせる
sudo kube-bench run --targets master,node,etcd,policies

4. 特定のベンチマークまたはKubernetesバージョンを固定する

自動検出が間違っている場合や、特定のリビジョンに対して監査する必要がある場合は、ベンチマークを明示的に固定します：

# 特定のCISベンチマークリビジョンを固定
sudo kube-bench run --benchmark cis-1.8

# またはKubernetesバージョンでマッピング
sudo kube-bench --version 1.27

# マネージド/ディストリビューション固有のベンチマーク
sudo kube-bench run --benchmark eks-1.5.0
sudo kube-bench run --benchmark gke-1.6.0
sudo kube-bench run --benchmark rke2-cis-1.7

5. 個別のチェックを実行またはスキップする

修復サイクル中に特定のチェックIDに焦点を当てたり、除外したりします：

# 特定のチェックのみを実行
sudo kube-bench run --targets master --check 1.2.1,1.2.2

# ノイズの多い/既知の許容チェックをスキップ
sudo kube-bench run --targets node --skip 4.2.6

6. 機械可読な出力を生成する

パイプライン、SIEM、ダッシュボードに取り込むためにJSONまたはJUnitを出力し、ファイルに書き込みます：

# JSONをファイルに出力
sudo kube-bench run --targets master,node --json --outputfile kube-bench-report.json

# JUnit（CIテストレポート用）
sudo kube-bench --junit --outputfile kube-bench-junit.xml

# AWS Security Finding Format（Security Hub用）
sudo kube-bench run --targets node --asff

7. FAIL/WARNの結果をトリアージして修復する

失敗した各チェックは修復方法を出力します。CIS推奨の修正をノード/マニフェストに適用します。例えば、静的ポッドマニフェストでAPIサーバーフラグを強化します：

# 一般的な制御プレーンFAILの修復例：
# CIS 1.2.x — APIサーバーで匿名認証を無効にする。
# 静的ポッドマニフェストを編集し、フラグを設定：
sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
#   - --anonymous-auth=false
# kubeletが自動的に静的ポッドを再起動します。

# ノード修復例 — kubelet設定ファイルのパーミッション（CIS 4.1.x）：
sudo chmod 600 /etc/kubernetes/kubelet/kubelet-config.json
sudo chown root:root /etc/kubernetes/kubelet/kubelet-config.json

8. 修復後に再検証する

該当するターゲットを再実行し、以前失敗したチェックがPASSになったことを確認し、時間の経過に伴うスコアを追跡します：

sudo kube-bench run --targets master --check 1.2.1 --json --outputfile recheck.json

# オプション：結果をPostgreSQLに永続化して傾向追跡
sudo kube-bench run --targets master,node --pgsql

ツールとリソース

ツール / リソース	目的	リンク
kube-bench	CIS Kubernetes Benchmarkチェッカー	https://github.com/aquasecurity/kube-bench
kube-benchドキュメント	実行/プラットフォーム/フラグ	https://aquasecurity.github.io/kube-bench/
CIS Kubernetes Benchmark	ソースとなるハードニング基準	https://www.cisecurity.org/benchmark/kubernetes
Trivy Operator	クラスタ内での継続的なコンプライアンス+脆弱性スキャン	https://github.com/aquasecurity/trivy-operator
kube-hunter	補完的なペネトレーションテストツール	https://github.com/aquasecurity/kube-hunter

検証基準

• kube-benchがインストールされている（kube-bench version）、またはJobとして実行中。
• クラスタのKubernetesバージョンに適した正しいベンチマークに対してスキャンが実行された。
• master、node、etcd、policiesの各ターゲットがスキャンされた。
• パイプライン/ダッシュボード取り込み用のJSON/JUnit出力が生成された。
• FAILおよびWARNの結果がトリアージされ、優先順位付けされた。
• CIS修復が制御プレーンマニフェストとノード設定に適用された。
• 再実行により、以前失敗したチェックがPASSになったことが確認された。
• 結果が経時的に追跡されている（ファイルアーカイブまたはPostgreSQL）。