Implement Hostgroup-Based Backend Credentials

[maurice2k]

Fixes #3446

Summary

This PR implements the ability to use separate credentials for frontend (client → ProxySQL) and backend (ProxySQL → MySQL/PostgreSQL) connections, mapped by hostgroup. This allows ProxySQL to act as an authentication middleware where clients authenticate with one set of credentials, while ProxySQL uses different credentials to connect to backend servers.

Changes

Core Implementation:

• Added lookup_backend_for_hostgroup() method to MySQL_Authentication and PgSQL_Authentication classes
• Modified MySQL_Session and PgSQL_Session to use hostgroup-specific backend credentials when available
• Added SQLite triggers to enforce constraint: only one backend=1 user per default_hostgroup
• Fixed small memory leaks in free_account_details() (missing username free, duplicate password free)

How It Works:

• Frontend users: frontend=1, backend=0 - used for client authentication
• Backend users: frontend=0, backend=1 - used for backend connections, mapped by default_hostgroup
• Standard users: frontend=1, backend=1 - classic ProxySQL behavior (same credentials for both)

Example Configuration:

-- Frontend user (clients connect with this)
INSERT INTO mysql_users (username, password, default_hostgroup, frontend, backend)
VALUES ('app_user', 'app_pass', 10, 1, 0);

-- Backend credentials for hostgroup 10
INSERT INTO mysql_users (username, password, default_hostgroup, frontend, backend)
VALUES ('backend_user', 'backend_pass', 10, 0, 1);

When app_user connects and queries are routed to hostgroup 10, ProxySQL automatically uses backend_user credentials for the backend connection.

Testing

Includes a Docker-based test suite (test/backend-credentials/) with:

• MySQL backend servers (2 read, 2 write, 1 standard frontend=backend auth)
• PostgreSQL backend servers (2 read, 2 write, 1 standard frontend=backend auth)
• Automated tests covering:
  • Frontend connection with different backend credentials
  • Query routing (SELECT → read hostgroup, INSERT/UPDATE/DELETE → write hostgroup)
  • Write verification on correct hostgroup
  • Standard mode backward compatibility (frontend=backend=1)

Run tests:

cd test/backend-credentials
./run-tests.sh

Backward Compatibility

Fully backward compatible. Existing configurations with frontend=1, backend=1 continue to work unchanged.

[gemini-code-assist]

Summary of Changes

Hello @maurice2k, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant enhancement to ProxySQL by enabling hostgroup-based backend credentials for both MySQL and PostgreSQL. This feature allows for a more flexible and secure authentication model where client-facing and database-facing credentials can be distinct and managed per hostgroup. It transforms ProxySQL into a more powerful authentication proxy, providing granular control over how connections are established to backend servers. The changes maintain backward compatibility and are thoroughly validated with a new, extensive test suite.

Highlights

• Hostgroup-Based Backend Credentials: Implemented the ability to use separate credentials for frontend (client to ProxySQL) and backend (ProxySQL to database server) connections, mapped by hostgroup for both MySQL and PostgreSQL.
• Authentication Middleware: ProxySQL can now act as a more robust authentication middleware, allowing clients to authenticate with one set of credentials while ProxySQL uses different, hostgroup-specific credentials for backend connections.
• Constraint Enforcement: Added SQLite triggers to enforce a critical constraint: only one backend user (backend=1) is allowed per default_hostgroup, ensuring unambiguous credential mapping.
• Memory Leak Fixes: Addressed and fixed small memory leaks within the free_account_details() function for MySQL authentication.
• Comprehensive Testing: A new Docker-based test suite has been introduced, covering various scenarios including frontend/backend credential separation, query routing, and backward compatibility for both MySQL and PostgreSQL.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[renecannao]

Can one of the admins verify this patch?

[gemini-code-assist]

Code Review

This pull request introduces a significant and valuable feature: hostgroup-based backend credentials for both MySQL and PostgreSQL. The implementation is comprehensive, touching authentication, session management, and database schema with new triggers. The inclusion of a thorough Docker-based test suite is commendable and greatly increases confidence in the changes. My review of the C++ code confirms that the core logic is sound, and the memory leak fix in free_account_details() is a good catch. My main feedback centers on improving maintainability by reducing code duplication. Specifically, the logic for creating database triggers in Admin_Bootstrap.cpp and the logic for applying backend credentials in MySQL_Session.cpp and PgSQL_Session.cpp are repeated in several places. I've suggested refactoring these into helper functions. Overall, this is a solid contribution.

[maurice2k]

Hey there! I changed most of what Gemini Code Assist said (all valid points) but SonarQube is complaining about malloc/free that is used all over the codebase and also was already in place where I made changes.

Happy to get this merged!

[sonarqubecloud]

Quality Gate failed

Failed conditions
3 Security Hotspots

See analysis details on SonarQube Cloud

[maurice2k]

Is there something I can do?