Вопросы безопасности Spark SQL

Question

Каковы соображения безопасности при принятии и выполнении произвольных искровых SQL-запросов?

Представьте себе следующую установку:

Два файла на HDFS регистрируются в виде таблиц и a_secretsb_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") 

Эти две точки зрения, я мог бы обеспечить, используя права доступа к файлам просто HDFS. Но у меня есть следующие логические представления этих таблиц, которые я хотел бы выставить:

# 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") 

Теперь предположим, я получаю произвольное (user, pass, query) множество. Я получаю список учетных записей пользователя может получить доступ:

groups = get_groups(user, pass) 

и извлечь логический план запроса из запроса пользователя:

spark.sql(query).explain(true) 

дает мне план запроса по линии (это точный план запроса состоит)

== 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 ... 

Предполагая, что я могу разобрать логический план запроса, чтобы определить, какие именно таблицы и файлы осуществляется доступ, безопасно предоставить доступ к данным, полученных в результате выполнения запроса? Я думаю о потенциальных проблемах, таких как:

• Существуют ли способы доступа к зарегистрированным таблицам без их появления в логическом плане запроса?
• Способы загрузки новых данных и регистрации их в виде таблиц через чистую искру SQL? (ввод в spark.sql(1))?
• Имеют ли пользователи доступ к любым функциям sql с побочными эффектами (которые изменяют или получают доступ к неаризованным данным)?
• Существуют ли способы регистрации UDF/выполнения произвольного кода только через spark.sql(1)?

Резюмируя: Могу ли я безопасно принимать произвольные SQL, зарегистрировать его df = spark.sql(1), анализировать доступ к данным с помощью df.explain(True), а затем возвращать результаты, используя, например, df.collect()?

редактирует: - 23 января 15:29: отредактированные включать префикс "EXPLAIN" в

Answer 1

TL; DR Вы никогда не должны выполнить какие-либо ненадежный код на Спарк кластера.

Есть ли способы загрузить новые данные и зарегистрировать их в виде таблиц через чистую искру SQL?

Да. CREATE TABLE может быть выполнен с использованием метода sql, поэтому, если пользователи имеют разрешения на доступ к файловой системе, они могут создавать таблицы.

Существуют ли способы регистрации UDF/выполнения произвольного кода только через spark.sql (1)?

Да, до тех пор они могут контролировать, которые классам, могут быть изменены с SQL.

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

У пользователей есть доступ к любым SQL функций с побочными эффектами (что изменяет или доступ самовольных данные)?

Фактически Да (по расширению предыдущей точки).

Могу ли я безопасно принимать произвольные SQL,

Нет.