CVE-2020-8566 の理解と緩和: Ceph クラスター管理者の資格情報が kube-controller-manager ログへ漏洩

本文の内容は、2020年10月26日にKaizhe Huangが投稿したブログ(https://sysdig.com/blog/falco-cve-2020-8566-ceph/)を元に日本語に翻訳・再構成した内容となっております。

Kubernetes のソースコードを監査していたところ、最近 Kubernetes に機密データの漏洩を引き起こす可能性のある問題 (CVE-2020-8566) を発見しました。

ceph クラスターをストレージクラスとして使用し、kube-controller-manager でロギングレベルを 4 以上に設定して Kubernetes クラスターを作成した場合、CVE-2020-8566 の影響を受ける可能性があります。その場合、ceph のユーザー資格情報が cloud-controller-manager のログに漏洩してしまいます。このログにアクセスできる人は誰でもログを読むことができ、あなたのcephユーザになりすまし、保存されているデータを危険にさらすことができます。

この記事では、この問題を理解し、Kubernetesのどの部分が影響を受けるのか、そしてそれを緩和する方法について説明します。

予備的な内容

まずは、問題の原因となる、または問題の影響を受ける Kubernetes コンポーネントをリストアップしてみましょう。

Kube-controller-manager：Kubernetes コントローラマネージャーは、状態の更新を監視し、それに応じてクラスターに変更を加えるコアコントローラの組み合わせです。現在Kubernetesに同梱されているコントローラには以下のものがあります。

• Replication controller：コントローラオブジェクトを複製するために、システム上の正しい数のポッドを維持します。
• Node controller：ノードの変更を監視します。
• Endpoints controller：サービスオブジェクトとポッドオブジェクトを結合するためのエンドポイントオブジェクトを生成します。
• Service accounts and token controller：ネームスペースのサービスアカウントとトークンを管理します。

Secret: Kubernetes Secretsを使用すると、パスワード、OAuthトークン、sshキーなどの機密情報を保存して管理することができます。機密情報をSecretに保存することは、Podの定義やコンテナイメージにそのまま入れるよりも安全で柔軟性があります。

StorageClass：StorageClass は、管理者が提供するストレージの「クラス」を記述する方法を提供します。異なるクラスは、サービス品質レベル、バックアップポリシー、またはクラスタ管理者が決定する任意のポリシーに対応しています。

PersistentVolumeClaim: PersistentVolumeClaim (PVC)は、ユーザーによるストレージの要求です。ポッドに似ています。Podはノードリソースを消費し、PVCはPVリソースを消費します。Podは特定のレベルのリソース（CPUとメモリ）を要求できます。クレームは特定のサイズとアクセスモードを要求できます。

CVE-2020-8566の問題

CVE-2020-8563の問題点は以下の通りです。ストレージとして ceph クラスターを使用している Kubernetes クラスターがあり、kube-controller-manager のログレベルが 4 以上に設定されている場合、ceph ストレージクラスを参照する PVC が作成されると、vSphere の資格情報が cloud-controller-manager によってログに記録されます。

以下の録画では、漏洩した ceph クラスタ管理者の資格情報を取得する方法を示しています。

CVE-2020-8566 の影響

CVSS システムによると、中程度の深刻度として 5.3 のスコアを付けています。

これは、秘密漏洩を起こすために、攻撃者が kube-controller-manager のログレベルを 4 以上に設定する方法を見つける必要があることを考慮に入れています。このエクスプロイトはコンポーネントが存在するノードへのアクセス権限を必要とするため、深刻度は中程度です。

しかし、最初から kube-controller-manager のログレベルが 4 以上に設定されていたとしたらどうでしょうか？例えば、誰かがトラブルシューティングを支援するために (kubeadm 経由で) ログの冗長度を上げたとします。

そうすると、このCVEスコアの深刻度が7.7と高深刻度として上昇します。

この場合、特別なアクセスは必要ありません。kube-provider-controller のログにアクセスできる人は誰でも秘密を見ることができます。

kube-provider-controllerのログにアクセスできる人は、ログ内の秘密を閲覧することができます。

要約すると、影響を受けるKubernetesクラスターは以下のような構成となります。

1. Kubernetes クラスターでストレージに ceph クラスターを使用しています。
2. kube-controller-managerのログレベルが4以上に設定されている。
3. cephクラスタからストレージクラスを参照するPVCが少なくとも1つ作成されている。

全体的に、ログアーカイブにクリアテキストで保存されている秘密は、ログアーカイブにアクセスできるユーザーやアプリケーションに公開される可能性があるため、危険です。管理者の資格情報にアクセスできる人は、cephクラスターの管理者ユーザに代わって行動することができます。

CVE-2020-8566 の緩和

このCVEの影響を受けている場合は、直ちにceph管理者パスワードを更新してください。期限切れの資格情報を使用して ceph ストレージクラスターにアクセスすることはできません。

kube-controller-manager のログレベルがデフォルト値に設定されていたとしても、kube-apiserver や kube-controller-manager のような Kubernetes コンポーネントが冗長なログで起動している可能性があるかどうかをチェックする必要があります。

CNCFのインキュベーションプロジェクトであるFalcoは、クラウドネイティブ環境での異常なアクティビティの検出に役立ちます。以下のfalcoルールは、CVE-2020-8566の影響を受けているかどうかを検出するのに役立ちます。

- list: kube_controller_manager_image_list
  items:
  - "k8s.gcr.io/kube-controller-manager"
- macro: kube_controller_manager
  condition: (proc.name=kube-controller and container.image.repository in (kube_controller_manager_image_list))
- list: kube_apiserver_image_list
  items:
  - "k8s.gcr.io/kube-apiserver"
- macro: kube_apiserver
  condition: (proc.name=kube-apiserver and container.image.repository in (kube_apiserver_image_list))
# TODO: add more components like kube-proxy, kube-scheduler
- macro: kube_components
  condition: (kube_apiserver or kube_controller_manager)
# default log level is 2, any log level greater than 2 is considered verbose
- macro: verbose_log
  condition: ((evt.args contains "-v=" or evt.args contains "--v=") and not (evt.args contains "-v=0" or evt.args contains "-v=1" or evt.args contains "-v=2" or evt.args contains "--v=0" or evt.args contains "--v=1" or evt.args contains "--v=2"))
- rule: Kube Componentes Started with Verbose Log Level
  desc: Detected kube components like kube-apiserver, kube-proxy started with verbose log enabled
  condition: spawned_process and kube_components and verbose_log
  output: Kube components started with verbose log enabled (command=%proc.cmdline program=%proc.name container_id=%container.id image=%container.image.repository)
  priority: WARNING
  tags:

  - "process" 

このルールは、冗長なログから始まるKubernetesコンポーネントを検出します。

セキュリティイベントの出力は、Sysdig Secure (Falcoを使用しています)ではこのようになります。

まとめ

Kubernetes クラスターの頭脳である kube-apiserver や、Kubernetes クラスターに関する重要な情報をすべて保存している etcd を堅牢にするためのベストプラクティスに従っているかもしれません。しかし、CVE-2020-8566が私たちに教えてくれることが一つあるとすれば、それは、Kubernetesのすべてのコンポーネントを保護する必要があるため、それだけに留まるべきではないということです。

Sysdig Secure は、Kubernetes クラスターのベンチマークを行い、PCI や NIST などのセキュリティ基準に準拠しているかどうかを確認するのに役立ちます。今すぐお試しください。