Notifications
Clear all
Topic starter
08/07/2026 7:09 pm
TL;DR: MariaDB Galera Cluster can remove replication lag and enable rolling maintenance, but passbolt’s lab shows that mutual TLS is what lets distributed database nodes authenticate peers and clients without brittle IP-based trust, according to Passbolt. The real lesson is that identity-bound transport trust, not just encryption, becomes the control plane for clustered credentials.
NHIMG editorial — based on content published by Passbolt: All articles, passbolt with MariaDB Galera Cluster using Mutual TLS (mTLS) authentication
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
Questions worth separating out
Q: How should security teams govern certificate-based access for clustered databases?
A: Treat certificates, hostnames, and CA trust as a single identity boundary.
Q: Why do mTLS and workload identity matter in distributed database environments?
A: Because distributed databases depend on knowing which node or application is connecting, not just whether traffic is encrypted.
Q: What breaks when certificate SANs do not match cluster hostnames?
A: Peer validation fails, replication can become unstable, and operators often compensate with manual exceptions or relaxed trust settings.
Practitioner guidance
- Inventory database identities as NHIs Document every MariaDB node certificate, application client certificate, CA, and hostname binding as part of the identity estate.
- Bind cluster trust to SAN-consistent hostnames Standardise node names across DNS, certificate SANs, and Galera configuration so replication does not depend on IP addresses.
- Require certificate-backed database access for privileged apps Use client certificates for application-to-database access and enforce REQUIRE SSL on sensitive accounts.
What's in the full article
Passbolt's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step certificate generation commands for the Galera root CA, server certificates, and passbolt client certificates.
- Exact Docker and MariaDB configuration snippets for replication mTLS and client-side TLS.
- Verification commands for cluster health, TLS status, and passbolt connectivity checks.
- Troubleshooting notes for DNS mismatch, certificate SAN errors, and non-primary cluster states.
👉 Read Passbolt's article on passbolt with MariaDB Galera Cluster and mTLS →
mTLS for Galera clusters: what it changes for IAM teams?
Explore further
08/07/2026 7:34 pm
Identity-bound transport trust is now part of database governance, not a networking optional extra. This lab shows that clustered passbolt deployments cannot rely on IP addresses or perimeter rules alone once nodes span subnets, racks, or sites. mTLS turns the database tier into a certificate-governed identity plane, which aligns closely with OWASP NHI and Zero Trust thinking. Practitioners should treat cluster membership, peer authentication, and certificate issuance as one control domain.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who should own lifecycle management for database certificates?
A: The team that owns the database service should own the full certificate lifecycle, with IAM or security governance setting standards for issuance, rotation, and revocation. Without explicit ownership, certificates tend to outlive their intended purpose and become unmanaged trust assets.
👉 Read our full editorial: Mutual TLS for Galera clusters tightens passbolt database trust
