Infrastructure Encryption
DuoKey as the external key custodian behind disk, VM and application-data encryption.
What this product family covers
Modern infrastructure — host disks, hypervisor storage, and data-platform columns — increasingly ships its own encryption-at-rest capability, but that capability is only as strong as who controls the key. Infrastructure Encryption groups the DuoKey integrations where Cockpit acts as the external key custodian for an encryption engine that already exists in the infrastructure layer: the disk-encryption driver, the hypervisor's native key provider, or a data platform's tokenization runtime. Cockpit never re-implements the encryption engine — it holds the key (or the key-encryption-key) outside that engine and answers its requests to use it.
Each integration reaches Cockpit over the protocol it already speaks — PKCS#11/CNG-KSP, KMIP, or HTTPS tokenize/detokenize — and Cockpit's linked vault is the only place the key material lives.
Five integrations are covered here:
| Integration | What DuoKey custodies | Protocol / interface |
|---|---|---|
| Disk Encryption | The key-encryption-key (KEK) that wraps the volume/data encryption key for LUKS, Cryhod or BitLocker | PKCS#11 proxy (LUKS/Cryhod) or a CNG-KSP certificate protector (BitLocker) |
| Nutanix VM Encryption | The AES-256 cluster encryption key for a Nutanix AHV cluster's Data-at-Rest Encryption | KMIP (Nutanix Prism binds Cockpit as an external KMIP key manager) |
| VMware VM Encryption | The AES-256 key behind a vCenter Native Key Provider KMS cluster (VM, vTPM, vSAN encryption) | KMIP (vCenter binds Cockpit as an external KMIP KMS cluster) |
| Databricks | A deterministically-derived key behind format-preserving tokenization of Lakehouse columns — derived per call, never stored in a vault | Spark / Unity-Catalog UDFs calling the tokenization service over HTTPS |
| Tokenization | Deterministically-derived key(s) behind format-preserving tokenization for Databricks, Snowflake, or a standalone secret — derived per call, never stored in a vault | HTTPS tokenize / detokenize calls, or platform-native external functions |
Disk Encryption is modeled as a single integration in the Apps catalog with three interchangeable on-host engines — LUKS, Cryhod and BitLocker — rather than three separate integrations. See Disk Encryption for the per-backend detail.
How it fits the Apps catalog
Every integration on this page is provisioned as an app in Cockpit's Apps catalog, the same model used across DuoKey's other integrations (databases, PKI issuers, SaaS BYOK, and so on):
Deploy
Register the integration with its connection details (host, cluster, workspace, or volume metadata) and, for KMIP-based integrations, bind a key or key label the external system will request.
Vault-backed key custody
For Disk Encryption, Nutanix and VMware, the key material lives in a linked DuoKey vault, never in the target system: Disk Encryption uses a per-volume RSA key-encryption-key; Nutanix and VMware use an AES-256 key served over KMIP. Databricks and Tokenization work differently — their tokenization key is derived deterministically per tenant and named key from a platform-level master key, and is never stored in a vault; the vault you link to one of those apps is used only for that app's own health checks, self-tests and audit. See Tokenization for the full mechanics.
Enable / disable / health / self-test
Each app exposes the standard lifecycle operations — enable, disable, a health check, and a self-test — so operators can verify connectivity and key custody without leaving Cockpit.
Audit trail
Sensitive operations (for example, disclosing a BitLocker recovery key) are recorded as first-class audit and activity events tied to the acting user.
Two key-custody protocols, one model
The five integrations use two underlying protocols, both already used elsewhere in DuoKey's platform:
- PKCS#11 / CNG-KSP (Disk Encryption): the on-host encryption engine asks DuoKey's provider for cryptographic operations against a key that never leaves the vault. This is the same provider model used by DuoKey's other PKCS#11-backed integrations.
- KMIP (Nutanix VM Encryption, VMware VM Encryption): the external system's own built-in KMIP client registers and fetches a key from Cockpit's KMIP listener — the same KMIP-based key custody model used elsewhere in DuoKey's database and infrastructure integrations.
Databricks and Tokenization instead front a tokenization data-plane: format-preserving tokenize / detokenize calls served directly by Cockpit over HTTPS, consumed through platform-native UDFs or external functions rather than a disk or hypervisor protocol.
Choosing an integration
Disk Encryption
LUKS, Cryhod and BitLocker full-disk / filesystem encryption, including BitLocker recovery-key escrow.
Nutanix VM Encryption
Bind a Nutanix AHV cluster's Data-at-Rest Encryption to a DuoKey-held KMIP key.
VMware VM Encryption
Register DuoKey as a vCenter Native Key Provider KMS cluster for VM, vTPM and vSAN encryption.
Databricks
Onboard format-preserving tokenization into a Lakehouse workspace via Spark / Unity-Catalog UDFs.
Tokenization
The underlying tokenization service — Databricks, Snowflake and generic-secret variants.
If you are onboarding a Lakehouse workload, start with Databricks — it is the guided onboarding path into the same tokenization service described in full on the Tokenization page.
Configuration examples on these pages use placeholders such as <workspace-url> and <cluster-uuid>. Never enter real customer, partner or production identifiers into documentation, tickets, or support requests.