Database Encryption
DuoKey as the external key custodian behind seven database encryption engines — from engine-native TDE to client-side, per-column and per-field encryption.
What this product family is
The Database Encryption apps in the Cockpit's catalog all solve the same underlying problem in different ways: a database engine (or its client driver) needs an encryption key it does not want to store locally, and DuoKey supplies that key from a tenant vault, over a standard protocol the database side already speaks — usually KMIP.
Two distinct encryption models sit under this umbrella:
- Engine-native Transparent Data Encryption (TDE). The database engine itself owns encryption. It fetches (or is configured to fetch) a principal or master key from DuoKey, then transparently encrypts data files, tablespaces, SSTables or commit logs on disk. Applications and queries are unaware encryption is happening; DuoKey never sees table data, only the key material it custodies. Percona PostgreSQL TDE, MySQL/MariaDB TDE, Cassandra TDE and Couchbase's Encryption at Rest all fall in this category.
- Client-side / application-level encryption. The database engine never sees plaintext at all. A client driver or library encrypts specific fields or columns before they leave the application, using keys it fetches (indirectly) from DuoKey, and decrypts them on the way back. The database stores and indexes ciphertext. MongoDB Client-Side Field-Level Encryption (CSFLE), MongoDB Queryable Encryption, and SQL Server Always Encrypted fall in this category — DuoKey's role narrows to custodying the top-level wrapping key (a Customer Master Key or equivalent), never the per-record encryption keys themselves.
SQL Server Always Encrypted (in this section) is a different integration from SQL EKM (a separate, existing product covering SQL Server TDE). See the SQL Always Encrypted page for a direct comparison.
Each engine reaches Cockpit over the protocol it already speaks — KMIP for the TDE engines and Couchbase, driver-native calls for the client-side engines — and Cockpit's linked vault is the only place the key material lives.
The seven engines
| Engine | Encryption model | Onboarding | Proof status |
|---|---|---|---|
| Percona PostgreSQL TDE | Engine-native TDE (KMIP principal key) | Detail page | Proven end-to-end — live KMIP round-trip and ciphertext-at-rest verified against a real Percona 17.5 container |
| MySQL / MariaDB TDE | Engine-native TDE (keyring plugin) | Wizard | Deployment/config generation real; self-test currently simulated |
| Cassandra TDE | Engine-native TDE (per-node KMIP key provider) | Detail page | Deployment artifacts and rotation runbook real; rolling rollout is an operator-run runbook, not yet automated |
| MongoDB CSFLE | Client-side field-level encryption (opaque ciphertext) | Wizard | Deployment/config generation real; self-test currently simulated |
| MongoDB Queryable Encryption | Client-side field-level encryption (queryable — equality/range) | Detail page | Emitted encryptedFieldsMap and CMK reference real; self-test currently simulated |
| Couchbase Encryption at Rest | Engine-native DEK/KEK wrap over KMIP | Detail page | KEK provisioning and KMIP enrollment bundle real; Couchbase-side application is a manual operator step |
| SQL Server Always Encrypted | Client-side column encryption (CMK/CEK) | Detail page | CMK path and T-SQL generation real; self-test currently simulated |
Only Percona PostgreSQL TDE has a live, automated end-to-end proof today: a real KMIP server the Cockpit runs, a real pg_tde client registering and fetching a principal key over TTLV/mTLS, and an integration test that greps ciphertext off disk against a live container. The other six engines generate real, usable deployment artifacts — configuration snippets, T-SQL, CQL, KMIP enrollment bundles — and link to a real key already held in the tenant vault (Couchbase's enrollment step goes further and provisions a dedicated KEK directly), but their self-test / health-check endpoints currently return simulated results rather than driving a live round-trip against the target database. This is called out explicitly on each page; it does not mean the underlying key custody or artifact generation is fake, only that the health-check has not yet been wired to a live probe.
How this fits the Apps catalog
Every engine here is an entry in the Cockpit's Apps catalog, in the database category. Deploying one creates an app scoped to your tenant, which in turn either:
- links to a vault key that is wrapped/served over the Cockpit's KMIP server (the TDE engines, and the CMK for the client-side engines), or
- provisions a dedicated Key Encryption Key (KEK) the target system references by a KMIP identifier (Couchbase).
Some engines are onboarded through the guided multi-step wizard (MySQL TDE, MongoDB CSFLE); the rest are configured directly on the app's detail page because they either need fields the generic wizard doesn't model yet, or their onboarding is inherently a one-shot "provision and hand the operator a bundle" flow (Cassandra TDE, MongoDB Queryable Encryption, Couchbase, SQL Always Encrypted). Percona PostgreSQL TDE also onboards from its detail page, reflecting its richer configuration surface (connection pooling, failover, replica hosts).
Every app exposes the same lifecycle regardless of onboarding path: deploy → enable/disable → health check → self-test → delete, plus engine-specific actions (principal-key rotation for Percona, CEK creation for Always Encrypted, cluster enrollment for Couchbase, replication-aware key rotation for Cassandra).
Percona PostgreSQL TDE
Flagship, proven end-to-end integration.
MySQL / MariaDB TDE
Keyring-plugin TDE via the wizard.
Cassandra TDE
Replicated-cluster TDE with a dual-active-key rotation runbook.
MongoDB CSFLE
Client-side field-level encryption.
MongoDB Queryable Encryption
Queryable client-side field encryption.
Couchbase Encryption at Rest
KEK-over-KMIP for Couchbase's native DEK/KEK model.
SQL Server Always Encrypted
Client-side column encryption, distinct from SQL EKM.