Detaillierte Erläuterung des MLSQL-Beispiels zur Berechtigungssteuerung zur Kompilierungszeit

Vorwort

Das einfache Verständnis von MySQL-Berechtigungen besteht darin, dass MySQL Ihnen erlaubt, Dinge im Rahmen Ihrer Möglichkeiten zu tun und Sie die Grenzen nicht überschreiten können.

Die Berechtigungskontrolle ist ebenso wichtig wie die Lebensader von MLSQL. MLSQL muss auf eine Vielzahl von Ressourcen zugreifen, wie etwa MySQL, Oracle, HDFS, Hive, Kafka, Sorl, ElasticSearch, Redis, API, Web usw. Verschiedene Benutzer haben unterschiedliche Berechtigungen für diese Datenquellen (sowie Tabellen und Spalten).

Das traditionelle Modell besteht darin, dass jeder Benutzer einen Proxy-Benutzer haben muss und dieser Proxy-Benutzer dann in jeder Datenquelle autorisiert werden muss. Dies mag zwar mühsam erscheinen, ist in der Praxis jedoch grundsätzlich schwierig umzusetzen. Verschiedene Datenquellen befinden sich in unterschiedlichen Teams, sodass der gesamte Bewerbungsprozess Tage oder sogar Wochen dauern kann.
Wenn die oben genannten Probleme schon entmutigend sind, dann sind die Zugriffsrechte auf Hive für Unternehmen, die Hive als Data Warehouse verwenden, möglicherweise noch entmutigender. Das Autorisierungsmodell von Hive folgt dem Linux-Benutzer, d. h. wer Spark startet, hat Zugriffsrechte. Dies ist für Multi-Tenant-MLSQL-Anwendungen völlig undurchführbar. Beispielsweise wird Spark von sparkUser gestartet, aber der eigentliche Ausführende kann Zhang San, Li Si usw. sein. Hive kann nicht wissen, wer die Aufgabe abgeschlossen hat, sondern nur, dass es sparkUser war.

Es gibt noch einen weiteren Punkt, den jeder spüren kann:

Wir haben mit großem Aufwand ein Skript geschrieben und es eine Stunde lang ausgeführt, als es plötzlich abstürzte. Wir stellten fest, dass die in Zeile 350 aufgerufene Datenquelle nicht über ausreichende Berechtigungen verfügte. Das ist wirklich ärgerlich.

Hier kommt das Problem

Wie können wir also wissen, ob alle am Skript beteiligten Ressourcen autorisiert sind, bevor das Skript ausgeführt wird?

Die Antwort ist: Ja

Off topic: Der Titel ist nicht streng, da MLSQL im Wesentlichen eine interpretierte Ausführungssprache ist, die keine Kompilierung erfordert. Ein besserer Titel wäre [Berechtigungskontrolle während der Analyse].

Wenn die Berechtigungsüberprüfung bei MLSQL aktiviert ist, wird zunächst das gesamte Skript gescannt und anschließend werden die erforderlichen Informationen extrahiert. Dazu gehören ausführliche Angaben zu verschiedenen Datenquellen, sodass Sie vor der Ausführung wissen, ob Sie auf nicht autorisierte Bibliotheken und Tabellen zugegriffen haben. Also, wie macht es MLSQL? Schauen wir uns die folgenden Informationen an:

verbinden jdbc wo
Treiber="com.mysql.jdbc.Driver"
und url="jdbc:mysql://${ip}:${host}/db1?${MYSQL_URL_PARAMS}"
und Benutzer="${user}"
und password="${password}"
als db1_ref;

lade jdbc.`db1_ref.people`
als Menschen;

Speichern Sie die Anhänge der Personen als jdbc.`db1_ref.spam`;

Weil MLSQL erfordert, dass jede Datenquelle mit einer Load-Anweisung geladen werden muss. Beim Parsen der Load-Anweisung erkennt MLSQL, dass der Benutzer jetzt auf eine Datenquelle zugreift, die auf dem JDBC-Protokoll basiert, und erhält diese Information über die URL:

Datenbank: db1
Tabelle: Personen
Betriebstyp: laden
Quelltyp: mysql
Tabellentyp: JDBC

Natürlich wird dieser Skriptbenutzer auch eine Spam-Tabelle schreiben und es werden auch Informationen extrahiert:

Datenbank: db1
Tabelle: Personen
Betriebstyp: speichern
Quelltyp: mysql
Tabellentyp: JDBC

Dann gibt es eine temporäre Tabelle „people“, sodass dieses Skript insgesamt drei Tabellen mit Informationen enthält, die dann zur Beurteilung an AuthCenter gesendet werden. AuthCenter teilt MLSQL mit, welche Tabelle für den aktuellen Benutzer nicht autorisiert ist. Wenn eine nicht autorisierte Tabelle gefunden wird, löst MLSQL direkt eine Ausnahme aus. Während des gesamten Prozesses wird überhaupt kein physischer Plan ausgeführt, sondern nur die Informationen werden aus dem Skript extrahiert.

In MLSQL können wir in Select-Anweisungen nicht auf Hive-Tabellen zugreifen. Wir können sie nur über Load-Anweisungen laden. Beispielsweise meldet die folgende Anweisung einen Fehler:

Wählen Sie * aus public.abc als Tabelle1;

Wir haben in der Select-Anweisung keinen Zugriff auf die Bibliothek public.abc. Wenn Sie sie verwenden müssen, können Sie dies wie folgt tun:

lade hive.`public.abc` als abc;
Wählen Sie * aus abc als Tabelle1;

So implementieren Sie die Steuerung auf Spaltenebene

Wenn MLSQL die Ladeanweisung analysiert, fragt es den aktuellen Benutzer, auf welche Tabellen zugegriffen wird und welche Spalten autorisiert sind. Anschließend wird die letzte Ladeanweisung neu geschrieben und eine neue Ansicht bereitgestellt, die nur die Spalten enthält, auf die der Benutzer zugreifen darf.

Zusammenfassen

Durch einige wirksame Einschränkungen kann MLSQL alle mit der Datenquelle in Zusammenhang stehenden Informationen direkt auf der Ebene der Syntaxanalyse extrahieren und zur Beurteilung an das entsprechende Berechtigungscenter senden, wodurch Probleme mit der Autorisierungsablehnung während der Laufzeit vermieden werden. Dieser Schritt von MLSQL ist von großer Bedeutung. Er macht das MLSQL-System nicht mehr vollständig von der Berechtigungskontrolle des zugrunde liegenden Systems abhängig, was das Problem erheblich vereinfacht.

Das ist alles für diesen Artikel. Ich hoffe, dass der Inhalt dieses Artikels für Ihr Studium oder Ihre Arbeit von gewissem Referenzwert ist. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.