Kurz und gut – Episode #10 Sag mir, woher Du kommst!

Ich werde in Seminaren, Workshops oder in Kundenprojekten in Sachen MySQL immer mal wieder mit Dingen konfrontiert, auf die ich ad hoc keine Antwort habe bzw. mit denen ich noch keine Erfahrung gesammelt habe. 

Das Problem

Heute geht es um ein Problem eines Kunden, der nach der Einführung eines InnoDB Clusters inklusive des MySQL Routers ein Berechtigungsproblem hat. Dazu muss man wissen, dass MySQL Clients anhand ihrer Herkunft (IP, Hostadresse) authentifizieren kann. Man ist also in der Lage einen User „mj“ von dem Host „172.22.0.1“ Zugriff zu gewähren, während er sich von Systemen mit einer abweichenden IP nicht einloggen kann. Dies nutzen einige Kunden, um unberechtigte Zugriffe besser in den Griff zu bekommen. Mit der Einführung des Clusters, bzw. eigentlich des MySQL Routers, welcher nun zwischen Client und DB-Server steht, entsteht hier ein Problem. Dem DB-Server wird nun nämlich die IP des Routers und nicht die IP des Clients mitgeteilt. 

In unserem Beispiel wird so aus dem User MJ@App1 über den Umweg des Routers nun der User MJ@Router_EU. Damit der Zugriff gelingt, müssten jetzt die User-Accounts entweder angepasst oder die Zugriffsberechtigungen unabhängig von der User-Herkunft gestalten werden. Dies ist möglich, jedoch natürlich etwas unsicherer. 

Die Lösung

Es gibt keine! An den für den Authentifizierungsprozess relevanten Stellen ist die IP des Routers hinterlegt. Die eigentliche IP des Clients wird hier nicht mehr berücksichtigt. Allerdings ist man in der Lage (ab der Router Version 8.0.23) über andere Metatabellen herauszubekommen, von welchem System der Client tatsächlich eingeloggt ist. Dies ist hilfreich, ändert aber nichts an dem Berechtigungsproblem.

Der User "mj" meldet sich im Server Berlin mit der IP 172.22.0.2 über den MySQL Router (172.22.0.8) am DB-Server an. In den Statusinformationen kann man bereits die geänderte IP erkennen. 

bash-4.4# # my IP=172.22.0.2
bash-4.4# mysql -umj -pmj --host=europe --port=6446

mysql> status
--------------
mysql  Ver 8.0.33 for Linux on aarch64 (MySQL Community Server - GPL)

Connection id:		1481
Current database:
Current user:		mj@172.22.0.8
…
 

Auf dem Server können wir über interne Sichten die tatsächliche IP des Clients aufdecken. An dem Problem des Berechtigungsprozesses ändert dies leider nichts. 

mysql> SELECT PROCESSLIST_ID, ATTR_NAME, ATTR_VALUE  FROM performance_schema.session_connect_attrs      WHERE ATTR_NAME IN ("_client_ip", "_client_port") and PROCESSLIST_ID = 1481;
+----------------+--------------+------------+
| PROCESSLIST_ID | ATTR_NAME    | ATTR_VALUE |
+----------------+--------------+------------+
|           1481 | _client_ip   | 172.22.0.2 |
|           1481 | _client_port | 33164      |
+----------------+--------------+------------+
2 rows in set (0.00 sec)
 

Fazit

Manchmal steckt der Teufel im Detail. Die Einführung des Clusters, bzw. des Clients wirkt sich auf das etablierte Berechtigungskonzept aus. Anstatt die User nach den IPs oder Hostnamen der Clients zu filtern, müssen nun die Router berücksichtigt werden. In einigen Fällen macht dies keinen gravierenden Unterschied, da pro Applikationsserver ggf. ein lokaler Router (mit derselben IP) installiert wird. In anderen Fällen können die Auswirkungen aber größer sein. Gerade bei sehr vielen User-Accounts kann dies Arbeit bedeuten. 

Seminarempfehlung