famerico opened a new issue, #14662:
URL: https://github.com/apache/cloudstack/issues/14662
### 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 the separate SharedMountPoint issue).
### 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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
