MySQL / MariaDB TDE

DuoKey as the external key source for InnoDB tablespace encryption, via a keyring plugin.

Applies to:

DuoKey Cockpit v2MySQL / MariaDB with InnoDBKeyring plugin: keyring_okv / keyring_hashicorp / keyring_kmip

Overview

MySQL and MariaDB's InnoDB storage engine supports Transparent Data Encryption through a pluggable keyring: instead of the server generating and storing its own InnoDB master encryption key locally, a keyring plugin (or, in current MySQL/Percona Server releases, a keyring component) sources it from an external system. This app configures that keyring to point at a DuoKey-managed key, so InnoDB tablespace files are encrypted at rest without the master key ever living on the database host.

Not the same as a 'proprietary' Oracle protocol

Despite the name, keyring_okv speaks the standard KMIP 1.1 wire protocol as a generic KMIP client — it was originally built for Oracle Key Vault, but it (and the newer component_keyring_kmip) will talk to any KMIP-compliant server, including the DuoKey Cockpit's KMIP listener. component_keyring_hashicorp, by contrast, speaks HashiCorp Vault's own API rather than KMIP.

MySQL / MariaDB to the DuoKey KMIP server

MySQL / MariaDB (InnoDB)Tablespace encryptionRedo / undo log encryption

keyring_okv or component_keyring_kmip

Keyring plugin / componentLoaded at boot via the server's keyring manifest

KMIP 1.1 (TTLV) over TLS

DuoKey KMIP serverCockpit's KMIP listener

Tenant vault / HSMInnoDB master encryption key — never stored on the database host

The keyring component loads before InnoDB initializes, so encrypted tablespaces can be decrypted before the SQL layer accepts connections.

Property	Value
Encryption model	Engine-native TDE (InnoDB tablespace encryption)
Key source	Keyring plugin (OKV / HashiCorp / KMIP-shaped, backed by the DuoKey vault)
Onboarding	Guided multi-step wizard
Proof status	Deployment and configuration generation are real; the self-test currently returns simulated results — see below

Read this before relying on the self-test

The self-test and health-check endpoints for this integration currently return simulated, hardcoded results — they report success without performing a live round-trip against a running MySQL/MariaDB instance. This is an honest limitation, not a hidden one: it mirrors the current maturity of several engines in this catalog (see the overview proof-status table). What is real: the app record, the linked vault key, and the generated setup SQL below, which an operator can run directly against a live server.

Configuration

Field	Purpose
mysql_host	mysql_port	MySQL / MariaDB connection endpoint (default port 3306).
keyring_plugin	Plugin type: keyring_okv (default), keyring_hashicorp, or keyring_kmip.
tablespaces	List of tablespaces to bring under encryption.
redo_log_encryption	Whether InnoDB redo/undo log encryption is also enabled.
linked_key_id	The DuoKey vault key backing the keyring.

Onboarding via the wizard

1

Database

Enter the MySQL/MariaDB host and port for the target instance.

2

Keyring plugin

Choose the keyring plugin type and its configuration.

3

TDE configuration

Select the tablespaces to encrypt and whether to enable redo/undo log encryption.

4

Vault & key

Select the DuoKey vault and master key the keyring plugin will source.

5

Review & deploy

Review the summary and generated SQL setup, then deploy.

6

Monitor

Track encryption status — large tables can take time to encrypt in the background once ENCRYPTION='Y' is applied.

Setup SQL

Deployment generates the following steps. <table_name> is a placeholder — the operator applies it per table (or per tablespace) as needed.

Setup SQL generated by the appSQL

-- 1. Install the keyring plugin
INSTALL PLUGIN keyring_okv SONAME 'keyring_okv.so';

-- 2. Verify it loaded
SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME LIKE 'keyring%';

-- 3. Enable InnoDB encryption on a table
ALTER TABLE <table_name> ENCRYPTION='Y';

Encrypting existing data

ALTER TABLE ... ENCRYPTION='Y' rewrites the tablespace under the hood; for large tables, run it during a maintenance window or expect a background copy operation depending on your MySQL/MariaDB version.

Rotating the master encryption key

ALTER INSTANCE ROTATE INNODB MASTER KEY asks the keyring to generate (or, here, fetch) a new master encryption key and store it. Rotation is fast: it does not immediately re-encrypt existing tablespace data, so older master keys must stay available in the DuoKey vault to keep previously-wrapped tablespace keys decryptable.

What happens when mysqld starts

Boot-time key retrieval and redo log encryption

1. mysqld startsKeyring component loads from the boot manifest, before InnoDB initializes

first key request

2. Request the master encryption keyAutomatic on first boot, or on ALTER INSTANCE ROTATE INNODB MASTER KEY

KMIP 1.1 (TTLV) over TLS

3. DuoKey KMIP serverAuthenticates the client, returns / stores the sealed master encryption key

held in server memory only

4. Wrap the tablespace keysPer-tablespace keys wrapped under the master key

5. Transparent encrypt / decryptTablespace pages, plus redo / undo log records if enabled

The keyring component must be ready before InnoDB initializes, since encrypted tablespaces have to be decryptable before the SQL layer accepts connections.

Health and self-test

Check	What it reports	Live probe today
Health	MySQL reachability, keyring active, TDE enabled	No — returns a fixed healthy status envelope
Self-test	MySQL connection, keyring plugin active, master key accessible, tablespace encryption	No — all four checks return a hardcoded pass

Do not treat the self-test as a compliance proof

Until this self-test is wired to a live MySQL session, use the generated setup SQL and your own INFORMATION_SCHEMA / SHOW ... STATUS queries to independently confirm encryption is active on a given instance.

See Also

• Database Encryption Overview
• Percona PostgreSQL TDE
• Cassandra TDE