0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@YasuhiroABE(Yasuhiro ABE)

Rook/Ceph v1.19でCVE-2025-30156に対応する

0
Posted at

はじめに

Rook/Cephのv1.19.8を利用しているバージョンをv1.19系の最新にしようと思ったら、CVEに関する情報が加わっていました。

通常の方法でアップグレードすると、ceph statusコマンドに次のような警告が表示されるようになります。

ceph -sコマンドに表示される警告の抜粋
Wed Sep  9 01:54:55 AM UTC 2026
  cluster:
    id:     6c105885-7cc6-4412-9812-ccbdf21a6519
    health: HEALTH_ERR
            9 auth client entities with insecure key types
            Monitors are configured to allow auth using insecure key types
            Monitors are configured to allow creation of insecure key types
            4 rotating auth service keys using insecure key types
            10 auth service entities with insecure key types

これに対応するためには次の文書に従ってアップグレードする必要があります。

この他に公式(rook.io)からRook/Cephの鍵システムについて、次の資料が提供されています。

この最後の資料では、HEALTH_WARNとなった状態からHEALTH_OKにするアラートを抑制する方法について記載があります。

環境

  • Kubernetes v1.35.4 (Kubespray v2.31.0)
  • Ubuntu 24.04.4 with linux-image-generic-hwe-24.04 (7.0.0-31.31~24.04.1)

この他に通常の6.8系のlinux-image-genericを利用しているサーバー環境もあり、同様の手順を適用しています。

6.x系列のカーネルを利用している場合には、Linuxカーネルバージョンを意識する必要がありますが、執筆時点のRook v1.19.11では特に違いを意識する必要はありません。Rook v1.20系を適用するとCSIプラグインがaes256k対応版に更新されるため、あらかじめLinuxカーネルを7.0系以上にしておくことをお勧めします。

作業の流れ

次の部分は公式ガイドを参照してください。

  • Rookのアップデート
    • Rook v1.19以前のバージョンを利用している場合は、v1.18のドキュメントに従ってRook/Cephをv1.18.11にアップデートする。(この時Cephはv19.2.3になっているはず)
    • Rook v1.18.11やv1.19.xを利用している場合は、最新のv1.19.11にアップデートする。 (ドキュメントによってはv1.19.10と書かれているが、そこはv1.19系の最新版に読み替える)
  • Cephのアップデート
    • この時点でCephはv19.2.3かv19.2.4になっているはず
    • ドキュメントに従って、Cephのバージョンをv19.2.6にアップグレードする

ここでは最後のCephClusterの編集の部分以降について説明していきます。

  • CephClusterリソースを編集し、keyGeneration: を2にする

CephClusterリソースを編集する

この手順を実施するには、Rookのバージョンがv1.19.10以上で、かつ、Cephが19.2.6以上であることが必要です。

現状の確認

私の環境では次のようになっています。

$ sudo kubectl -n rook-ceph get cephcluster

NAME        DATADIRHOSTPATH   MONCOUNT   AGE      PHASE   MESSAGE                        HEALTH       EXTERNAL   FSID
rook-ceph   /var/lib/rook     3          2y215d   Ready   Cluster created successfully   HEALTH_ERR              6c105885-7cc6-4412-9812-ccbdf21a6519

まず現状の設定を確認しておきます。

$ sudo kubectl -n rook-ceph get CephCluster rook-ceph -o yaml

spec:
  security:
    keyRotation:
      enabled: false
    kms: {}
status:
  cephx:
    admin: {}
    cephExporter: {}
    crashCollector: {}
    csi: {}
    mgr:
      keyType: aes
    mon: {}
    osd:
      keyType: aes
    rbdMirrorPeer: {}

変更内容を検討する

元のYAMLファイルの.spec.securityの設定に、cephxの項目を追加します。

既存の設定は残しつつcephx用の設定を追加する
spec:
  security:
    keyRotation:
      enabled: false
    kms: {}
    cephx:
      daemon:
        keyRotationPolicy: KeyGeneration
        keyGeneration: 2

これまでの更新方法によって、.spec.security.keyRotationが設定されていない場合があります。
その場合でもcephxの項目だけを追加しています。

ドキュメントにはコメントもあってkeyGeneration:の値は設定値よりも大きければよく、1でも問題ないように思えたのですが、後で設定したcephobjectstores(cephos)でkeyGeneration: 1が設定済みの状態でした。

keyGenerationは2以上であれば問題ないと思いますが、関連するリソースを確認して、既定値よりも大きな整数を指定することが必要です。

リソースの編集

kubectl patchコマンドを利用する方法ありますが、ここではeditを使っていきます。

$ sudo kubectl -n rook-ceph edit CephCluster rook-ceph

変更が終ると、自動的に鍵情報が更新されていきます。

更新最中の問題

鍵が置き換わっている途中で、ceph statusを実行しようとしていると、Pod間の通信でエラーになります。

ceph statusを実行しようとして発生するエラー
$ ceph_status
Wed Sep  9 02:17:54 AM UTC 2026
[errno 13] RADOS permission denied (error connecting to the cluster)
command terminated with exit code 13

公式のガイドには最新版では自動的に接続が修復されるとの記述がありますが、v1.18.11やv1.19.8からのアップデートで確認した範囲では手動でPodを再起動する必要がありました。

この場合にはtools Podを再起動します。

