What is in place, what it expects from you, and what is not covered. The last of those is the part most software leaves out.
Passwords are hashed with argon2id. A local account must have an authenticator, because it is the way back in when single sign on is broken. Failed attempts lock the account and are counted per address as well, so spraying one password across many accounts is slowed too.
The managers talk over mutual TLS with certificates from the cluster's own authority, and every message is signed with the cluster secret on top of that. Holding a certificate is the same thing as being a member, and the authority's key never leaves the machine that made it.
The manager runs unprivileged in a container that cannot touch the host. Anything needing root goes to an agent that will only do things on a fixed list and checks the arguments of each. That list is the real boundary, not the container.
Every action is written to an audit log that nothing in the interface can edit, on the machine where it happened. Logs are deliberately not replicated, so no node can write into another node's history.
None of this is a fault in either server. A newly initialized MySQL or MariaDB has always come up permissive, on the assumption that the next thing to run is mysql_secure_installation. That program is interactive, so no scripted install ever runs it, and databases built by automation tend to keep what a hand built one would have lost in the first five minutes.
| What | Why it matters |
|---|---|
| Two accounts with no name and no password | One for localhost and one named after the host. Anyone who reaches the port can connect with no user name at all. |
| A database called test | Empty, and there by default. |
| Rights on test held by PUBLIC | PUBLIC is the role every account holds and cannot give up, so every account, including a tightly scoped application one, can create a database called test_anything and do as it likes inside it. Dropping the test database does not take this away. |
All three are cleared when the server is built, and there is a command to do it on a cluster that is already running.
Careful
Close port 4567 to everything but the nodes. Galera does not authenticate group membership. Anything that reaches that port and names your cluster is admitted by Galera itself, holding no token, no certificate and no password, and this software is never consulted. There is no setting here that can refuse it. We took a healthy three node cluster down that way by accident, in one second, with a stray container.
| Do this | Or else |
|---|---|
| Set the allow list to the networks your staff use | Anyone who can reach port 8443 gets the login form. |
| Set the trusted proxy when behind a load balancer | Every visitor wears the balancer's address, so the audit log cannot say who did anything and ten bad passwords from one person lock out everybody. The Settings page notices this and says so. |
| Give application accounts one database and one network | An account with % and rights on everything turns one leaked configuration file into full access from anywhere. |
| Keep the nodes on the same version | Mixed versions stay joined and disagree about what they can do. |
Said plainly rather than implied.