Spark SQL-Sicherheitsüberlegungen

Question

Was sind die Sicherheitsüberlegungen beim Akzeptieren und Ausführen beliebiger Spark-SQL-Abfragen?

Stellen Sie sich die folgende Konfiguration:

Zwei Dateien auf hdfs als Tabellen registriert a_secrets und b_secrets:

# must only be accessed by clients with access to all of customer a' data 
spark.read.csv("/customer_a/secrets.csv").createTempView("a_secrets") 

# must only be accessed by clients with access to all of customer b's data 
spark.read.csv("/customer_b/secrets.csv").createTempView("b_secrets") 

diesen beiden Ansichten, ich sichern einfache hdfs Dateiberechtigungen verwenden könnte. Aber sagen, ich habe folgende logische Ansichten dieser Tabellen, die Ich mag würde entlarven:

# only access for clients with access to customer a's account no 1 
spark.sql("SELECT * FROM a_secrets WHERE account = 1").createTempView("a1_secrets") 

# only access for clients with access to customer a's account no 2 
spark.sql("SELECT * FROM a_secrets WHERE account = 2").createTempView("a2_secrets") 


# only access for clients with access to customer b's account no 1 
spark.sql("SELECT * FROM b_secrets WHERE account = 1").createTempView("b1_secrets") 

# only access for clients with access to customer b's account no 2 
spark.sql("SELECT * FROM b_secrets WHERE account = 2").createTempView("b2_secrets") 

Jetzt nehme ich an einen beliebigen (user, pass, query) Satz erhalten. Ich erhalte eine Liste der Konten der Benutzer zugreifen kann:

groups = get_groups(user, pass) 

und extrahiert den logischen Abfrage-Plan der Abfrage des Benutzers:

spark.sql(query).explain(true) 

mir einen Abfrageplan entlang der Linien von (genau diese Abfrage-Plan geben aufgebaut ist)

== Analyzed Logical Plan == 
account: int, ... more fields 
Project [account#0 ... more fields] 
+- SubqueryAlias a1_secrets 
    +- Relation [... more fields] 
     +- Join Inner, (some_col#0 = another_col#67) 
     :- SubqueryAlias a2_secrets 
     : +- Relation[... more fields] csv 
== Physical Plan == 
... InputPaths: hdfs:/customer_a/secrets.csv ... 

Angenommen, ich einen logischen Abfrage-Plan analysieren kann, genau zu bestimmen, welche Tabellen und Dateien zugegriffen werden, ist es sicher von der Abfrage erzeugen Zugriff auf die Daten zu gewähren? Ich denke an mögliche Probleme wie:

• Gibt es Möglichkeiten, auf registrierte Tabellen zuzugreifen, ohne dass sie in einem logischen Abfrageplan angezeigt werden?
• Sind die Möglichkeiten, neue Daten zu laden und sie durch reines Spark SQL als Tabellen zu registrieren? (Eingabe in spark.sql(1))?
• Haben Benutzer Zugriff auf alle SQL-Funktionen mit Nebenwirkungen (die unkorrigierte Daten ändern oder auf diese zugreifen)?
• Gibt es Möglichkeiten, UDFs zu registrieren/beliebigen Code über spark.sql(1) auszuführen?

Zusammengefasst: Kann ich beliebige SQL sicher akzeptieren, registrieren Sie es mit df = spark.sql(1), Datenzugriff analysieren df.explain(True) eingeben und dann die Ergebnisse zurück zum Beispiel unter Verwendung von df.collect()?

Edits: - 23. Januar 15.29 Uhr: bearbeitet, um einen "Explain" Präfix enthält in

Answer 1

TL; DR Sie sollten niemals einen nicht vertrauenswürdigen Code auf dem Spark-Cluster auszuführen.

Sind die Möglichkeiten zum Laden neuer Daten und registrieren sie als Tabellen durch reines Funken SQL?

Ja. CREATE TABLE kann mit der Methode sql ausgeführt werden. Wenn also Benutzer Zugriff auf das Dateisystem haben, können sie Tabellen erstellen.

Gibt es Möglichkeiten, UDFs zu registrieren/beliebigen Code durch spark.sql (1) auszuführen?

Ja, wie lange sie Classpath steuern, die mit SQL geändert werden.

spark.sql("""add jar URI""") 

Haben Benutzer Zugriff auf alle SQL-Funktionen mit Nebenwirkungen haben (das ändert oder unbefugte Datenzugriffe)?

Effektiv ja (durch Erweiterung des vorherigen Punktes).

Kann ich sicher, beliebigen SQL akzeptiert

Keine.