「kube-bench」でKubernetesクラスタのCISベンチマーク準拠を確認する

仮想化／コンテナ

技術解説

連載 [第15回] :

Kubernetesスペシャリストが注目する関連ツール探求

2025年7月2日(水)

小林舜

第15回の今回は、「kube-bench」でKubernetesクラスタのセキュリティベンチマークを取得し、CIS Benchmarkのベストプラクティスに準拠しているか確認する方法について紹介します。

はじめに

3-shakeのSreake事業部でインターンとして活動している小林(@moz-sec)です。第15回目の今回は、Kubernetesのセキュリティベンチマークツールである「kube-bench」について紹介します。

【出典】https://aquasecurity.github.io/kube-bench/dev/images/kube-bench.jpg

kube-benchとは

CIS Kubernetes Benchmarkをもとに、Kubernetesクラスタがセキュリティのベストプラクティスに準拠しているかどうかを確認するコマンドラインツールです。オンプレミスからパブリックKubenretesサービスまで、さまざまなKubernetes環境で動作するように設計されています。

EKS、GKE、AKSといったマネージドKubernetesクラスタではコントロールプレーンノードにアクセスできませんが、ワーカーノードの構成を確認することは可能です。そのため、kube-benchの設定ファイルにはEKS、GKE、AKS用の設定ファイルが用意されており、これを使うことでテストを行います。

kube-benchはデフォルトで、動作しているKubernetesのバージョンに基づいてテストセットを決定し、さらにノード上のコンポーネントの識別を行い、実際に実行するテストセットを決定します。

CIS Kubernetes Benchmark

CIS Benchmarkとは、クラウドサービスやOS、サーバーソフトウェア、モバイルデバイス、ネットワーク機器といった、セキュリティのベストプラクティスです。Kubernetesはサーバーソフトウェアに含まれており、他にBINDやNGINX、PostgreSQL、VMwareなどが含まれています。

CIS Kubernetes Benchmarkは大まかに次のような構成になっており、各コンポーネントを保護するためのベストプラクティスと推奨事項が書かれています。例えば、設定ファイルの権限や各コンポーネント起動時のオプション引数、適切なアクセス権限が付与されているかなどの記述があります。

Control Plane Component
　　1.1 Control Plane Node Configuration Files
　　1.2 API server
　　1.3 Controller Manager
　　1.4 Scheduler
etcd
Control Plane Configuration
　　3.1 Authentication and Authorization
　　3.2 Logging
Worker Nodes
　　4.1 Worker Node Configuration Files
　　4.2 Kubelet
　　4.3 kube-proxy
Policies
　　5.1 RBAC and Service Accounts
　　5.2 Pod Security Standards
　　5.3 Network Policies and CNI
　　5.4 Secrets Management
　　5.5 Extensible Admission Control
　　5.6 General Policies

最新版のCIS Kubernetes Benchmarkはv.1.11.0が2025/04/01に公開されており、Kubernetes v1.29-v1.32が対象になっています。340ページほどありますが、個々のセクションは簡潔にまとめてあるため、読みやすいです。ただし、これに対応するkube-benchの設定ファイルはまだ用意されていません。

1つ前のCIS Kubernetes Benchmarkはv.1.10.0が2024/09/23に公開されており、Kubernetes v1.28-v1.31が対象になっています。こちらは332ページあります。これに対応するkube-benchの設定ファイルはcis-1.10です。

CIS Kubernetes BenchmarkはセルフマネージドKubernetesクラスタが対象になっているため、クラウドで提供されているEKS、GKE、AKSなどのマネージドKubernetesサービスを使う場合には別のCIS Benchmarkを使用します。詳しくはCIS Amazon EKS Benchmark、CIS GKE Benchmark・CIS GKE Autopilot Benchmark、 CIS AKS Benchmarkを参照してください。

kube-benchのドキュメントに対象のKubernetesのバージョンが記載されていますが、情報が更新されていないため、2025/06/10時点では次のようになっています。CIS Kubernetes BenchmarkのドキュメントにはTarget Technology Detailsセクションに対象となるKubernetesのバージョンが書かれています。

ソース	CIS Kubernetes Benchmark	kube-bench config	Kubernetes version
CIS	v1.11.0	なし	v1.29-v1.32
CIS	v1.10.0	cis-1.10	v1.28-v1.31
CIS	EKS v1.5.0	eks-1.5.0	EKS
CIS	GKE v1.6.1	gke-1.6.0	GKE
CIS	AKS v1.5.0	aks-1.0(未更新)	AKS

Kubernetes BenchmarkのProfile Applicabilityという項目では、レベル1とレベル2が定義されています。

レベル1は、実用的かつ慎重な対応として比較的容易に導入できる基本的なセキュリティ対策であり、ほとんどの環境で最低限行うべきものになります。次のような基準に基づいて定義されています。

be practical and prudent; provide a clear security benefit; and not inhibit the utility of the technology beyond acceptable means.

レベル2は、レベル1を拡張したもので、強固なセキュリティ対策を提供しますが、システムの機能や運用に影響を与える可能性があるため、高セキュリティが要求される環境での適用が推奨されます。

Extends Level 1

各チェック項目には次のような情報も含まれており、CIS Kubernetes Benchmarkを見るだけで「何を確認すべきか」「理想的な状態は何か」が明確に分かる構成になっています。

項目の詳細
セキュリティ上の根拠
運用に与える影響
推奨される設定の適用方法
確認手順
デフォルト設定

実行方法

kube-benchでテストを実行する方法は3つあります。Kubernetes環境に応じて、柔軟に選択して実行することが可能です。

バイナリをインストールして直接実行
後述するコンテナでの実行に比べて、権限周りを気にする必要がないため、最も手軽に実行できます。

kube-benchのバージョンは、GitHubリポジトリのReleasesを参照してください。
```
$ curl -OL https://github.com/aquasecurity/kube-bench/releases/download/v0.10.7/kube-bench_0.10.7_linux_amd64.deb
$ sudo apt install ./kube-bench_0.10.7_linux_amd64.deb
$ kube-bench run
```
コンテナ実行
ホストのPID Namespaceへのアクセス権限が必要です。また、Kubernetesの設定ファイル(/etc, /var)やkubeconfigをコンテナにマウントする必要があります。
```
$ docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl -v ~/.kube:/.kube -e KUBECONFIG=/.kube/config -t aquasec/kube-bench:latest
```
Kubernetes Podで実行
ホストのPID Namespaceへのアクセス権限が必要です。また、Kubernetesの設定ファイル(/etc, /var)やkubeconfigをコンテナにマウントする必要があります。

さらに、コントロールプレーンノードでテストを行うには、podSelectorとtolerationsでPodを適切にスケジューリングする必要があります。
```
$ kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/refs/heads/main/job.yaml
$ kubectl logs {kube-bench_Pod_name}
```

定期実行

Kubernetes上でCronJobを作成しておくと、定期的にkube-benchを実行してKubernetesの設定をチェックできます。

kube-benchのリポジトリにjob.yamlがあるため、これを参考にしてCronJobを作成します。次のCronJobでは、日本時間(JST)で毎日午前2時にスキャンを行います。

apiVersion: batch/v1
kind: CronJob
metadata:
  name: kube-bench
spec:
  schedule: "0 2 * * *" # 毎日午前2時
  timeZone: "Asia/Tokyo"  # 日本時間
  jobTemplate:
    spec:
      template:
        metadata:
          labels:
            app: kube-bench
        spec:
          containers:
            - name: kube-bench
              image: docker.io/aquasec/kube-bench:v0.10.4
              command: ["kube-bench"]
              volumeMounts:
                - name: var-lib-cni
                  mountPath: /var/lib/cni
                  readOnly: true
                - name: var-lib-etcd
                  mountPath: /var/lib/etcd
                  readOnly: true
                - name: var-lib-kubelet
                  mountPath: /var/lib/kubelet
                  readOnly: true
                - name: var-lib-kube-scheduler
                  mountPath: /var/lib/kube-scheduler
                  readOnly: true
                - name: var-lib-kube-controller-manager
                  mountPath: /var/lib/kube-controller-manager
                  readOnly: true
                - name: etc-systemd
                  mountPath: /etc/systemd
                  readOnly: true
                - name: lib-systemd
                  mountPath: /lib/systemd/
                  readOnly: true
                - name: srv-kubernetes
                  mountPath: /srv/kubernetes/
                  readOnly: true
                - name: etc-kubernetes
                  mountPath: /etc/kubernetes
                  readOnly: true
                - name: usr-bin
                  mountPath: /usr/local/mount-from-host/bin
                  readOnly: true
                - name: etc-cni-netd
                  mountPath: /etc/cni/net.d/
                  readOnly: true
                - name: opt-cni-bin
                  mountPath: /opt/cni/bin/
                  readOnly: true
          hostPID: true
          restartPolicy: Never
          volumes:
            - name: var-lib-cni
              hostPath:
                path: /var/lib/cni
            - name: var-lib-etcd
              hostPath:
                path: /var/lib/etcd
            - name: var-lib-kubelet
              hostPath:
                path: /var/lib/kubelet
            - name: var-lib-kube-scheduler
              hostPath:
                path: /var/lib/kube-scheduler
            - name: var-lib-kube-controller-manager
              hostPath:
                path: /var/lib/kube-controller-manager
            - name: etc-systemd
              hostPath:
                path: /etc/systemd
            - name: lib-systemd
              hostPath:
                path: /lib/systemd
            - name: srv-kubernetes
              hostPath:
                path: /srv/kubernetes
            - name: etc-kubernetes
              hostPath:
                path: /etc/kubernetes
            - name: usr-bin
              hostPath:
                path: /usr/bin
            - name: etc-cni-netd
              hostPath:
                path: /etc/cni/net.d/
            - name: opt-cni-bin
              hostPath:
                path: /opt/cni/bin/

