Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
На этой странице объясняется, как Azure Databricks использует Lakeguard для принудительной изоляции пользователей в общих вычислительных средах и детальном управлении доступом в выделенных вычислительных средах.
Что такое Lakeguard?
Lakeguard — это набор технологий в Databricks, которые применяют изоляцию кода и фильтрацию данных, чтобы несколько пользователей могли безопасно и экономично использовать один вычислительный ресурс, а также получать доступ к данным с детализированными элементами управления доступом в вычислительных ресурсах, предоставляющим привилегированный доступ.
Как работает Lakeguard?
В общих вычислительных средах, таких как стандартные классические вычисления, бессерверные вычисления и хранилища SQL, Lakeguard изолирует пользовательский код от обработчика Spark и других пользователей. Эта конструкция позволяет многим пользователям совместно использовать одни и те же вычислительные ресурсы, сохраняя строгие границы между пользователями, драйвером Spark и исполнителями. Поскольку такая изоляция обеспечена, стандартные вычислительные среды могут нативно применять детализированные средства контроля доступа, такие как фильтрация строк и маскирование столбцов.
Выделенные вычислительные ресурсы используют классическую архитектуру Spark, в которой пользовательский код не изолирован от движка, поэтому в ней невозможно применять детализированные механизмы контроля доступа без риска избыточного извлечения данных. Вместо этого выделенные вычислительные ресурсы передают фильтрацию данных бессерверным вычислительным ресурсам вашей рабочей области, которые изолированы с помощью Lakeguard и выполняют фильтрацию от их имени. Именно поэтому точное управление доступом на выделенных вычислительных ресурсах требует, чтобы ваша рабочая область была включена для бессерверных вычислений. См. тонкое управление доступом на выделенных вычислительных ресурсах.
Классическая архитектура Spark
На следующем рисунке показано, как в традиционной архитектуре Spark пользовательские приложения совместно используют JVM с привилегированным доступом к базовому компьютеру.
Архитектура Lakeguard
Lakeguard изолирует весь пользовательский код с помощью безопасных контейнеров. Это позволяет выполнять несколько рабочих нагрузок в одном вычислительном ресурсе, сохраняя строгую изоляцию между пользователями.
Изоляция клиента Spark
Lakeguard изолирует клиентские приложения от драйвера Spark и друг от друга с помощью двух ключевых компонентов:
Spark Connect: Lakeguard использует Spark Connect (представлено с Apache Spark 3.4) для разъединять клиентские приложения от драйвера. Клиентские приложения и драйверы больше не используют один и тот же JVM или classpath. Это разделение предотвращает несанкционированный доступ к данным. Такая архитектура также не позволяет пользователям получать доступ к данным, возвращаемым в результате избыточной выборки, когда запросы содержат фильтры на уровне строк или столбцов.
Замечание
Spark Connect откладывает анализ и разрешение имен во время выполнения, что может изменить поведение кода. См . статью "Сравнение Spark Connect с классической версией Spark".
Изоляция контейнеров: Каждое клиентское приложение работает в собственной изолированной контейнерной среде. Это предотвращает доступ пользовательского кода к данным других пользователей или к базовой системе. Песочница использует методы изоляции на основе контейнеров для создания безопасных границ между пользователями.
Изоляция UDF
По умолчанию исполнители Spark не изолируют UDF. Отсутствие изоляции может позволить UDF записывать файлы или получать доступ к базовой машине.
Lakeguard изолирует пользовательский код, включая пользовательские функции (UDF), на исполнителях Spark следующим образом:
- Изоляция среды выполнения на исполнителях Spark.
- Изоляция исходящего сетевого трафика пользовательских функций для предотвращения несанкционированного внешнего доступа.
- Репликация клиентской среды в песочницу UDF, чтобы пользователи могли получить доступ к необходимым библиотекам.
Эта изоляция распространяется на пользовательские функции (UDF) в стандартных вычислительных ресурсах, а также на пользовательские функции Python в бессерверных вычислительных ресурсах и хранилищах SQL.