MaxScale REST exposure needs a break from the default admin account

MaxScale sits between applications and MariaDB servers. It routes queries, manages topology and exposes an administrative interface for operations. The administrative interface is powerful enough that its exposure should be reviewed separately from the database listener.

MariaDB's documentation says the REST API uses HTTP Basic authentication with MaxScale administrative users. It also documents an initial default account of admin with password mariadb. The default is a deployment starting point, not a production credential.

What ZoomEye observed

On 2026-11-09 at 06:47 Asia/Shanghai, the count-only all scope produced:

• app="MaxScale": 3
• title="MaxScale": 886
• http.body="MaxScale": 9,129

The body count is broad. The title count identifies a visible MaxScale web surface. The title query is the useful starting point. A match does not prove that an instance still uses default credentials or that the API is reachable without other network controls.

Separate data plane and admin plane

Clients should connect to the database service, not the REST API. Put MaxGUI and the REST API on a management network, a private listener or a VPN. If an operator needs remote access, require a strong identity layer and restrict the source address.

The GUI and MaxCtrl both use the REST API. That means an exposed API is not just a dashboard issue. It can change server parameters, routing and administrative users. Review the admin_secure_gui setting and the TLS termination point before deciding that the interface is private.

Replace the bootstrap account

Immediately after installation, create named administrative accounts and remove or disable the shared default. Use a separate read-only account for monitoring where possible. Store passwords outside the configuration and avoid putting them in a shell history or an unencrypted dashboard variable.

The documentation describes token-based GUI sessions and administrative account types. Treat a GUI session, a MaxCtrl credential and a database service account as different capabilities. Do not reuse the same secret across them.

Log and alert

Record successful and failed authentication to the REST API, changes to users and changes to server parameters. Alert on updates from a new source network, especially outside a change window. A monitoring tool should not need permission to rewrite routing.

If a proxy sits in front of MaxGUI, verify that it does not cache authenticated responses and that it strips inbound identity headers. The API should receive a direct authenticated request, not a header that any client can set.

Review checklist

1. Confirm the default account no longer works.
2. List every listener for the REST API and GUI.
3. Test access from a normal application subnet.
4. Verify TLS and certificate validation for remote management.
5. Check user roles for read-only monitoring.
6. Inspect audit logs for parameter changes and account edits.

The title count shows that MaxScale can be visible on the public web. The documented default account makes the first review simple. Replace it, move the management plane behind a restrictive boundary and give every administrator a named credential with a defined role.

References

• Securing Your MaxScale Deployment
• MaxScale REST API
• ZoomEye title observation