テスト項目の制御

kube-benchコマンドを実行するだけで自動的にKubernetesのバージョンやコントロールプレーン・ワーカーを特定してスキャンを行うためオプションの指定は特に必要ありませんが、特定のルールのみチェックしたいといった場合にはオプションで指定できます。

--versionでKubernetesのバージョンを指定します。これは、環境変数KUBE_BENCH_VERSIONでも指定できますが、—-versionがある場合は上書きします。

$ kube-bench run --version 1.32

--benchmarkでCISベンチマークを指定します。

$ kube-bench run --benchmark cis-1.10

ただし、—-versionと—-benchmarkの併用はできません。

CISベンチマークの中から特定のルールのみチェックを行うことも可能です。

--targetsでセクションを指定します。master、node、controlplane、etcd、policiesから選択できます。

$ kube-bench run --targets master

--idでチェック項目を指定します。このIDとなる番号はCIS Kubernetes Benchmarkに記述されているものになります。

$ kube-bench run --check='1.1.1, 1.2.1'

CISベンチマークの指定はkube-bench/cfgからディレクトリの指定、特定のルールの指定はファイルを指定することで実現しています。例えば--targetsでnodeを指定した場合はkube-bench/cfg/cis-1.10の中からkube-bench/cfg/cis-1.10/node.yamlが選択され、テストを実行します。

ワーカーノードで実行

一番上に各項目のPASS・WARN・FAIL・INFOが書かれており、Remediationsに修正方法が書かれています。各項目の右側にAutomated・Manualがあり、自動でチェックできるかどうかが書かれています。

WARNは手動でテストを行う必要があるもので、Manualの項目がこれに該当することが多いです。

オンプレミスのKubernetes環境のワーカーノードでkube-benchを実行したときの結果を一部抜粋します。自動でワーカーノードであることを検知し、CIS Kubernetes Benchmarkの 4.Worker Nodesと5.Policiesのチェックが行われます。内部的にはkube-bench/cfg/cis-1.10のテストセットが選択され、その中でもnode.yamlとpolicies.yamlのテストが行われます。

$ kube-bench run

[INFO] 4 Worker Node Security Configuration
[INFO] 4.1 Worker Node Configuration Files
[FAIL] 4.1.1 Ensure that the kubelet service file permissions are set to 600 or more restrictive (Automated)
[PASS] 4.1.2 Ensure that the kubelet service file ownership is set to root:root (Automated)

== Remediations node ==
4.1.1 Run the below command (based on the file location on your system) on the each worker node.
For example, chmod 600 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

== Summary node ==
1 checks PASS
11 checks FAIL
12 checks WARN
0 checks INFO

[INFO] 5 Kubernetes Policies
[INFO] 5.1 RBAC and Service Accounts
[FAIL] 5.1.1 Ensure that the cluster-admin role is only used where required (Automated)

== Remediations policies ==
5.1.1 Identify all clusterrolebindings to the cluster-admin role. Check if they are used and
if they need this role or if they could use a role with fewer privileges.
Where possible, first bind users to a lower privileged role and then remove the
clusterrolebinding to the cluster-admin role : kubectl delete clusterrolebinding [name]
Condition: is_compliant is false if rolename is not cluster-admin and rolebinding is cluster-admin.

== Summary policies ==
0 checks PASS
6 checks FAIL
29 checks WARN
0 checks INFO

== Summary total ==
1 checks PASS
17 checks FAIL
41 checks WARN
0 checks INFO

