Encryption Bypass - Revision history

Qadmin: Qadmin moved page Ceph Encryption Bypass to Encryption Bypass without leaving a redirect: The feature is not Ceph-specific - the same list governs encrypted scale-up Storage Pools and SED pool devices on the same appliance, so a Ceph-scoped title hides it from scale-up administrators

2026-09-04T05:57:33Z

Qadmin moved page Ceph Encryption Bypass to Encryption Bypass without leaving a redirect: The feature is not Ceph-specific - the same list governs encrypted scale-up Storage Pools and SED pool devices on the same appliance, so a Ceph-scoped title hides it from scale-up administrators

← Older revision		Revision as of 05:57, 4 September 2026
(No difference)

Qadmin: Correct the framing again per engineering: the bypass is automatic on a vendor:model match - no prompt, no option, the product does the right thing by itself. The previous wording implied a provisioning decision the administrator makes. What actually matters is whether the media is in the list before provisioning, since an unlisted model gets software-encrypted and cannot be converted in place (QSTOR-12352)

2026-09-04T05:56:14Z

Correct the framing again per engineering: the bypass is automatic on a vendor:model match - no prompt, no option, the product does the right thing by itself. The previous wording implied a provisioning decision the administrator makes. What actually matters is whether the media is in the list before provisioning, since an unlisted model gets software-encrypted and cannot be converted in place (QSTOR-12352)

