MariaDB HashiCorp Vault Key Management Plugin: Automated Tablespace Encryption, Dynamic Key Rotation, and Compliance in Pakistan

In enterprise financial institutions, banking payment gateways, and regulated corporate environments across Pakistan, compliance directives enforced by the State Bank of Pakistan (SBP) and the Securities and Exchange Commission of Pakistan (SECP) mandate strict Transparent Data Encryption (TDE) for all data-at-rest. Simply encrypting entire disk volumes (via LUKS) fails audit requirements because root administrators can read raw database files while the volume is unlocked.

MariaDB’s native HashiCorp Vault Key Management Plugin provides enterprise-grade TDE by offloading cryptographic master key generation, storage, and automated version rotation to an external, hardware-isolated HashiCorp Vault cluster. This architecture ensures that database tablespaces, binary logs, and redo logs are encrypted in hardware, with keys never persisted to disk on the database server.

---

The Architecture of MariaDB Vault-Managed TDE

The integration relies on HashiCorp Vault’s Transit Secrets Engine, which provides cryptography-as-a-service. MariaDB queries Vault over mutual TLS (mTLS) to fetch or wrap database encryption keys (DEKs).

+-------------------------------------------------------------------------+
|                  HashiCorp Vault Cluster (KMS / HSM)                    |
|                                                                         |
|  [Transit Secrets Engine: key_version_1, key_version_2]                 |
|  - Cryptographic key never leaves secure memory                         |
+-------------------------------------------------------------------------+
                                      ^
                                      | (mTLS HTTPS / Port 8200)
                                      | [Token / AppRole Authentication]
                                      v
+-------------------------------------------------------------------------+
|                  MariaDB Database Server (Dedicated Server)             |
|                                                                         |
|  [hashicorp_vault.so Plugin] <---> [InnoDB Core Engine]                 |
|                                         |                               |
|                     +-------------------+-------------------+           |
|                     |                                       |           |
|                     v                                       v           |
|            [Encrypted Tablespaces]                 [Encrypted Redo Logs] |
|            (AES-256-CTR / GCM)                     (AES-256-CBC)        |
+-------------------------------------------------------------------------+

When operating on high-security Dedicated Servers in Pakistan, decoupling the database computation engine from cryptographic key custody satisfies the stringent regulatory separation-of-duties mandates.

---

Step 1: Provisioning the HashiCorp Vault Transit Engine and AppRole

On your HashiCorp Vault server, enable the transit engine and create a dedicated encryption key:

# Enable Transit engine
vault secrets enable transit

# Create a convergent 256-bit AES-GCM encryption key
vault write -f transit/keys/mariadb_enterprise_key \
  type=aes256-gcm96 \
  derived=false \
  exportable=false

# Configure access policy for MariaDB in /etc/vault/mariadb-policy.hcl
cat << 'EOF' > /etc/vault/mariadb-policy.hcl
path "transit/encrypt/mariadb_enterprise_key" {
  capabilities = ["update"]
}
path "transit/decrypt/mariadb_enterprise_key" {
  capabilities = ["update"]
}
path "transit/keys/mariadb_enterprise_key" {
  capabilities = ["read"]
}
EOF

# Apply policy and create AppRole credentials
vault policy write mariadb-tde /etc/vault/mariadb-policy.hcl
vault auth enable approle
vault write auth/approle/role/mariadb-role \
  token_policies="mariadb-tde" \
  token_ttl=24h \
  token_max_ttl=72h

Retrieve the role_id and secret_id to provide to the database instance.

---

Step 2: Configuring the MariaDB HashiCorp Vault Plugin

On the MariaDB server, install and configure the plugin. Create /etc/my.cnf.d/vault_encryption.cnf:

[mariadb]
# Load the HashiCorp Vault key management plugin
plugin_load_add = hashicorp_vault

# Vault server endpoint and mTLS settings
hashicorp_vault_url = https://vault.internal.pk:8200
hashicorp_vault_ca_path = /etc/pki/tls/certs/vault_ca.crt
hashicorp_vault_approle_role_id = 4a12bc34-98de-4123-b123-c4567890ef12
hashicorp_vault_approle_secret_id = 9f87ba65-43dc-2109-a321-b9876543210f

# Transit key name inside Vault
hashicorp_vault_key_name = mariadb_enterprise_key

# InnoDB Tablespace Encryption Settings
innodb_encrypt_tables = FORCE
innodb_encrypt_log = ON
innodb_encryption_threads = 8
innodb_encryption_rotate_key_age = 1

# Supported encryption algorithms (AES-256-CTR / AES-256-CBC)
innodb_default_encryption_key_id = 1

Restart MariaDB to activate the plugin:

systemctl restart mariadb

---

Step 3: Verifying Tablespace Encryption Status

Confirm that the plugin is loaded and communicating successfully with Vault:

-- Check plugin status
SHOW PLUGINS LIKE 'hashicorp_vault';

-- Verify encryption engine status
SHOW STATUS LIKE 'innodb_encryption%';

Sample output:

+-----------------------------------+-------+
| Variable_name                     | Value |
+-----------------------------------+-------+
| Innodb_encryption_rotation_pages_read  | 49201 |
| Innodb_encryption_rotation_pages_done  | 49201 |
| Innodb_encryption_key_requests         | 849   |
+-----------------------------------+-------+

To create an explicitly encrypted table:

CREATE TABLE corporate_ledgers (
    ledger_id BIGINT AUTO_INCREMENT PRIMARY KEY,
    account_number VARCHAR(34) NOT NULL,
    balance DECIMAL(18,4) NOT NULL,
    audit_hash VARCHAR(64) NOT NULL
) ENGINE=InnoDB ENCRYPTED=YES;

---

Step 4: Executing Zero-Downtime Cryptographic Key Rotation

When SBP/SECP security compliance audits necessitate annual or quarterly key rotations, execute the rotation directly inside Vault without restarting MariaDB:

# Rotate the master encryption key version inside HashiCorp Vault
vault write -f transit/keys/mariadb_enterprise_key/rotate

Once rotated in Vault, instruct MariaDB to re-encrypt existing tablespaces in the background using the new key version:

-- Signal InnoDB background threads to re-encrypt tablespaces with the updated key version
SET GLOBAL innodb_encryption_rotate_key_age = 2;

MariaDB’s background encryption threads incrementally read existing pages, decrypt them using the previous key version, re-encrypt them with the newly rotated key version, and flush them to NVMe disk with zero query interruption.

Deploying high-security databases on bare-metal Dedicated Servers provides the dedicated hardware isolation, secure private networking, and computational throughput required to enforce strict enterprise data encryption at scale.