Posted inセキュリティ

Kubernetes セキュリティ監査：kube-bench と kube-hunter でクラスターを堅牢化する

Security tutorial - IT technology blog
Security tutorial - IT technology blog

デフォルト設定を超えた Kubernetes のセキュリティ対策

Kubernetes クラスターを立ち上げるのは簡単な部分です。本当の課題は、デフォルトの設定が「堅牢さ」よりも「とりあえず動くこと」を優先していることに気づいたときから始まります。API サーバーが露出したままになっていたり、デフォルトのサービスアカウントトークンが使われていたりするチームを多く見てきました。これは単に、100以上あるセキュリティ設定のどれを有効にすべきか知らなかったためです。

監査プロセスを自動化するために、業界標準の2つのツール、kube-bench と kube-hunter を使用します。どちらもセキュリティに焦点を当てていますが、異なる角度からアプローチします。一方は設計図をチェックし、もう一方は鍵をこじ開けようとします。これらを組み合わせる方法を理解することが、真に堅牢な環境を構築するための秘訣です。

検査官 vs 攻撃者

クラスターを監査する際、私は「設定の健全性」と「アクティブな脆弱性」という2つの視点から見ています。

静的な設定監査 (kube-bench)

kube-bench は建物の検査官のようなものだと考えてください。クラスターの設定を Center for Internet Security (CIS) の Kubernetes ベンチマークと比較します。etcd データベースが保存時に暗号化されているか、API サーバーが --anonymous-auth を許可しているかといった、具体的な不備をチェックします。これは、インストール時にマニュアル通りに設定したかを確認するチェックリスト主導のツールです。

アクティブな脆弱性スキャン (kube-hunter)

kube-hunter は、どちらかというとペネトレーションテスター（侵入テスト担当者）のように動作します。設定ファイルの内容ではなく、実際に侵入できるかどうかに注目します。10250番ポート (Kubelet API) や 2379番ポート (etcd) などの開いているポートを調査し、設定ミスのダッシュボードを探します。外部から実行してハッカーの視点を確認することも、Pod の内部から実行して悪意のあるコンテナがネットワーク内を横方向に移動しようとする状況をシミュレートすることもできます。

メリットとデメリット

kube-bench

  • メリット: コンプライアンスのゴールドスタンダードです。クライアントから CIS レポートを求められた場合、このツールは正確な「合格/不合格」のデータを提供します。さらに、各不合格項目を修正するための具体的なシェルコマンドも提示してくれます。
  • デメリット: ディスク上の情報しか見ません。アプリケーションコードのゼロデイ脆弱性や、潜んでいるランタイムの脅威を検出することはできません。

kube-hunter

  • メリット: 現実世界の攻撃パスを明らかにします。プロセス自体が安全でないデフォルト設定で動作している場合など、静的なチェックでは見落とされがちな認証なしの Kubelet ポートといった重大なリスクを特定します。
  • デメリット: 出力がノイズになることがあります。一部の検出結果は、即座の脅威ではない「低リスク」の情報漏洩（バージョン番号など）である可能性があり、結果をフィルタリングするために人間の目が必要になります。

プロフェッショナルのワークフロー

ハイブリッドなアプローチをお勧めします. 初期セットアップ時やメジャーバージョンのアップグレード後には kube-bench を実行します。これにより、コアインフラストラクチャのコンプライアンスを維持できます。その後、kube-hunter を CI/CD パイプラインに統合するか、週次の cron ジョブとして実行します。これにより、新しいデプロイや設定のドリフトによって生じたセキュリティの退行を捉えることができます。

これらの問題を修正する際、サービスアカウント用に強力でユニークなパスワードを生成する必要があることがよくあります。私はそのために、toolcraft.app のブラウザベースのパスワードジェネレーターを使用しています。ブラウザ上で完全に動作するため、機密性の高いキーがネットワーク経由で送信されることはありません。修復段階での資格情報の漏洩を防ぐためのちょっとした習慣です。

実装ガイド

ステップ 1: kube-bench を Job として実行する

クラスターを監査する最も信頼できる方法は、kube-bench を Kubernetes Job として実行することです。これにより、ホストのファイルシステムやコントロールプレーンのプロセスを検査するために必要な権限をツールに与えることができます。

# 監査用ジョブを作成する
cat <<EOF > kube-bench-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench
spec:
  template:
    spec:
      hostPID: true
      containers:
        - name: kube-bench
          image: aquasec/kube-bench:latest
          command: ["kube-bench"]
          volumeMounts:
            - name: var-lib-etcd
              mountPath: /var/lib/etcd
              readOnly: true
            - name: var-lib-kubelet
              mountPath: /var/lib/kubelet
              readOnly: true
            - name: etc-systemd
              mountPath: /etc/systemd
              readOnly: true
            - name: etc-kubernetes
              mountPath: /etc/kubernetes
              readOnly: true
      restartPolicy: Never
      volumes:
        - name: var-lib-etcd
          hostPath:
            path: /var/lib/etcd
        - name: var-lib-kubelet
          hostPath:
            path: /var/lib/kubelet
        - name: etc-systemd
          hostPath:
            path: /etc/systemd
        - name: etc-kubernetes
          hostPath:
            path: /etc/kubernetes
EOF

# 監査を実行する
kubectl apply -f kube-bench-job.yaml

Pod が終了したらログを確認します。マスターノード and ワーカーノードの詳細な分析結果が表示されます。特に [FAIL] とマークされている箇所に注目してください。

ステップ 2: 迅速な修復

kube-bench レポートの最も優れた点は「Remediations（修復方法）」セクションです。単に問題を指摘するだけでなく、解決策も提示します。例えば、1.2.19 Ensure that the --insecure-port argument is set to 0 とフラグが立てられた場合、その穴を塞ぐためにどのマニフェストファイルを編集すべきか正確に教えてくれます。

ステップ 3: 脆弱性の探索

設定ファイルが保護されたら、次は境界のテストです。通常、まずはワークステーションからリモートスキャンを実行し、インターネットから何が見えるかを確認します。

# Docker によるリモートスキャン
docker run -it --rm aquasec/kube-hunter --remote 1.2.3.4 # クラスター IP に置き換えてください

「内部脅威」をシミュレートするには、Pod レベルのスキャンを実行します。これにより、アプリケーションの1つが侵害された場合に何が起こるかを確認できます。

kubectl run kube-hunter --image=aquasec/kube-hunter --restart=Never -- --pod-scan

ステップ 4: 境界の堅牢化

レポートを確認したら、修正の優先順位を決めます。まずは kube-hunter で検出された「High（高）」重要度の項目から着手しましょう。多くの場合、これには API サーバーのマニフェストの更新、/metrics へのアクセスの制限、Pod が Kubelet API と通信するのを防ぐためのネットワークポリシーの実装などが含まれます。堅牢化は短距離走ではなくマラソンです。これらのツールを毎月実行することで、些細な設定のずれが重大な侵害につながらないようにしましょう。

Share:
Tags: