[cinder/barbican] LUKS encryption for mounted disk - how to decrypt cinder volume
Hi All, I have a question about the possible decryption of LUKS volume. I'm testing currently barbican+cinder, but I'm just wondering if there is a way, to somehow decrypt my LUKS volume with payload generated by a barbican. Is there any procedure for that? I was doing it by myself, but somehow it doesn't work and I got an error: [TEST]root@barbican-01:/usr/lib/python3/dist-packages# barbican secret get --payload --payload_content_type application/octet-stream http://controller.test:9311/v1/secrets/76631940-9ab6-4b8c-9481-e54c3ffdbbfe +---------+--------------------------------------------------------------------------------------------------------+ | Field | Value | +---------+--------------------------------------------------------------------------------------------------------+ | Payload | b'\xbf!i\x97\xf4\x0c\x12\xa4\xfe4\xf3\x16C\xe8@\xdc\x0f\x9d+:\x0c7\xa9\xab[\x8d\xf2\xf1\xae\r\x89\xdc' | +---------+--------------------------------------------------------------------------------------------------------+ cryptsetup luksOpen /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f my-volume Enter passphrase for /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f: *<passphrase from payload>* No key available with this passphrase. I thought that above issue can be related to encoding, so I took payload value directly from vault and use it as a key-file, but problem is exactly the same(my encrypted volume is the last volume list by domblklist option): vault kv get secret/data/e5baa518207e4f9db4810988d22087ce | grep value | awk -F'value:' '{print $2}' 4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d] [TEST]root@comp-02:~# cat bbb 4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d [TEST]root@comp-02:~# cat bbb | base64 -d > pass2 [TEST]root@comp-02:~# cat pass2 ▒▒▒▒▒▒▒^<▒N▒▒▒▒~پ5▒▒▒▒▒▒▒z߾▒▒▒▒~▒▒▒▒▒n▒▒▒▒▒]▒[TEST]root@comp-02:~# [TEST]root@comp-02:~# virsh domblklist instance-00000da8 Target Source ------------------------------------------------ vda /dev/dm-17 vdb /dev/disk/by-id/wwn-0x6e00084100ee7e7e74623bd3000036bc vdc /dev/dm-16 vde /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f vdf /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 [TEST]root@comp-02:~# udisksctl unlock -b /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 --key-file pass2 Error unlocking /dev/dm-21: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/dm-21: Failed to activate device: Operation not permitted [TEST]root@comp-02:~# cryptsetup luksOpen /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 my-volume --master-key-file=pass2 Volume key does not match the volume. I see that nova/cinder and barbican are doing this stuff somehow so I strongly believe there is a way to decrypt this manually. Maybe I’m doing something wrong in my testing-steps. Thanks in advance for any help here! Unfortunately, I haven’t found any materials on how to do this. Best regards, Jan
On 09-02-21 12:48:38, Jan Wasilewski wrote:
Hi All,
I have a question about the possible decryption of LUKS volume. I'm testing currently barbican+cinder, but I'm just wondering if there is a way, to somehow decrypt my LUKS volume with payload generated by a barbican. Is there any procedure for that? I was doing it by myself, but somehow it doesn't work and I got an error:
[TEST]root@barbican-01:/usr/lib/python3/dist-packages# barbican secret get --payload --payload_content_type application/octet-stream http://controller.test:9311/v1/secrets/76631940-9ab6-4b8c-9481-e54c3ffdbbfe +---------+--------------------------------------------------------------------------------------------------------+ | Field | Value | +---------+--------------------------------------------------------------------------------------------------------+ | Payload | b'\xbf!i\x97\xf4\x0c\x12\xa4\xfe4\xf3\x16C\xe8@\xdc\x0f\x9d+:\x0c7\xa9\xab[\x8d\xf2\xf1\xae\r\x89\xdc' | +---------+--------------------------------------------------------------------------------------------------------+
cryptsetup luksOpen /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f my-volume Enter passphrase for /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f: *<passphrase from payload>* No key available with this passphrase.
I thought that above issue can be related to encoding, so I took payload value directly from vault and use it as a key-file, but problem is exactly the same(my encrypted volume is the last volume list by domblklist option):
vault kv get secret/data/e5baa518207e4f9db4810988d22087ce | grep value | awk -F'value:' '{print $2}' 4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d]
[TEST]root@comp-02:~# cat bbb 4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d [TEST]root@comp-02:~# cat bbb | base64 -d > pass2 [TEST]root@comp-02:~# cat pass2 ▒▒▒▒▒▒▒^<▒N▒▒▒▒~پ5▒▒▒▒▒▒▒z߾▒▒▒▒~▒▒▒▒▒n▒▒▒▒▒]▒[TEST]root@comp-02:~# [TEST]root@comp-02:~# virsh domblklist instance-00000da8 Target Source ------------------------------------------------ vda /dev/dm-17 vdb /dev/disk/by-id/wwn-0x6e00084100ee7e7e74623bd3000036bc vdc /dev/dm-16 vde /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f vdf /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 [TEST]root@comp-02:~# udisksctl unlock -b /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 --key-file pass2 Error unlocking /dev/dm-21: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/dm-21: Failed to activate device: Operation not permitted [TEST]root@comp-02:~# cryptsetup luksOpen /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 my-volume --master-key-file=pass2 Volume key does not match the volume.
I see that nova/cinder and barbican are doing this stuff somehow so I strongly believe there is a way to decrypt this manually. Maybe I’m doing something wrong in my testing-steps. Thanks in advance for any help here! Unfortunately, I haven’t found any materials on how to do this.
Yeah this is thanks to a long standing peice of technical debt that I've wanted to remove for years but I've never had to the change to. The tl;dr is that os-brick and n-cpu both turn the associated symmetric key secret into a passphrase using the following logic, ultimately calling binascii.hexlify: https://github.com/openstack/nova/blob/944443a7b053957f0b17a5edaa1d0ef14ae48... https://github.com/openstack/os-brick/blob/ec70b4092f649d933322820e300326956... I'm sure I've written up the steps to manually decrypt a cinder volume using these steps before but I can't seem to find them at the moment. I'll try to find some time to write these up again later in the week. Obviously it goes without saying that c-vol/c-api should be creating a passphrase secret for LUKS encrypted volumes to avoid this madness. Cinder creating and associating symmetric keys with encrypted volumes when used with Barbican https://bugs.launchpad.net/cinder/+bug/1693840 -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
Thank you for a nice description of how everything is organized. It is much easier to understand the full workflow.
I'll try to find some time to write these up again later in the week. That would be great, I will try to do this by myself, but I'm wondering if it's possible to do "all magic" directly from a payload that is visible from barbican CLI.
Anyway, I checked also related conversation at openstack-lists and I'm wondering about this part: http://lists.openstack.org/pipermail/openstack-dev/2017-May/117470.html Is there a way to replace the compromised LUKS passphrase with the current implementation of barbican? I was trying to do this by myself but without luck. I'm also wondering if there is a procedure that can help here(if you know?) Thanks in advance. Best regards, Jan wt., 9 lut 2021 o 23:12 Lee Yarwood <lyarwood@redhat.com> napisał(a):
On 09-02-21 12:48:38, Jan Wasilewski wrote:
Hi All,
I have a question about the possible decryption of LUKS volume. I'm testing currently barbican+cinder, but I'm just wondering if there is a way, to somehow decrypt my LUKS volume with payload generated by a barbican. Is there any procedure for that? I was doing it by myself, but somehow it doesn't work and I got an error:
[TEST]root@barbican-01:/usr/lib/python3/dist-packages# barbican secret get --payload --payload_content_type application/octet-stream
http://controller.test:9311/v1/secrets/76631940-9ab6-4b8c-9481-e54c3ffdbbfe
+---------+--------------------------------------------------------------------------------------------------------+
| Field | Value |
+---------+--------------------------------------------------------------------------------------------------------+
| Payload | b'\xbf!i\x97\xf4\x0c\x12\xa4\xfe4\xf3\x16C\xe8@ \xdc\x0f\x9d+:\x0c7\xa9\xab[\x8d\xf2\xf1\xae\r\x89\xdc' |
+---------+--------------------------------------------------------------------------------------------------------+
cryptsetup luksOpen
my-volume Enter passphrase for /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f: *<passphrase from payload>* No key available with this passphrase.
I thought that above issue can be related to encoding, so I took payload value directly from vault and use it as a key-file, but problem is exactly the same(my encrypted volume is the last volume list by domblklist
/dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f option):
vault kv get secret/data/e5baa518207e4f9db4810988d22087ce | grep value | awk -F'value:' '{print $2}'
4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d]
[TEST]root@comp-02:~# cat bbb
4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d
[TEST]root@comp-02:~# cat bbb | base64 -d > pass2 [TEST]root@comp-02:~# cat pass2 ▒▒▒▒▒▒▒^<▒N▒▒▒▒~پ5▒▒▒▒▒▒▒z߾▒▒▒▒~▒▒▒▒▒n▒▒▒▒▒]▒[TEST]root@comp-02:~# [TEST]root@comp-02:~# virsh domblklist instance-00000da8 Target Source ------------------------------------------------ vda /dev/dm-17 vdb /dev/disk/by-id/wwn-0x6e00084100ee7e7e74623bd3000036bc vdc /dev/dm-16 vde /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f vdf /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 [TEST]root@comp-02:~# udisksctl unlock -b /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 --key-file pass2 Error unlocking /dev/dm-21: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/dm-21: Failed to activate device: Operation not permitted [TEST]root@comp-02:~# cryptsetup luksOpen /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 my-volume --master-key-file=pass2 Volume key does not match the volume.
I see that nova/cinder and barbican are doing this stuff somehow so I strongly believe there is a way to decrypt this manually. Maybe I’m doing something wrong in my testing-steps. Thanks in advance for any help here! Unfortunately, I haven’t found any materials on how to do this.
Yeah this is thanks to a long standing peice of technical debt that I've wanted to remove for years but I've never had to the change to.
The tl;dr is that os-brick and n-cpu both turn the associated symmetric key secret into a passphrase using the following logic, ultimately calling binascii.hexlify:
https://github.com/openstack/nova/blob/944443a7b053957f0b17a5edaa1d0ef14ae48...
https://github.com/openstack/os-brick/blob/ec70b4092f649d933322820e300326956...
I'm sure I've written up the steps to manually decrypt a cinder volume using these steps before but I can't seem to find them at the moment. I'll try to find some time to write these up again later in the week.
Obviously it goes without saying that c-vol/c-api should be creating a passphrase secret for LUKS encrypted volumes to avoid this madness.
Cinder creating and associating symmetric keys with encrypted volumes when used with Barbican https://bugs.launchpad.net/cinder/+bug/1693840
-- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
On 10-02-21 11:29:06, Jan Wasilewski wrote:
Thank you for a nice description of how everything is organized. It is much easier to understand the full workflow.
I'll try to find some time to write these up again later in the week. That would be great, I will try to do this by myself, but I'm wondering if it's possible to do "all magic" directly from a payload that is visible from barbican CLI.
Anyway, I checked also related conversation at openstack-lists and I'm wondering about this part: http://lists.openstack.org/pipermail/openstack-dev/2017-May/117470.html
Is there a way to replace the compromised LUKS passphrase with the current implementation of barbican? I was trying to do this by myself but without luck. I'm also wondering if there is a procedure that can help here(if you know?)
AFAIK the only way to do this at present is by retyping [1] the volume to a different encrypted volume type. That should result in a new volume using new secrets etc that for LUKSv1 volumes would mean a new passphrase. [1] https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=rety...
wt., 9 lut 2021 o 23:12 Lee Yarwood <lyarwood@redhat.com> napisał(a):
On 09-02-21 12:48:38, Jan Wasilewski wrote:
Hi All,
I have a question about the possible decryption of LUKS volume. I'm testing currently barbican+cinder, but I'm just wondering if there is a way, to somehow decrypt my LUKS volume with payload generated by a barbican. Is there any procedure for that? I was doing it by myself, but somehow it doesn't work and I got an error:
[TEST]root@barbican-01:/usr/lib/python3/dist-packages# barbican secret get --payload --payload_content_type application/octet-stream
http://controller.test:9311/v1/secrets/76631940-9ab6-4b8c-9481-e54c3ffdbbfe
+---------+--------------------------------------------------------------------------------------------------------+
| Field | Value |
+---------+--------------------------------------------------------------------------------------------------------+
| Payload | b'\xbf!i\x97\xf4\x0c\x12\xa4\xfe4\xf3\x16C\xe8@ \xdc\x0f\x9d+:\x0c7\xa9\xab[\x8d\xf2\xf1\xae\r\x89\xdc' |
+---------+--------------------------------------------------------------------------------------------------------+
cryptsetup luksOpen
my-volume Enter passphrase for /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f: *<passphrase from payload>* No key available with this passphrase.
I thought that above issue can be related to encoding, so I took payload value directly from vault and use it as a key-file, but problem is exactly the same(my encrypted volume is the last volume list by domblklist
/dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f option):
vault kv get secret/data/e5baa518207e4f9db4810988d22087ce | grep value | awk -F'value:' '{print $2}'
4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d]
[TEST]root@comp-02:~# cat bbb
4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d
[TEST]root@comp-02:~# cat bbb | base64 -d > pass2 [TEST]root@comp-02:~# cat pass2 ▒▒▒▒▒▒▒^<▒N▒▒▒▒~پ5▒▒▒▒▒▒▒z߾▒▒▒▒~▒▒▒▒▒n▒▒▒▒▒]▒[TEST]root@comp-02:~# [TEST]root@comp-02:~# virsh domblklist instance-00000da8 Target Source ------------------------------------------------ vda /dev/dm-17 vdb /dev/disk/by-id/wwn-0x6e00084100ee7e7e74623bd3000036bc vdc /dev/dm-16 vde /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f vdf /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 [TEST]root@comp-02:~# udisksctl unlock -b /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 --key-file pass2 Error unlocking /dev/dm-21: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/dm-21: Failed to activate device: Operation not permitted [TEST]root@comp-02:~# cryptsetup luksOpen /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 my-volume --master-key-file=pass2 Volume key does not match the volume.
I see that nova/cinder and barbican are doing this stuff somehow so I strongly believe there is a way to decrypt this manually. Maybe I’m doing something wrong in my testing-steps. Thanks in advance for any help here! Unfortunately, I haven’t found any materials on how to do this.
Yeah this is thanks to a long standing peice of technical debt that I've wanted to remove for years but I've never had to the change to.
The tl;dr is that os-brick and n-cpu both turn the associated symmetric key secret into a passphrase using the following logic, ultimately calling binascii.hexlify:
https://github.com/openstack/nova/blob/944443a7b053957f0b17a5edaa1d0ef14ae48...
https://github.com/openstack/os-brick/blob/ec70b4092f649d933322820e300326956...
I'm sure I've written up the steps to manually decrypt a cinder volume using these steps before but I can't seem to find them at the moment. I'll try to find some time to write these up again later in the week.
Obviously it goes without saying that c-vol/c-api should be creating a passphrase secret for LUKS encrypted volumes to avoid this madness.
Cinder creating and associating symmetric keys with encrypted volumes when used with Barbican https://bugs.launchpad.net/cinder/+bug/1693840
-- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
-- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
On 10-02-21 17:43:03, Lee Yarwood wrote:
On 10-02-21 11:29:06, Jan Wasilewski wrote:
Thank you for a nice description of how everything is organized. It is much easier to understand the full workflow.
I'll try to find some time to write these up again later in the week. That would be great, I will try to do this by myself, but I'm wondering if it's possible to do "all magic" directly from a payload that is visible from barbican CLI.
My thanks to gcharot for writing the following up downstream a while ago and highlighting some easy ways of achieving this. The following assumes that the volume is already mapped and connected to the localhost, in this case I'm just using the LVs used by the default LVM/iSCSI c-vol backend in my devstack env. It also assumes you have access to the secrets associated with the encrypted volume, by default admins do not. - Starting with an encrypted volume $ sudo qemu-img info --output=json /dev/stack-volumes-lvmdriver-1/volume-d4cc53db-6add-4c29-9f96-42a5498f8bd0 | jq .format "luks" - Fetch and store the key locally $ openstack secret get --payload_content_type 'application/octet-stream' http://192.168.122.208/key-manager/v1/secrets/6fd4f879-005d-4b7d-9e5f-2505f0... --file mysecret.key - Use dmcrypt to decrypt the device using the key as a passphrase $ yes $(hexdump -e '16/1 "%02x"' mysecret.key) | sudo cryptsetup luksOpen /dev/stack-volumes-lvmdriver-1/volume-d4cc53db-6add-4c29-9f96-42a5498f8bd0 volume-d4cc53db-6add-4c29-9f96-42a5498f8bd0 - This should leave you with the decrypted volume under /dev/mapper $ sudo qemu-img info /dev/mapper/volume-d4cc53db-6add-4c29-9f96-42a5498f8bd0 image: /dev/mapper/volume-d4cc53db-6add-4c29-9f96-42a5498f8bd0 file format: raw virtual size: 0.998 GiB (1071644672 bytes) disk size: 0 B Hope this helps! -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
Hi Lee, sorry for long delay in my response, but I wanted to fully test it and thanks to your draft I was able to decrypt my encrypted volume. Your procedure is well described, so I just collected all steps in one place and wanted to share in this conversation: Jan Wasilewski [image: Załączniki]11:04 (1 minutę temu) do mnie **Description:** As an admin, you would like to decrypt the volume, which is attached to compute node and check, that your barbican secret key is correct(i.e. customer is saying, that the barbican secret key doesn't work). This procedure describes, how you can simply test it. **Starting point:** Volume is encrypted and attached to an instance(instance has to be shutdown to make qemu commands operational). Our volume id is: ca8da832-a88d-4f91-ab2d-2bd3efbca4a3 **Procedure:** Log in to a compute node that is hosting your instance. List volumes attached to your instance: ``` [TEST]root@comp-09:/home/jwasilewski# virsh domblklist ec9081e4-e1e4-40a2-bf8c-c87c14b79d5a Target Source ------------------------------------------------ vda /dev/dm-29 vdb /dev/disk/by-id/wwn-0x6e00084100ee7e7e7fe79b5900003a89 ``` In our case vdb volume is an encrypted one. We can check it by qemu-img command: ``` [TEST]root@comp-09:/home/jwasilewski# qemu-img info /dev/disk/by-id/wwn-0x6e00084100ee7e7e7fe79b5900003a89 image: /dev/disk/by-id/wwn-0x6e00084100ee7e7e7fe79b5900003a89 file format: luks virtual size: 20G (21472739328 bytes) disk size: 0 encrypted: yes Format specific information: ivgen alg: plain64 hash alg: sha256 cipher alg: aes-256 uuid: 009f60f7-e871-4eac-88da-b274e80eb247 cipher mode: xts slots: [0]: active: true iters: 900838 key offset: 4096 stripes: 4000 [1]: active: false key offset: 262144 [2]: active: false key offset: 520192 [3]: active: false key offset: 778240 [4]: active: false key offset: 1036288 [5]: active: false key offset: 1294336 [6]: active: false key offset: 1552384 [7]: active: false key offset: 1810432 payload offset: 2097152 master key iters: 56302 ``` We would like to decrypt the volume. We need to retrieve symmetric key which is allocated to this volume from barbican. We need to find a secret store associated with our volume, so we have to login to OpenStack database and execute: ``` mysql> select * from volumes where id = 'ca8da832-a88d-4f91-ab2d-2bd3efbca4a3'\G *************************** 1. row *************************** created_at: 2021-02-12 13:41:40 updated_at: 2021-02-17 12:33:34 deleted_at: NULL deleted: 0 id: ca8da832-a88d-4f91-ab2d-2bd3efbca4a3 ec2_id: NULL user_id: wfoij24f0sdfs0934nkl project_id: 234sfds90klfgd093n host: cinder-01@huawei_backend#StoragePool001 size: 20 availability_zone: nova status: in-use attach_status: attached scheduled_at: 2021-02-12 13:41:40 launched_at: 2021-02-12 13:41:42 terminated_at: NULL display_name: encrypted-volume display_description: provider_location: {"huawei_sn": "2102352VVA10L2000001", "huawei_lun_id": "14985", "huawei_lun_wwn": "6e00084100ee7e7e7fe79b5900003a89"} provider_auth: NULL snapshot_id: NULL volume_type_id: 3129bdc2-6162-4729-9eab-d0c97db2335a source_volid: NULL bootable: 0 provider_geometry: NULL _name_id: NULL encryption_key_id: b13d2017-e3e5-4f5f-a836-918ec130dc0a migration_status: NULL replication_status: disabled replication_extended_status: NULL replication_driver_data: NULL consistencygroup_id: NULL provider_id: NULL multiattach: 0 previous_status: NULL cluster_name: NULL group_id: NULL service_uuid: 674de52f-1c9a-402f-88c9-6b79c91a4249 shared_targets: 1 1 row in set (0.00 sec) ``` So encryption_key_id is the value that we were looking for. Then we can simply get our secret store: ``` [TEST]root@zabbix-1:~# openstack secret get http://controller.tc.tester-pl.pl:9311/v1/secrets/b13d2017-e3e5-4f5f-a836-91... +---------------+----------------------------------------------------------------------------------------+ | Field | Value | +---------------+----------------------------------------------------------------------------------------+ | Secret href | http://controller.tc.tester-pl.pl:9311/v1/secrets/b13d2017-e3e5-4f5f-a836-91... | | Name | None | | Created | 2021-02-12T13:41:39+00:00 | | Status | ACTIVE | | Content types | {u'default': u'application/octet-stream'} | | Algorithm | aes | | Bit length | 512 | | Secret type | symmetric | | Mode | None | | Expiration | None | +---------------+----------------------------------------------------------------------------------------+ ``` And of course encryption key, by command(we will save it to file **my_symmetric_key.key**): ``` barbican secret get --payload_content_type application/octet-stream http://controller.tester-pl.pl:9311/v1/secrets/b13d2017-e3e5-4f5f-a836-918ec... --file my_symmetric_key.key ``` We need to transfer symmetric key to passphrase then: ``` [TEST]root@barbican-01:/var/log/barbican# hexdump -e '16/1 "%02x"' my_symmetric_key.key ``` The output is our LUKS Passphrase. We can go to our compute node and decrypt a volume: ``` [TEST]root@comp-09:/home/jwasilewski# cryptsetup luksOpen /dev/disk/by-id/wwn-0x6e00084100ee7e7e7fe79b5900003a89 my-encrypted-volume-decrypted Enter passphrase for /dev/disk/by-id/wwn-0x6e00084100ee7e7e7fe79b5900003a89: ``` Then we can confirm, that our volume is decrypted: ``` [TEST]root@comp-09:/home/jwasilewski# qemu-img info /dev/mapper/my-encrypted-volume-decrypted image: /dev/mapper/my-encrypted-volume-decrypted file format: raw virtual size: 20G (21472739328 bytes) disk size: 0 ``` Thanks again for sharing it, I believe it is a super-useful procedure. Best regards, Jan czw., 11 lut 2021 o 13:23 Lee Yarwood <lyarwood@redhat.com> napisał(a):
On 10-02-21 17:43:03, Lee Yarwood wrote:
On 10-02-21 11:29:06, Jan Wasilewski wrote:
Thank you for a nice description of how everything is organized. It is much easier to understand the full workflow.
I'll try to find some time to write these up again later in the week. That would be great, I will try to do this by myself, but I'm wondering if it's possible to do "all magic" directly from a payload that is visible from barbican CLI.
My thanks to gcharot for writing the following up downstream a while ago and highlighting some easy ways of achieving this.
The following assumes that the volume is already mapped and connected to the localhost, in this case I'm just using the LVs used by the default LVM/iSCSI c-vol backend in my devstack env.
It also assumes you have access to the secrets associated with the encrypted volume, by default admins do not.
- Starting with an encrypted volume
$ sudo qemu-img info --output=json /dev/stack-volumes-lvmdriver-1/volume-d4cc53db-6add-4c29-9f96-42a5498f8bd0 | jq .format "luks"
- Fetch and store the key locally
$ openstack secret get --payload_content_type 'application/octet-stream' http://192.168.122.208/key-manager/v1/secrets/6fd4f879-005d-4b7d-9e5f-2505f0... --file mysecret.key
- Use dmcrypt to decrypt the device using the key as a passphrase
$ yes $(hexdump -e '16/1 "%02x"' mysecret.key) | sudo cryptsetup luksOpen /dev/stack-volumes-lvmdriver-1/volume-d4cc53db-6add-4c29-9f96-42a5498f8bd0 volume-d4cc53db-6add-4c29-9f96-42a5498f8bd0
- This should leave you with the decrypted volume under /dev/mapper
$ sudo qemu-img info /dev/mapper/volume-d4cc53db-6add-4c29-9f96-42a5498f8bd0 image: /dev/mapper/volume-d4cc53db-6add-4c29-9f96-42a5498f8bd0 file format: raw virtual size: 0.998 GiB (1071644672 bytes) disk size: 0 B
Hope this helps!
-- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
participants (2)
-
Jan Wasilewski
-
Lee Yarwood