コントロールプレーンノードで実行

オンプレミスのKubernetes環境のコントロールプレーンノードでkube-benchを実行したときの結果を一部抜粋します。自動でコントロールプレーンノードであることを検知し、CIS Kubernetes Benchmarkの1.Control Plane Component、2.etcd、3.Control Plane Configuration、4.Worker Nodes、5.Policies といった全てのチェックが行われます。内部的にはkube-bench/cfg/cis-1.10のテストセットが選択され、その中のmaster.yaml、etcd.yaml、node.yaml、policies.yamlのテストが行われます。

$ kube-bench run

[INFO] 1 Control Plane Security Configuration
[INFO] 1.1 Control Plane Node Configuration Files
[PASS] 1.1.1 Ensure that the API server pod specification file permissions are set to 600 or more restrictive (Automated)

== Remediations master ==
1.1.9 Run the below command (based on the file location on your system) on the control plane node.
For example, chmod 600 

== Summary master ==
38 checks PASS
9 checks FAIL
12 checks WARN
0 checks INFO

[INFO] 2 Etcd Node Configuration
[INFO] 2 Etcd Node Configuration
[PASS] 2.1 Ensure that the --cert-file and --key-file arguments are set as appropriate (Automated)

== Summary etcd ==
7 checks PASS
0 checks FAIL
0 checks WARN
0 checks INFO

[INFO] 3 Control Plane Configuration
[INFO] 3.1 Authentication and Authorization
[WARN] 3.1.1 Client certificate authentication should not be used for users (Manual)

== Summary controlplane ==
0 checks PASS
0 checks FAIL
5 checks WARN
0 checks INFO

[INFO] 4 Worker Node Security Configuration
[INFO] 4.1 Worker Node Configuration Files
[FAIL] 4.1.1 Ensure that the kubelet service file permissions are set to 600 or more restrictive (Automated)

== Remediations node ==
4.1.1 Run the below command (based on the file location on your system) on the each worker node.
For example, chmod 600 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

== Summary node ==
16 checks PASS
2 checks FAIL
6 checks WARN
0 checks INFO

[INFO] 5 Kubernetes Policies
[INFO] 5.1 RBAC and Service Accounts
[FAIL] 5.1.1 Ensure that the cluster-admin role is only used where required (Automated)

== Remediations policies ==
5.1.1 Identify all clusterrolebindings to the cluster-admin role. Check if they are used and
if they need this role or if they could use a role with fewer privileges.
Where possible, first bind users to a lower privileged role and then remove the
clusterrolebinding to the cluster-admin role : kubectl delete clusterrolebinding [name]
Condition: is_compliant is false if rolename is not cluster-admin and rolebinding is cluster-admin.

== Summary policies ==
0 checks PASS
6 checks FAIL
29 checks WARN
0 checks INFO

== Summary total ==
61 checks PASS
17 checks FAIL
52 checks WARN
0 checks INFO

おわりに

今回は、kube-benchを利用して、Kubernetesクラスタがセキュリティのベストプラクティスにどれだけ準拠しているかを確認する方法について解説しました。また、CIS Kubernetesベンチマークについても取り上げました。

今回紹介した以外にも、YAMLファイルを記述することでテストを追加することも可能です。まだCIS Kubernetes Benchmark v1.11.0に対応するkube-benchの設定ファイルはないため、新たに追加されたテスト項目はkube-benchではチェックできません。しかし、kube-benchではYAMLファイルをベースにテストを行っているため、追加されたチェック項目をYAMLで定義するとユーザ側で対応できるようになります。

kube-benchのconfigファイルの書き方

kube-benchを使って、Kubernetesクラスタのセキュリティをテストしてみてはいかがでしょうか。

【参考】

著者

小林舜

この著者の記事一覧この著者の
記事一覧

株式会社スリーシェイク Sreake事業部

2024年6月にインターンとして3-shakeのSreake事業部にJoin。Kubernetesやクラウドネイティブ技術の技術検証を行っています。
---
スリーシェイクは、ITインフラ領域の技術力に強みをもつテクノロジーカンパニーです。SREコンサルティング事業「Sreake」では、AWS/Google Cloud/Kubernetesに精通したプロフェッショナルが技術戦略から設計・開発・運用を一貫してサポートしています。また、ノーコード型ETLツール「Reckoner」、フリーランスエンジニア特化型人材紹介サービス「Relance」、セキュリティサービス「Securify」を提供しています。
会社HP: https://3-shake.com/