benchmarking-kubernetes-with-kube-bench

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 Benchmark に基づいてクラスターを直接強化することで、T1610（コンテナーのデプロイ） に対する攻撃対象領域を縮小できます。この手法では、攻撃者がコンテナーをデプロイしてコードを実行したり、防御を回避したりします。たとえば、強化されていないクラスターで公開されたままの特権コンテナー、ホスト名前空間、匿名 API アクセス、安全でない kubelet 設定を悪用します。

kube-bench は、ノード上のスタンドアロンバイナリとして、コンテナー内で、あるいは最も一般的な方法として、関連する設定ファイルを読み取れるようホストファイルシステムをマウントした Pod を持つ 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 の公式な方法）。

# Binary release (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

# Via Go install
go install github.com/aquasecurity/kube-bench@latest

# Run as a one-off container directly on a node (mounts host config)
docker run --rm --pid=host \
  -v /etc:/etc:ro -v /var:/var:ro \
  -t docker.io/aquasec/kube-bench:latest run --targets node

# Verify
kube-bench version

目的

• クラスターの Kubernetes バージョンに適したベンチマークを使って kube-bench を実行します。
• コントロールプレーン（マスター）、ノード、etcd、コントロールプレーンのポリシー、マネージドサービスのターゲットをスキャンします。
• パイプラインやダッシュボード向けに、機械可読な JSON/JUnit 出力を生成します。
• FAIL と WARN の結果をトリアージし、CIS の修正ガイダンスを適用します。
• 再実行して、修正後に PASS になったことを検証します。

MITRE ATT&CK マッピング

テクニック ID	名前	戦術	関連性
T1610	コンテナーのデプロイ	実行 / 防御回避	kube-bench で CIS Benchmark に基づく強化を適用すると、悪意のあるコンテナーのデプロイ時に攻撃者が悪用する特権コンテナーやホスト名前空間を使ったデプロイ、匿名 API アクセス、安全でない kubelet 設定を制限できます。

ワークフロー

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

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

sudo kube-bench

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

kube-bench リポジトリにある Job マニフェストを適用し、Pod のログから結果を読み取ります。

# General-purpose job
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# Wait, then retrieve results
kubectl get pods -l app=kube-bench
kubectl logs -l app=kube-bench

# Platform-specific jobs are available, e.g. EKS:
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml

3. 特定のコンポーネントを対象にする

run --targets を使って、スキャン対象を特定のコンポーネントグループに絞ります。

# Control-plane (API server, scheduler, controller manager)
sudo kube-bench run --targets master

# Worker node (kubelet, proxy)
sudo kube-bench run --targets node

# etcd datastore
sudo kube-bench run --targets etcd

# Cluster-wide policies (RBAC, pod security, network policy)
sudo kube-bench run --targets policies

# Combine multiple targets
sudo kube-bench run --targets master,node,etcd,policies

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

自動検出が正しくない場合や、特定の改訂版に基づいて監査する必要がある場合は、ベンチマークを明示的に指定します。

# Pin to a specific CIS benchmark revision
sudo kube-bench run --benchmark cis-1.8

# Or map by Kubernetes version
sudo kube-bench --version 1.27

# Managed/distribution-specific benchmarks
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 に絞るか、対象から除外します。

# Run only specific checks
sudo kube-bench run --targets master --check 1.2.1,1.2.2

# Skip noisy/known-accepted checks
sudo kube-bench run --targets node --skip 4.2.6

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

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

# JSON to a file
sudo kube-bench run --targets master,node --json --outputfile kube-bench-report.json

# JUnit (for CI test reporting)
sudo kube-bench --junit --outputfile kube-bench-junit.xml

# AWS Security Finding Format (for Security Hub)
sudo kube-bench run --targets node --asff

7. FAIL／WARN の検出結果をトリアージして修正する

各チェックでは修正方法が表示されます。CIS 推奨の修正をノードまたはマニフェストに適用します。たとえば、静的 Pod マニフェストの API サーバーのフラグを厳格化します。

# Example remediation for a common control-plane FAIL:
# CIS 1.2.x — ensure anonymous-auth is disabled on the API server.
# Edit the static pod manifest and set the flag:
sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
#   - --anonymous-auth=false
# The kubelet restarts the static pod automatically.

# Example node remediation — kubelet config file permissions (CIS 4.1.x):
sudo chmod 600 /etc/kubernetes/kubelet/kubelet-config.json
sudo chown root:root /etc/kubernetes/kubelet/kubelet-config.json

8. 修正後に再検証する

該当するターゲットを再実行し、以前 FAIL だったチェックが PASS になったことを確認してから、スコアを継続的に追跡します。

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

# Optional: persist results to PostgreSQL for trend tracking
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 推奨の修正が適用されている。
• 再実行により、以前 FAIL だったチェックが PASS になったことが確認されている。
• 結果が継続的に追跡されている（ファイルアーカイブまたは PostgreSQL）。