[KVM] Encrypted disk offering: volume created on a manually selected primary storage pool (NFS and SharedMountPoint) is not encrypted (no LUKS, no error)

Đang mở
  • Có gì không ổn?
#14,662 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@weizhouapache đang làm issue này rồi.

Từ ngày 10/11/2026.

  • #14667 của @weizhouapache — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
java
Lĩnh vực
backend, infrastructure, security

Hướng nghiên cứu

Start by tracing volume creation for requests that specify storageid, then compare that path with allocation by storage tag, using the reported KVM storage and encryption logs as clues. Check how the selected pool type and encryption metadata reach volume creation and attach. Done means manual pool selection either creates a LUKS volume with a stored passphrase or returns a clear error; linked PR #14667 is already open.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

problem

When a volume is created from a disk offering with encrypt=true and the primary storage pool is passed explicitly (storageid), the volume is not encrypted. There is no error: the volume is created and attached normally, but it is a plain qcow2 image with no LUKS header and volumes.passphrase_id is NULL. The same disk offering used with allocation by storage tag produces a LUKS volume.

The silent behavior is the main concern: an operator who picks the pool manually believes the data is encrypted at rest and it is not.

The same happens on a SharedMountPoint (iSCSI-backed) pool: manual selection produces a plain image with no error, while allocation by tag on that pool fails at attach (see #14663).

versions
  • Apache CloudStack 4.22.1.1
  • Hypervisor: KVM, host reports host.volume.encryption
  • Volume format: qcow2
  • Primary storage: NFS pool (NetworkFilesystem) and SharedMountPoint pool (iSCSI-backed)
The steps to reproduce the bug
  1. Use a KVM host that supports volume encryption.
  2. Create a disk offering with encryption enabled and a storage tag that matches an NFS pool.
  3. Create a volume from that offering with allocation by tag. Result: LUKS volume (works as expected).
  4. Create a second volume from the same kind of encrypted offering (no storage tag), passing the NFS pool explicitly:
    createVolume diskofferingid=<encrypted offering> storageid=<nfs pool id> ...
  5. Attach it to a VM. No error is returned.
  6. Check the result: volumes.passphrase_id is NULL, and the agent log shows no encryption option in the create command and no <encryption> element in the disk XML (excerpts below).
  7. Repeating steps 4 to 6 on a SharedMountPoint (iSCSI-backed) pool gives the same result: passphrase_id NULL, plain qcow2, no error. We ran the manual-selection test 11 times with two disk offerings on both pool types, with the same result every time. In one earlier unplanned run (outside our test protocol) a manual selection on the SharedMountPoint pool produced a volume with a passphrase and a visible attach failure; we could not reproduce it in 3 deliberate repeats.

Allocation by tag (works), agent DEBUG log:

DEBUG [utils.script.Script] Executing command [qemu-img create --object secret,file=<keyfile>,id=sec0 -o encrypt.format=luks,preallocation=off,encrypt.key-secret=sec0 -f qcow2 /mnt/50e883ef-d010-3cb7-95fa-30dc5faeae7d/a4dcb52d-6bbc-4edb-afe8-f6a9f8ef902f 5368709120 ].
DEBUG [kvm.storage.KVMStorageProcessor] Attaching device: <disk  device='disk' type='file'>
<driver name='qemu' type='qcow2' cache='none' />
<source file='/mnt/50e883ef-d010-3cb7-95fa-30dc5faeae7d/a4dcb52d-6bbc-4edb-afe8-f6a9f8ef902f'/>
<target dev='vde' bus='virtio'/>
<serial>a4dcb52d6bbc4edbafe8</serial>
<encryption format='luks'>
<secret type='passphrase' uuid='2b94d58b-0848-3559-b193-f1d5846dadfc' />
</encryption>
</disk>

Manual pool selection (silent failure), agent DEBUG log:

DEBUG [utils.script.Script] Executing command [qemu-img create -o preallocation=off -f qcow2 /mnt/50e883ef-d010-3cb7-95fa-30dc5faeae7d/aeb9b9fa-3b24-4a65-9664-ff51cf2f7753 5368709120 ].
DEBUG [kvm.storage.KVMStorageProcessor] Attaching device: <disk  device='disk' type='file'>
<driver name='qemu' type='qcow2' cache='none' />
<source file='/mnt/50e883ef-d010-3cb7-95fa-30dc5faeae7d/aeb9b9fa-3b24-4a65-9664-ff51cf2f7753'/>
<target dev='vde' bus='virtio'/>
<serial>aeb9b9fa3b244a659664</serial>
</disk>
DEBUG [cloud.agent.Agent] Seq 1-1174595077813569846: [...] "org.apache.cloudstack.storage.command.AttachAnswer":{ [...] "result":"true" [...] }

Manual pool selection on the SharedMountPoint (iSCSI-backed) pool, agent DEBUG log: volume created through libvirt (no qemu-img create, no encryption option), attached without <encryption>, and the attach succeeds. The database shows passphrase_id NULL and encrypt_format NULL for the volume.

INFO  [kvm.storage.LibvirtStorageAdaptor] Attempting to create volume f279db6b-d6fd-4339-943c-ad01455af989 (SharedMountPoint) in pool 0d3db4e4-0e9a-4421-a5a4-72e9770d27c1 with size (5.00 GB) 5368709120
DEBUG [kvm.storage.LibvirtStorageAdaptor] <volume>
<name>f279db6b-d6fd-4339-943c-ad01455af989</name>
<capacity>5368709120</capacity>
<target>
<format type='qcow2'/>
<permissions><mode>0744</mode></permissions></target>
</volume>
DEBUG [cloud.agent.Agent] Seq 1-1174595077813576597: [...] "org.apache.cloudstack.storage.command.CreateObjectAnswer": [...] "result":"true" [...]
DEBUG [kvm.storage.KVMStorageProcessor] Attaching physical disk /mnt/<iscsi-pool>/f279db6b-d6fd-4339-943c-ad01455af989 with format qcow2
DEBUG [kvm.storage.KVMStorageProcessor] Attaching device: <disk  device='disk' type='file'>
<driver name='qemu' type='qcow2' cache='none' />
<source file='/mnt/<iscsi-pool>/f279db6b-d6fd-4339-943c-ad01455af989'/>
<target dev='vdc' bus='virtio'/>
<serial>f279db6bd6fd4339943c</serial>
</disk>
DEBUG [cloud.agent.Agent] Seq 1-1174595077813576599: [...] "org.apache.cloudstack.storage.command.AttachAnswer": [...] "poolType":"SharedMountPoint", [...] "result":"true" [...]
What to do about it?

The decision to encrypt should not depend on how the pool was chosen. Either apply LUKS (and store the passphrase) on the manual-pool path, or fail the request with a clear error.

Note: PR #13228 changes several getPassphraseId() != null checks to isEncrypted() (which also considers encryptFormat). We have not verified that it affects this scenario, so it may or may not be related.

Ngôn ngữ chính
Java
Star
3.1k
Fork
1.4k
Merge trung bình
7 ngày 16 giờ
Pull request đã merge (30 ngày)
15

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/cloudstack

Tất cả issue của apache/cloudstack

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.