aquasecurity/kube-hunterKubernetesクラスターのセキュリティ上の弱点をハントする
## 注意
kube-hunterは現在活発に開発されていません。既知の脆弱性についてKubernetesクラスターをスキャンしたい場合は、[Trivy](https://github.com/aquasecurity/trivy) の使用をお勧めします。特に、TrivyのKubernetes [misconfiguration scanning](https://blog.aquasec.com/trivy-kubernetes-cis-benchmark-scanning) および [KBOM vulnerability scanning](https://blog.aquasec.com/scanning-kbom-for-vulnerabilities-with-trivy) をご覧ください。詳細は [Trivy Docs](https://aquasecurity.github.io/trivy/) をご確認ください。
---
kube-hunterは、Kubernetesクラスターのセキュリティ上の弱点を探します。このツールは、Kubernetes環境におけるセキュリティ問題への認識と可視性を高めるために開発されました。**自分が所有していないKubernetesクラスターでkube-hunterを実行しないでください！**
**kube-hunterの実行**: kube-hunterはコンテナ (aquasec/kube-hunter) として提供されており、[kube-hunter.aquasec.com](https://kube-hunter.aquasec.com) でオンライン登録してトークンを受け取ると、結果をオンラインで表示・共有できます。また、後述のようにPythonコードを直接実行することもできます。
**脆弱性の探索**: kube-hunterのナレッジベースには、発見可能な脆弱性や問題に関する記事が含まれています。kube-hunterが問題を報告すると、そのVID (脆弱性ID) が表示されるので、KB (https://aquasecurity.github.io/kube-hunter/) で調べることができます。
_kube-hunterのKubernetes ATT&CK Matrix統合に興味がある場合は、[続きを読む](#kubernetes-attck-matrix)_
[kube-hunter デモ動画](https://youtu.be/s2-6rTkH8a8?t=57s)
## 目次
- [目次](#目次)
- [Kubernetes ATT&CK Matrix](#kubernetes-attck-matrix)
- [ハンティング](#ハンティング)
- [kube-hunterはどこで実行すべきか？](#kube-hunterはどこで実行すべきか)
- [スキャンオプション](#スキャンオプション)
- [認証](#認証)
- [アクティブハンティング](#アクティブハンティング)
- [テスト一覧](#テスト一覧)
- [ノードマッピング](#ノードマッピング)
- [出力](#出力)
- [ディスパッチ](#ディスパッチ)
- [高度な使い方](#高度な使い方)
- [Azureクイックスキャン](#azureクイックスキャン)
- [カスタムハンティング](#カスタムハンティング)
- [デプロイ](#デプロイ)
- [マシン上](#マシン上)
- [前提条件](#前提条件)
- [pipでインストール](#pipでインストール)
- [ソースから実行](#ソースから実行)
- [コンテナ](#コンテナ)
- [Pod](#pod)
- [コントリビューション](#コントリビューション)
- [ライセンス](#ライセンス)
## Kubernetes ATT&CK Matrix
kube-hunterは、Kubernetes ATT&CK matrixの新しいフォーマットに対応しました。kube-hunterの脆弱性は、攻撃者を模倣した創造的なテクニックの集まりですが、MITREのATT&CKは、それを行うためのより一般的な標準化されたテクニックカテゴリを定義しています。kube-hunterの脆弱性は、攻撃者が目指すより一般的なテクニックの足がかりとなる小さなステップと考えることができます。kube-hunterのハンターと脆弱性のほとんどは、これらのテクニックに密接に該当する可能性があるため、Matrix標準に準拠することにしました。
_MITREのテクニックにマッピングできなかったいくつかのkube-hunter脆弱性には、`General`キーワードがプレフィックスとして付いています。_
## ハンティング
### kube-hunterはどこで実行すべきか？
kube-hunterの実行方法は3通りあり、それぞれクラスターの弱点を検出するための異なるアプローチを提供します。
任意のマシン（ラップトップを含む）でkube-hunterを実行し、リモートスキャンを選択してKubernetesクラスターのIPアドレスまたはドメイン名を指定します。これにより、攻撃者の視点からKubernetesセットアップを確認できます。
クラスター内のマシンで直接kube-hunterを実行し、すべてのローカルネットワークインターフェースをプローブするオプションを選択することもできます。
また、kube-hunterをクラスター内のPodとして実行することもできます。これにより、もしアプリケーションのPodが（例えばソフトウェアの脆弱性によって）侵害された場合、クラスターがどの程度露出するかを示します。（`--pod`オプション）
### スキャンオプション
最初にこれらの**[前提条件](#前提条件)**を確認してください。
デフォルトでは、kube-hunterは対話型セッションを開始し、以下のスキャンオプションのいずれかを選択できます。コマンドラインから手動でスキャンオプションを指定することもできます。オプションは以下の通りです。
1. **リモートスキャン**
ハンティング対象のリモートマシンを指定するには、オプション1を選択するか、`--remote`オプションを使用します。例:
`kube-hunter --remote some.node.com`
2. **インターフェーススキャン**
インターフェーススキャンを指定するには、`--interface`オプションを使用します（これにより、マシンのすべてのネットワークインターフェースがスキャンされます）。例:
`kube-hunter --interface`
3. **ネットワークスキャン**
特定のCIDRをスキャンするには、`--cidr`オプションを使用します。例:
`kube-hunter --cidr 192.168.0.0/24`
4. **Kubernetesノード自動検出**
`--k8s-auto-discover-nodes` フラグを設定すると、Kubernetesに問い合わせてクラスター内のすべてのノードを取得し、それらすべてをスキャンしようとします。デフォルトでは、Kubernetes APIに接続するために[in-cluster config](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)を使用します。明示的なkubeconfigファイルを使用する場合は、`--kubeconfig /location/of/kubeconfig/file`を設定します。
また、`--pod` モードを使用する場合、これは常に行われることに注意してください。
### 認証
攻撃者の初期段階を模倣するために、kube-hunterはハンティングに認証を必要としません。
* **Impersonate** - `--service-account-token` フラグでサービスアカウントシークレットのJWT Bearerトークンを手動で渡すことにより、ハンティング時に特定のサービスアカウントトークンを使用するようにkube-hunterに指示できます。
例:
```bash
$ kube-hunter --active --service-account-token eyJhbGciOiJSUzI1Ni...
```
* `--pod` フラグを付けて実行する場合、kube-hunterはハンティング中に検出したサービスへの認証に、[Pod内にマウントされた](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/)サービスアカウントトークンを使用します。
* 指定された場合、`--service-account-token` フラグはPodとして実行するときに優先されます。
### アクティブハンティング
アクティブハンティングは、kube-hunterが見つけた脆弱性を積極的に悪用し、さらに多くの脆弱性を探るオプションです。通常のハンティングとアクティブハンティングの主な違いは、通常のハンティングではクラスターの状態を変更しないのに対し、アクティブハンティングはクラスターに対して状態を変更する操作を行う可能性があり、**危険を伴う可能性がある**ことです。
デフォルトでは、kube-hunterはアクティブハンティングを行いません。アクティブにハンティングするには、`--active` フラグを使用します。例:
`kube-hunter --remote some.domain.com --active`
### テスト一覧
テストの一覧は、`--list` オプションで表示できます。例:
`kube-hunter --list`
アクティブハンティングのテストも含めて表示するには:
`kube-hunter --list --active`
### ノードマッピング
ノードのネットワークマッピングのみを表示するには、`--mapping` オプションを付けて実行します。例:
`kube-hunter --cidr 192.168.0.0/24 --mapping`
これにより、kube-hunterが見つけたすべてのKubernetesノードが出力されます。
### 出力
ログを制御するには、`--log` オプションを使用してログレベルを指定します。例:
`kube-hunter --active --log WARNING`
利用可能なログレベルは以下の通りです。
* DEBUG
* INFO (デフォルト)
* WARNING
### ディスパッチ
デフォルトでは、レポートは `stdout` に出力されますが、`--dispatch` オプションを使用して異なる方法を指定できます。例:
`kube-hunter --report json --dispatch http`
利用可能なディスパッチ方法は以下の通りです。
* stdout (デフォルト)
* http (設定するには、以下の環境変数を設定します)
* KUBEHUNTER_HTTP_DISPATCH_URL (デフォルト: https://localhost)
* KUBEHUNTER_HTTP_DISPATCH_METHOD (デフォルト: POST)
## 高度な使い方
### Azureクイックスキャン
**AzureまたはAWS環境のPodとして実行する場合**、kube-hunterはインスタンスメタデータサービスからサブネットを取得します。そのため、通常、発見プロセスに時間がかかります。サブネットスキャンを `/24` CIDRに厳格に制限するには、`--quick` オプションを使用します。
### カスタムハンティング
カスタムハンティングにより、上級ユーザーはハンティング開始時に登録されるハンターを制御できます。
**自分が何をしているか理解している場合**、これは必要に応じてkube-hunterのハンティングと発見プロセスを調整するのに役立ちます。
例:
```
kube-hunter --custom <HunterName1> <HunterName2>
```
カスタムハンティングを有効にすると、指定されたホワイトリストのハンター以外のすべてのハンターがハンティングプロセスから削除されます。
`--custom` フラグはハンターのクラス名のリストを読み取ります。kube-hunterのすべてのクラス名を表示するには、`--raw-hunter-names` フラグを `--list` フラグと組み合わせて使用できます。
例:
```
kube-hunter --active --list --raw-hunter-names
```
**注意**: kube-hunerのアーキテクチャ設計により、以下の「コアハンター/クラス」は常に登録されます（カスタムハンティングを使用する場合も同様）:
* HostDiscovery
* _指定された設定に基づいてハンティング用のIPアドレスを生成_
* _クラウドメタデータAPIを使用して自動的にサブネットを発見_
* FromPodHostDiscovery
* _Podベースの環境技術を使用して、ハンティング用の攻撃対象IPアドレスを自動発見_
* _クラウドメタデータAPIを使用して自動的にサブネットを発見_
* PortDiscovery
* _指定されたIPアドレスに対して、既知のKubernetesサービスポートのポートスキャン_
* Collector
* _発見された脆弱性とオープンサービスを収集し、将来のレポート用に保存_
* StartedInfo
* _開始メッセージを出力_
* SendFullReport
* _指定された設定に基づいてレポートをディスパッチ_
## デプロイ
kube-hunterのデプロイ方法は3つあります:
### マシン上
マシン上で直接kube-hunterを実行できます。
#### 前提条件
以下のインストールが必要です:
* python 3.x
* pip
##### pipでインストール
インストール:
~~~
pip install kube-hunter
~~~
実行:
~~~
kube-hunter
~~~
##### ソースから実行
リポジトリをクローン:
~~~
git clone https://github.com/aquasecurity/kube-hunter.git
~~~
モジュールの依存関係をインストール（[Virtual Environment](https://packaging.python.org/guides/installing-using-pip-and-virtual-environments/)内で行うことを推奨）:
~~~
cd ./kube-hunter
pip install -r requirements.txt
~~~
実行:
~~~
python3 kube_hunter
~~~
_pyinstaller/py2exeを使用する場合は、最初にinstall_imports.pyスクリプトを実行する必要があります。_
### コンテナ
Aqua Securityは、kube-hunterのコンテナ版を `aquasec/kube-hunter:aqua` で管理しています。このコンテナには、このソースコードに加えて、レポート結果を[kube-hunter.aquasec.com](https://kube-hunter.aquasec.com)で表示可能なレポートにアップロードするための（クローズドソースの）レポートプラグインが含まれています。`aquasec/kube-hunter` コンテナの実行とレポートデータのアップロードには、追加の[利用規約](https://kube-hunter.aquasec.com/eula.html)が適用されることに注意してください。このリポジトリのDockerfileを使用すると、レポートプラグインなしでコンテナ版をビルドできます。
ホストネットワークでkube-hunterコンテナを実行すると、ホスト上のすべてのインターフェースをプローブできます:
`docker run -it --rm --network host aquasec/kube-hunter`
_Docker for Mac/Windowsに関する注意:_ Docker for MacまたはWindowsの「ホスト」は、Dockerがコンテナを実行するVMです。そのため、`--network host` を指定すると、kube-hunterはそのVMのネットワークインターフェースにアクセスできるようになり、手元のマシンのインターフェースにはアクセスできません。デフォルトでは、kube-hunterは対話型モードで実行されます。上記のパラメータを使用してスキャンオプションを指定することもできます。例:
`docker run --rm aquasec/kube-hunter --cidr 192.168.0.0/24`
### Pod
このオプションを使用すると、悪意のあるコンテナを実行することでクラスター上で何ができ、何が発見できるかを確認できます。これにより、攻撃者がソフトウェアの脆弱性などを通じてPodを侵害できた場合に何ができるかという視点が得られます。これにより、通常よりもはるかに多くの脆弱性が明らかになる可能性があります。
サンプルの `job.yaml` ファイルは、デフォルトのKubernetes Podアクセス設定を使用して、Pod内でkube-hunterを実行するJobを定義しています。（必要に応じて、この定義を変更しても構いません。例えば、root以外のユーザーとして実行する、異なる名前空間で実行するなど。）
* `kubectl create -f ./job.yaml` でJobを実行
* `kubectl describe job kube-hunter` でPod名を確認
* `kubectl logs <pod name>` でテスト結果を表示
## コントリビューション
コントリビューションガイドラインを読むには、<a href="https://github.com/aquasecurity/kube-hunter/blob/main/CONTRIBUTING.md"> こちらをクリック </a>
## ライセンス
このリポジトリは [Apache License 2.0](https://github.com/aquasecurity/kube-hunter/blob/main/LICENSE) の下で利用可能です。