aquasecurity/kube-hunterKubernetesクラスターのセキュリティ上の弱点をハントする
kube-hunterは現在活発に開発されていません。既知の脆弱性についてKubernetesクラスターをスキャンしたい場合は、Trivy の使用をお勧めします。特に、TrivyのKubernetes misconfiguration scanning および KBOM vulnerability scanning をご覧ください。詳細は Trivy Docs をご確認ください。
kube-hunterは、Kubernetesクラスターのセキュリティ上の弱点を探します。このツールは、Kubernetes環境におけるセキュリティ問題への認識と可視性を高めるために開発されました。自分が所有していないKubernetesクラスターでkube-hunterを実行しないでください！
kube-hunterの実行: kube-hunterはコンテナ (aquasec/kube-hunter) として提供されており、kube-hunter.aquasec.com でオンライン登録してトークンを受け取ると、結果をオンラインで表示・共有できます。また、後述のようにPythonコードを直接実行することもできます。
脆弱性の探索: kube-hunterのナレッジベースには、発見可能な脆弱性や問題に関する記事が含まれています。kube-hunterが問題を報告すると、そのVID (脆弱性ID) が表示されるので、KB (https://aquasecurity.github.io/kube-hunter/) で調べることができます。 kube-hunterの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の実行方法は3通りあり、それぞれクラスターの弱点を検出するための異なるアプローチを提供します。
任意のマシン（ラップトップを含む）でkube-hunterを実行し、リモートスキャンを選択してKubernetesクラスターのIPアドレスまたはドメイン名を指定します。これにより、攻撃者の視点からKubernetesセットアップを確認できます。
クラスター内のマシンで直接kube-hunterを実行し、すべてのローカルネットワークインターフェースをプローブするオプションを選択することもできます。
また、kube-hunterをクラスター内のPodとして実行することもできます。これにより、もしアプリケーションのPodが（例えばソフトウェアの脆弱性によって）侵害された場合、クラスターがどの程度露出するかを示します。（--podオプション）
最初にこれらの**前提条件**を確認してください。
デフォルトでは、kube-hunterは対話型セッションを開始し、以下のスキャンオプションのいずれかを選択できます。コマンドラインから手動でスキャンオプションを指定することもできます。オプションは以下の通りです。
ハンティング対象のリモートマシンを指定するには、オプション1を選択するか、--remoteオプションを使用します。例:
kube-hunter --remote some.node.com
インターフェーススキャンを指定するには、--interfaceオプションを使用します（これにより、マシンのすべてのネットワークインターフェースがスキャンされます）。例:
kube-hunter --interface
特定のCIDRをスキャンするには、--cidrオプションを使用します。例:
kube-hunter --cidr 192.168.0.0/24
--k8s-auto-discover-nodes フラグを設定すると、Kubernetesに問い合わせてクラスター内のすべてのノードを取得し、それらすべてをスキャンしようとします。デフォルトでは、Kubernetes APIに接続するためにin-cluster configを使用します。明示的なkubeconfigファイルを使用する場合は、--kubeconfig /location/of/kubeconfig/fileを設定します。
また、--pod モードを使用する場合、これは常に行われることに注意してください。
攻撃者の初期段階を模倣するために、kube-hunterはハンティングに認証を必要としません。
Impersonate - --service-account-token フラグでサービスアカウントシークレットのJWT Bearerトークンを手動で渡すことにより、ハンティング時に特定のサービスアカウントトークンを使用するようにkube-hunterに指示できます。
例:
$ kube-hunter --active --service-account-token eyJhbGciOiJSUzI1Ni...
--pod フラグを付けて実行する場合、kube-hunterはハンティング中に検出したサービスへの認証に、Pod内にマウントされたサービスアカウントトークンを使用します。
--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
利用可能なログレベルは以下の通りです。
デフォルトでは、レポートは stdout に出力されますが、--dispatch オプションを使用して異なる方法を指定できます。例:
kube-hunter --report json --dispatch http
利用可能なディスパッチ方法は以下の通りです。
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のアーキテクチャ設計により、以下の「コアハンター/クラス」は常に登録されます（カスタムハンティングを使用する場合も同様）:
kube-hunterのデプロイ方法は3つあります:
マシン上で直接kube-hunterを実行できます。
以下のインストールが必要です:
インストール:
pip install kube-hunter
実行:
kube-hunter
リポジトリをクローン:
git clone https://github.com/aquasecurity/kube-hunter.git
モジュールの依存関係をインストール（Virtual Environment内で行うことを推奨）:
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で表示可能なレポートにアップロードするための（クローズドソースの）レポートプラグインが含まれています。aquasec/kube-hunter コンテナの実行とレポートデータのアップロードには、追加の利用規約が適用されることに注意してください。このリポジトリの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を侵害できた場合に何ができるかという視点が得られます。これにより、通常よりもはるかに多くの脆弱性が明らかになる可能性があります。
サンプルの 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> でテスト結果を表示コントリビューションガイドラインを読むには、 こちらをクリック
このリポジトリは Apache License 2.0 の下で利用可能です。