← Older revision		Revision as of 05:56, 4 September 2026
Line 3:		Line 3:
	'''The reason is that software encryption does not scale.''' Wrapping dm-crypt around a device whose array is already encrypting it adds a second encryption layer that costs CPU and throughput on every write while protecting data that is already protected. On a scale-out cluster with many such devices that overhead is significant and buys nothing. In one deployment, reconfiguring a pool from software encryption to bypass took it from roughly '''500 MB/s to roughly 20 GB/s''' -- a fortyfold difference on the same hardware, because the array was already doing the encryption and the software layer was simply in the way. Hardware encryption on these arrays can also be enabled '''at any time, on the fly, without rewriting the data''' -- so the array's protection does not have to be arranged before the devices are provisioned, and QuantaStor should stay out of the way either way.		'''The reason is that software encryption does not scale.''' Wrapping dm-crypt around a device whose array is already encrypting it adds a second encryption layer that costs CPU and throughput on every write while protecting data that is already protected. On a scale-out cluster with many such devices that overhead is significant and buys nothing. In one deployment, reconfiguring a pool from software encryption to bypass took it from roughly '''500 MB/s to roughly 20 GB/s''' -- a fortyfold difference on the same hardware, because the array was already doing the encryption and the software layer was simply in the way. Hardware encryption on these arrays can also be enabled '''at any time, on the fly, without rewriting the data''' -- so the array's protection does not have to be arranged before the devices are provisioned, and QuantaStor should stay out of the way either way.

	'''~~Decide this~~ before ~~you provision~~.''' ~~The~~ encryption choice is fixed for the life of an OSD or pool device~~. An OSD built while an entry is in force cannot be encrypted afterwards~~, ~~and -- the costly direction --~~ a device already carrying ~~QuantaStor's~~ software encryption cannot be switched to bypass in place. ~~Converting an existing software-encrypted pool~~ means '''copying all of the data off, rebuilding the devices ~~with~~ the entry in place, and copying it back'''~~. That is a~~ lengthy, disruptive ~~exercise~~ on a populated cluster~~, so check~~ the ~~bypass~~ list against your media before the ~~first OSD~~ is ~~created rather than after~~.		'''The bypass is automatic -- there is no prompt and no option.''' If a device's vendor and model match an entry, QuantaStor skips its own encryption for that device. Nothing asks you to confirm it and there is no checkbox to set: on a match, the product does the right thing on its own. So there is no decision to get wrong at provisioning time, and nothing to remember to switch on.

			'''What matters is whether your media is in the list before the first device is provisioned.''' A model that is not listed gets QuantaStor's software encryption, because the appliance has no way to know the array is already encrypting. And that is the expensive situation to discover later: the encryption choice is fixed for the life of an OSD or pool device, so a device already carrying software encryption cannot be switched to bypass in place. Correcting it means '''copying all of the data off, rebuilding the devices once the entry is in place, and copying it back''' -- lengthy and disruptive on a populated cluster. Check the list against your media before you provision, and add the entry if it is missing.

	'''Adding new entries is expected.''' The file exists so that new vendor and model combinations can be recognised as they are released, without waiting for a QuantaStor update. If you deploy an array that encrypts at rest in hardware and its model is not in the list, adding it is the intended action.		'''Adding new entries is expected.''' The file exists so that new vendor and model combinations can be recognised as they are released, without waiting for a QuantaStor update. If you deploy an array that encrypts at rest in hardware and its model is not in the list, adding it is the intended action.

Qadmin: Add the measured impact from a real deployment - a pool reconfigured from software encryption to bypass went from ~500 MB/s to ~20 GB/s on the same hardware - and a prominent warning that the choice must be made before provisioning, because converting an existing software-encrypted pool requires copying all the data off and rebuilding the devices (QSTOR-12352)

2026-09-04T05:53:49Z

Add the measured impact from a real deployment - a pool reconfigured from software encryption to bypass went from ~500 MB/s to ~20 GB/s on the same hardware - and a prominent warning that the choice must be made before provisioning, because converting an existing software-encrypted pool requires copying all the data off and rebuilding the devices (QSTOR-12352)

← Older revision		Revision as of 05:53, 4 September 2026
Line 1:		Line 1:
	The '''encryption bypass''' list tells QuantaStor not to apply its own software encryption to devices that are '''already encrypted by the storage system presenting them'''. Arrays such as the Seagate Corvault, Seagate Exos E/EP and Dell PowerVault families encrypt at rest in hardware and present logical devices to the appliance. For media like these, bypass is not an exception to normal practice -- '''it is the correct configuration''', and it is what the shipped file already does for the models listed in it.		The '''encryption bypass''' list tells QuantaStor not to apply its own software encryption to devices that are '''already encrypted by the storage system presenting them'''. Arrays such as the Seagate Corvault, Seagate Exos E/EP and Dell PowerVault families encrypt at rest in hardware and present logical devices to the appliance. For media like these, bypass is not an exception to normal practice -- '''it is the correct configuration''', and it is what the shipped file already does for the models listed in it.

	'''The reason is that software encryption does not scale.''' Wrapping dm-crypt around a device whose array is already encrypting it adds a second encryption layer that costs CPU and throughput on every write while protecting data that is already protected. On a scale-out cluster with many such devices that overhead is significant and buys nothing. Hardware encryption on these arrays can also be enabled '''at any time, on the fly, without rewriting the data''' -- so the array's protection does not have to be arranged before the devices are provisioned, and QuantaStor should stay out of the way either way.		'''The reason is that software encryption does not scale.''' Wrapping dm-crypt around a device whose array is already encrypting it adds a second encryption layer that costs CPU and throughput on every write while protecting data that is already protected. On a scale-out cluster with many such devices that overhead is significant and buys nothing. In one deployment, reconfiguring a pool from software encryption to bypass took it from roughly '''500 MB/s to roughly 20 GB/s''' -- a fortyfold difference on the same hardware, because the array was already doing the encryption and the software layer was simply in the way. Hardware encryption on these arrays can also be enabled '''at any time, on the fly, without rewriting the data''' -- so the array's protection does not have to be arranged before the devices are provisioned, and QuantaStor should stay out of the way either way.

			'''Decide this before you provision.''' The encryption choice is fixed for the life of an OSD or pool device. An OSD built while an entry is in force cannot be encrypted afterwards, and -- the costly direction -- a device already carrying QuantaStor's software encryption cannot be switched to bypass in place. Converting an existing software-encrypted pool means '''copying all of the data off, rebuilding the devices with the entry in place, and copying it back'''. That is a lengthy, disruptive exercise on a populated cluster, so check the bypass list against your media before the first OSD is created rather than after.

	'''Adding new entries is expected.''' The file exists so that new vendor and model combinations can be recognised as they are released, without waiting for a QuantaStor update. If you deploy an array that encrypts at rest in hardware and its model is not in the list, adding it is the intended action.		'''Adding new entries is expected.''' The file exists so that new vendor and model combinations can be recognised as they are released, without waiting for a QuantaStor update. If you deploy an array that encrypts at rest in hardware and its model is not in the list, adding it is the intended action.

Qadmin: Correct the framing per engineering: bypass is the intended configuration for arrays that encrypt at rest in hardware (Seagate Corvault, Seagate Exos E/EP, Dell PowerVault and similar), not a security exception to be avoided. Adds the rationale - software encryption does not scale and a second layer over already-encrypted media costs throughput for no gain - notes that hardware encryption on these arrays can be enabled on the fly without rewriting data, and states that adding new vendor:model...

2026-09-04T05:53:05Z

Correct the framing per engineering: bypass is the intended configuration for arrays that encrypt at rest in hardware (Seagate Corvault, Seagate Exos E/EP, Dell PowerVault and similar), not a security exception to be avoided. Adds the rationale - software encryption does not scale and a second layer over already-encrypted media costs throughput for no gain - notes that hardware encryption on these arrays can be enabled on the fly without rewriting data, and states that adding new vendor:model...

← Older revision		Revision as of 05:53, 4 September 2026
Line 1:		Line 1:
	The '''encryption bypass''' list ~~excludes a device type from~~ QuantaStor~~'s data-at-rest~~ encryption~~. A device~~ that ~~matches an entry is provisioned into an encryption-enabled Ceph cluster -- or an encrypted [[Storage Pools\|Storage Pool]] --~~ '''~~without being~~ encrypted by ~~QuantaStor~~'''. ~~The data lands in the clear as far~~ as the ~~appliance is concerned~~, and ~~protecting it~~ at rest ~~is left entirely~~ to the media'~~s own hardware encryption. The feature exists for self-encrypting storage such as~~ the ~~Seagate Corvault enclosures~~, ~~whose LUNs~~ already ~~encrypt at rest and gain nothing from a second software layer wrapped around them~~.		The '''encryption bypass''' list tells QuantaStor not to apply its own software encryption to devices that are '''already encrypted by the storage system presenting them'''. Arrays such as the Seagate Corvault, Seagate Exos E/EP and Dell PowerVault families encrypt at rest in hardware and present logical devices to the appliance. For media like these, bypass is not an exception to normal practice -- '''it is the correct configuration''', and it is what the shipped file already does for the models listed in it.

	'''~~This~~ is a ~~security exception mechanism~~, not ~~a performance option~~.''' An entry ~~turns QuantaStor~~'s encryption ~~off~~ for '''every''' device of that vendor and model on the node, and ~~for any~~ OSD created while the entry is in force ~~the exception is permanent -- there is no way to encrypt that OSD afterwards~~ without destroying and re-creating it. The two Seagate Corvault entries that ship in the file are the supported use of it. We recommend adding an entry only when OSNEXUS support has asked you to, and only for media you have established encrypts at rest on its own.		'''The reason is that software encryption does not scale.''' Wrapping dm-crypt around a device whose array is already encrypting it adds a second encryption layer that costs CPU and throughput on every write while protecting data that is already protected. On a scale-out cluster with many such devices that overhead is significant and buys nothing. Hardware encryption on these arrays can also be enabled '''at any time, on the fly, without rewriting the data''' -- so the array's protection does not have to be arranged before the devices are provisioned, and QuantaStor should stay out of the way either way.

			'''Adding new entries is expected.''' The file exists so that new vendor and model combinations can be recognised as they are released, without waiting for a QuantaStor update. If you deploy an array that encrypts at rest in hardware and its model is not in the list, adding it is the intended action.

			What the list does require is that the claim be true. QuantaStor cannot verify that a device encrypts itself; it takes the entry's word for it and skips its own encryption. So add an entry only for media you have established encrypts at rest, and note that an entry matches '''every''' device of that vendor and model on the node, and that an OSD created while the entry is in force cannot be encrypted later without destroying and re-creating it.

	There is no dialog for this list and no <code>qs</code> command that edits it. It is a per-node configuration file, read once when the QuantaStor service starts.		There is no dialog for this list and no <code>qs</code> command that edits it. It is a per-node configuration file, read once when the QuantaStor service starts.
Line 166:		Line 170:
	== Security consequences ==		== Security consequences ==

	~~Stated without hedging~~, ~~because~~ the ~~point~~ of ~~the feature is to switch protection off~~:		Bypass is the right configuration for hardware-encrypted media, but it moves responsibility for data-at-rest protection off the appliance entirely. The consequences of that, stated plainly:

	* '''~~The data~~ is ~~in the clear on the medium~~.''' A bypassed block device holds plaintext BlueStore data~~. A drive pulled from~~ the ~~chassis~~ is ~~readable unless~~ the ~~hardware's own encryption stops it~~, and QuantaStor has no way to ~~confirm that~~ it ~~does~~.		* '''QuantaStor writes plaintext, and cannot confirm the array is encrypting.''' A bypassed block device holds plaintext BlueStore data as far as the appliance is concerned. Protection at rest depends wholly on the array, and QuantaStor has no way to verify it is switched on -- so if the array's encryption is disabled, or was never enabled, nothing on the appliance will report the data as unprotected.
	* '''An audit of the cluster will not show the exception.''' The cluster remains an encryption-enabled cluster, the OSD remains <code>ceph.encrypted=1</code>, and the ~~WUI~~ reports the cluster as encrypted. Only the configuration file, the service log and the LVM tag reveal that a device is excluded.		* '''An audit of the cluster will not show the exception.''' The cluster remains an encryption-enabled cluster, the OSD remains <code>ceph.encrypted=1</code>, and the interface reports the cluster as encrypted. Only the configuration file, the service log and the LVM tag reveal that a device is excluded, so anyone auditing encryption coverage needs to read the bypass list too.
	* '''The scope is the device model, not the device.''' Every matching device on the node is excluded, including devices added later.		* '''The scope is the device model, not the device.''' Every matching device on the node is excluded, including devices added later. That is what makes the feature practical for a large array, and it also means an entry cannot be narrowed to a single drive.
	* '''The scope is ~~also~~ not limited to Ceph.''' The same list governs encrypted Storage Pools and SED pool devices on the same appliance. An entry added ~~to allow~~ a Corvault OSD also ~~disables encryption for~~ Corvault LUNs used in a Storage Pool on that node.		* '''The scope is not limited to Ceph.''' The same list governs encrypted Storage Pools and SED pool devices on the same appliance. An entry added for a Corvault OSD also applies to Corvault LUNs used in a Storage Pool on that node -- usually what you want, since the array encrypts either way, but worth knowing it is one list.
	* '''Key rotation ~~silently~~ skips bypassed OSDs.''' A <code>qs ceph-osd-key-replace</code> run reports success while leaving matching OSDs untouched, because there is no key to replace.		* '''Key rotation skips bypassed OSDs.''' A <code>qs ceph-osd-key-replace</code> run reports success while leaving matching OSDs untouched, because there is no QuantaStor-held key to replace. Key rotation for these devices is the array's business.
	* '''Health monitoring is reduced.''' Matching devices are excluded from SMART and temperature collection, so drive-health alerting ~~for them~~ comes from the enclosure rather than from QuantaStor.		* '''Health monitoring is reduced.''' Matching devices are excluded from SMART and temperature collection, so drive-health alerting comes from the enclosure rather than from QuantaStor.

	== Interaction with Storage Pools and SED media ==		== Interaction with Storage Pools and SED media ==

Qadmin: Restore the systemd Services related link carried by the previous revision (QSTOR-12352)

2026-09-03T11:23:26Z

Restore the systemd Services related link carried by the previous revision (QSTOR-12352)

← Older revision		Revision as of 11:23, 3 September 2026
Line 209:		Line 209:
	* [[Seagate Corvault Configuration]] -- the hardware the shipped entries exist for		* [[Seagate Corvault Configuration]] -- the hardware the shipped entries exist for
	* [[Security Configuration]] -- appliance-wide security settings		* [[Security Configuration]] -- appliance-wide security settings
			* [[QuantaStor systemd Services]] -- the service and the boot units named above

	----		----

Qadmin: Clarify where the ceph-volume activation message is logged (QSTOR-12352)

2026-09-03T11:23:02Z

Clarify where the ceph-volume activation message is logged (QSTOR-12352)

← Older revision		Revision as of 11:23, 3 September 2026
Line 150:		Line 150:
	# '''The absence of a crypt layer.''' <code>lsblk</code> on the bypassed device shows the LVM layer with no <code>crypt</code> device above the block LV, while the WAL and DB LVs of the same OSD still show one.		# '''The absence of a crypt layer.''' <code>lsblk</code> on the bypassed device shows the LVM layer with no <code>crypt</code> device above the block LV, while the WAL and DB LVs of the same OSD still show one.

	During OSD creation, <code>ceph-volume</code> also logs <code>Skipping block device encryption for: <path></code>, and on activation <code>Skipping block device decryption for <path></code>. ~~Both land~~ in the QuantaStor service log with the rest of the OSD creation output.		During OSD creation, <code>ceph-volume</code> also logs <code>Skipping block device encryption for: <path></code>, and on activation <code>Skipping block device decryption for <path></code>. The creation message lands in the QuantaStor service log with the rest of the OSD creation output; the activation message goes wherever the activation ran -- the service log when QuantaStor drove it, the systemd journal for the <code>ceph-volume@</code> unit when the node activated its OSDs at boot.

	== Reversing it ==		== Reversing it ==

Qadmin: Rewrite from the product: correct the match key (SCSI vendor + product ID, not device path/serial), document what the bypass actually skips per encryption mode, the WAL/DB devices staying encrypted, the ceph.block_skip_enc LVM tag, override-file handling, when the list is re-evaluated, verification, reversal and security consequences; drop invented qs physical-disk-get and qs-util restartmgmt commands; fix categories (QSTOR-12352)

2026-09-03T11:20:29Z

Rewrite from the product: correct the match key (SCSI vendor + product ID, not device path/serial), document what the bypass actually skips per encryption mode, the WAL/DB devices staying encrypted, the ceph.block_skip_enc LVM tag, override-file handling, when the list is re-evaluated, verification, reversal and security consequences; drop invented qs physical-disk-get and qs-util restartmgmt commands; fix categories (QSTOR-12352)

Show changes

Qadmin: Create Ceph Encryption Bypass admin page (per-device encryption exceptions)

2026-06-18T22:40:02Z

Create Ceph Encryption Bypass admin page (per-device encryption exceptions)

New page

= Ceph Encryption Bypass (Per-Device Encryption Exceptions) =

The '''Ceph Encryption Bypass''' feature lets you exclude specific device
types from QuantaStor's data-at-rest encryption when those devices already
provide their own encryption. It is used when building OSDs on an
'''encryption-enabled Ceph cluster''' that contains drives or enclosures
which encrypt data internally — most commonly self-encrypting storage
arrays such as the '''Seagate Corvault''' family.

Without this feature, every OSD on an encryption-enabled cluster is wrapped
in QuantaStor's software (dmcrypt/LUKS) or SED encryption. For media that is
already self-encrypting that produces redundant "double encryption", which
adds CPU and latency overhead and complicates key management with no
additional security benefit. The encryption bypass list tells QuantaStor to
create the OSD in the encrypted cluster '''but skip the encryption layer for
that one device''', trusting the hardware to protect data at rest.

{{Note|The bypass only takes effect on Ceph clusters/OSDs that were created
with encryption enabled. On an unencrypted cluster it has no effect — nothing
is encrypted in the first place.}}

== When to use it ==

Add a device to the bypass list when '''all''' of the following are true:

* You are deploying Ceph OSDs on a cluster created with encryption enabled (software dmcrypt/LUKS or SED).
* The target media (drive, or the LUNs presented by a self-encrypting enclosure) performs its own data-at-rest encryption in hardware.
* You want the device's hardware encryption — not QuantaStor's — to be the encryption-at-rest mechanism for those OSDs.

Typical examples:

* '''Seagate Corvault''' self-encrypting enclosures (4U106 and 5U84), which are pre-configured in the bypass list out of the box.
* Other vendor arrays/drives with always-on internal encryption that you have validated meet your data-at-rest requirements.

== How it works ==

# When QuantaStor creates a Bluestore OSD on an encryption-enabled cluster, it looks up the OSD's underlying device by '''SCSI Vendor ID''' and '''Product (Model) ID'''.
# If that Vendor/Model pair appears in the encryption bypass list, the device is treated as an '''encryption exception''':
#* On a '''software (dmcrypt/LUKS)''' cluster, the OSD is still created as part of the encrypted cluster, but the data device is provisioned with <code>--block.skip-enc</code> so its block device is not LUKS-encrypted.
#* On an '''SED''' cluster, the device is not crypt-formatted by QuantaStor; the drive's self-encryption is relied upon instead.
# Devices '''not''' in the list are encrypted normally — the bypass is strictly opt-in, per Vendor/Model.

The matching is by Vendor + Model string only, so a single entry covers
every drive/LUN of that type across the cluster.

== Configuration ==

The bypass list is a per-node configuration file:

/opt/osnexus/quantastor/conf/qs_encryption_bypass.conf

It is an INI-style file. Each entry is a named section with a
<code>vendor</code> and a <code>model</code> key that must match the device's
SCSI Vendor ID and Product ID exactly (case-sensitive):

<pre>
# Seagate Corvault systems have built-in encryption, so QuantaStor's
# software/SED encryption is bypassed for these devices.
[seagate_corvault_4u106]
vendor=SEAGATE
model=6575

[seagate_corvault_5u84]
vendor=SEAGATE
model=6566
</pre>

To add a new device type:

# Determine the device's SCSI '''Vendor ID''' and '''Product/Model ID'''. You can read these from:
#* The WUI — '''Physical Disks/Devices''' → disk properties (Vendor / Model fields).
#* The CLI — <code>qs physical-disk-get <disk></code>.
#* The shell — <code>lsscsi -v</code>, or <code>sg_inq /dev/sdX</code> (Vendor identification / Product identification).
# Add a new section to <code>qs_encryption_bypass.conf</code> with the matching <code>vendor=</code> and <code>model=</code> values.
# Repeat the edit on '''every Ceph node''' that will host OSDs of that device type. This file is '''not''' grid-synced — it is a local, per-node configuration that you must update manually on each node.
# Restart the QuantaStor service so the list is reloaded: <code>systemctl restart quantastor</code> (or <code>qs-util restartmgmt</code>).

{{Note|Add the device to the bypass list '''before''' creating the OSDs you
want excluded. Existing OSDs are not retroactively re-encrypted or
de-encrypted when the list changes — the bypass is evaluated at OSD-creation
time.}}

== ceph-volume patch dependency ==

The <code>--block.skip-enc</code> option used on software-encrypted clusters
is a QuantaStor extension to the stock Ceph <code>ceph-volume</code> tool.
QuantaStor maintains this patch automatically and admins do not normally need
to interact with it:

* The patch is '''idempotent and version-aware''' — safe to re-run, and it only applies the patch set matching the running Ceph release.
* It is re-applied automatically at QuantaStor service start, after any <code>apt</code> operation that may have reinstalled/upgraded <code>ceph-volume</code>, and on boot before any OSD is activated.
* '''Fail-safe by design:''' if the patch cannot be applied to the running <code>ceph-volume</code> (for example after an unexpected Ceph point-release change), QuantaStor logs a loud patch-failure error and the OSD operation fails rather than silently mis-encrypting data. If you see such an alert, contact OSNexus support before forcing OSD creation.

To temporarily disable the ceph-volume patching (advanced/support use only),
create the disable touchfile on the affected node:

/var/opt/osnexus/quantastor/touchfiles/tf_qs_ceph_volume_patch.disable

While this touchfile is present, the patch is not applied and
encryption-bypass OSD creation on software-encrypted clusters will fail.
Remove the touchfile and restart the service to re-enable.

== Verifying ==

After creating OSDs on a bypassed device type:

* Confirm the OSDs come '''up/in''' normally (WUI Ceph view, or <code>ceph osd tree</code>).
* On a software-encrypted cluster, confirm the bypassed device's data block device is '''not''' a LUKS/dmcrypt device (e.g. <code>lsblk</code> shows no <code>crypt</code> layer on it), while non-bypassed OSDs on the same cluster still show the encrypted layer.
* Review <code>/var/log/qs/ceph_volume_patch.log</code> and the QuantaStor service log if you need to confirm the ceph-volume patch applied cleanly.

== See also ==

* [[Create Ceph Cluster Configuration]]
* [[Physical Disks/Devices]]
* [[Security Configuration]]
* [[QuantaStor systemd Services]]

[[Category:Administrator Guide]]
[[Category:Scale-out Storage (Ceph)]]
[[Category:Encryption]]