$ sudo kubectl -n rook-ceph delete pod rook-ceph-tools-645f48b9bc-pf2wl
pod "rook-ceph-tools-645f48b9bc-pf2wl" deleted from rook-ceph namespace

自動的に新しいPodが起動するので、ceph statusを実行します。

$ sudo kubectl -n rook-ceph exec -it ... -- ceph status
Wed Sep  9 02:20:00 AM UTC 2026
  cluster:
    id:     6c105885-7cc6-4412-9812-ccbdf21a6519
    health: HEALTH_ERR
            7 auth client entities with insecure key types
            Monitors are configured to allow auth using insecure key types
            Monitors are configured to allow creation of insecure key types
            4 rotating auth service keys using insecure key types
            8 auth service entities with insecure key types

時間はかかりますが、鍵の更新が進んでいきます。

更新が完了した時の状態

しばらく落ち着くまで時間がかかりますが、最終的に次のようになりました。

Wed Sep  9 02:32:36 AM UTC 2026
  cluster:
    id:     6c105885-7cc6-4412-9812-ccbdf21a6519
    health: HEALTH_WARN
            5 auth client entities with insecure key types
            Monitors are configured to allow auth using insecure key types
            Monitors are configured to allow creation of insecure key types
            4 rotating auth service keys using insecure key types

ceph health detailの出力は次のようになっています。

HEALTH_WARN 5 auth client entities with insecure key types; Monitors are configured to allow auth using insecure key types; Monitors are configured to allow creation of insecure key types; 4 rotating auth service keys using insecure key types
[WRN] AUTH_INSECURE_CLIENT_KEY_TYPE: 5 auth client entities with insecure key types
    entity client.csi-cephfs-node using insecure key type: aes
    entity client.csi-cephfs-provisioner using insecure key type: aes
    entity client.csi-rbd-node using insecure key type: aes
    entity client.csi-rbd-provisioner using insecure key type: aes
    entity client.rbd-mirror-peer using insecure key type: aes
[WRN] AUTH_INSECURE_KEYS_ALLOWED: Monitors are configured to allow auth using insecure key types
    insecure cipher aes allowed for auth
[WRN] AUTH_INSECURE_KEYS_CREATABLE: Monitors are configured to allow creation of insecure key types
[WRN] AUTH_INSECURE_ROTATING_SERVICE_KEY_TYPE: 4 rotating auth service keys using insecure key types
    rotating service keys for mon using insecure key type: aes
    rotating service keys for mds using insecure key type: aes
    rotating service keys for osd using insecure key type: aes
    rotating service keys for mgr using insecure key type: aes

今回の手順ではここまでで正常に完了しています。

CephClusterのステータスについて

最初に確認したcephcluster/rook-cephリソースのstatus:は次のようになっていました。

status:
  cephx:
    admin:
      keyCephVersion: 19.2.6-0
      keyGeneration: 2
    cephExporter:
      keyCephVersion: 19.2.6-0
      keyGeneration: 2
    crashCollector:
      keyCephVersion: 19.2.6-0
      keyGeneration: 2
    csi: {}
    mgr:
      keyCephVersion: 19.2.6-0
      keyGeneration: 2
      keyType: aes256k
    mon:
      keyCephVersion: 19.2.6-0
      keyGeneration: 2
    osd:
      keyCephVersion: 19.2.6-0
      keyGeneration: 2
      keyType: aes256k
    rbdMirrorPeer: {}

HEALTH_OKへの変更方法について

この手順は実施する必要はないと思いますが、アラートが上がったままになることが問題であれば、公式ガイドに従って無視することができます。

cephcluster/rook-cephリソースの修正方法
spec:
  healthCheck:
    muteHealthWarning:
      AUTH_INSECURE_ROTATING_SERVICE_KEY_TYPE:
        policy: mute
      AUTH_INSECURE_CLIENT_KEY_TYPE:
        policy: mute
      AUTH_INSECURE_KEYS_ALLOWED:
        policy: mute
      AUTH_INSECURE_KEYS_CREATABLE:
        policy: mute

修正してから数分すると、ceph statusの表示が次のようになりました。

Wed Sep  9 06:16:27 AM UTC 2026
  cluster:
    id:     6c105885-7cc6-4412-9812-ccbdf21a6519
    health: HEALTH_OK
            (muted: AUTH_INSECURE_CLIENT_KEY_TYPE AUTH_INSECURE_KEYS_ALLOWED AUTH_INSECURE_KEYS_CREATABLE AUTH_INSECURE_ROTATING_SERVICE_KEY_TYPE)

まとめ

v1.19.11ではCSIのバージョンがまだv3.16系なので、全てにaes256kを指定することはできません。

またCSIでaes256kを設定するためには、Linuxのカーネルが7.0系以上であることが必要とされています。

Ubuntu 24.04ではHWEカーネルを利用すれば、片方の要件は満せるので、v1.20.xを適用することでアップデートされると思われますが、検証できるのはもう少し先になりそうです。

Rook/Ceph v1.20.7を確認したところcephcsiイメージのバージョンはv3.17.1でした。

これを適用した時に自動でCSIの鍵タイプがaes256kになるのかは確認できていません。

安全のためにcsiに対して明示的にaesを指定することもできます。

spec:
  security:
    cephx:
      csi:
        keyType: aes
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?