В этой статье для дата-инженеров и разработчиков распределенных приложений рассмотрим, какие механизмы обеспечения информационной безопасности поддерживает Apache Spark и как организовать безопасное взаимодействие Spark-приложения с хранилищами данных в экосистеме Hadoop.
Безопасная работа Spark-приложений с сервисами Hadoop
Многие технологии Big Data изначально оптимизированы для хранения и аналитики больших объемов данных с высокой производительностью и надежностью. Информационной безопасности не уделялось столько внимания. В частности, в Apache Spark многие функции безопасности, такие как проверка подлинности, по умолчанию не включены. Поэтому при развертывании кластера, открытого для доступа извне, важно предотвратить запуск неавторизованных приложений. Spark поддерживает несколько типов развертывания, каждый из которых поддерживает разные уровни безопасности, причем ни один из них не является безопасным по умолчанию. Исторически так сложилось, что кластер Spark и его сервисы обычно развертываются не в общедоступной сети, а в корпоративном пространстве. Поэтому доступ к узлам и портам, используемым сервисами Spark, должен быть ограничен исходными узлами, которым необходим доступ к этим службам.
Обычно приложения Apache Spark работают с данными, хранящимися в корпоративном озере, основанных на компонентах экосистемы Hadoop, таких как распределенная файловая система HDFS или NoSQL-СУБД Hive и HBase. Поэтому важно обеспечить безопасное взаимодействие Spark-приложения с этим хранилищами данных. Например, Spark поддерживает отправку приложений в средах, использующих защищенный протокол Kerberos для проверки подлинности компьютерной сети. Kerberos использует локальную форму идентификации с помощью билетов (ticket), предоставляемых сервером аутентификации. Любой билет зашифрован и имеет область действия (realm), покрывающие набор нужных сервисов. Для использования билета необходимо несколько уровней дешифрования, что исключает отправку конфиденциальных данных по сети. В большинстве случаев Spark использует учетные данные текущего вошедшего в систему пользователя при аутентификации в службах, поддерживающих Kerberos. Такие учетные данные можно получить, войдя в настроенный центр распространения ключей (KDC, Key Distribution Center), например, с помощью kinit – инструмента получения и кэширования билетов выдачи билетов Kerberos.
Кроме того, при взаимодействии с Hadoop-сервисами Spark-приложению необходимо получить токены делегирования, чтобы нелокальные процессы могли пройти аутентификацию. При использовании файловой системы Hadoop (HDFS или WebHDFS) Spark получит соответствующие токены для службы, в которой размещается домашний каталог пользователя. Токен HBase будет получен, если HBase находится в пути к классам приложения, а в конфигурации HBase включена проверка подлинности Kerberos ( hbase.security.authentication=kerberos). Аналогично будет получен токен Hive, если Hive находится в пути к классам, а конфигурация включает URI для удаленных служб хранилища метаданных, т.е. определен параметр hive.metastore.uri. Если приложению необходимо взаимодействовать с другими защищенными файловыми системами Hadoop, их URI должны быть явно предоставлены Spark во время запуска. Это делается путем их перечисления в конфигурации spark.kerberos.access.hadoopFileSystems.
Spark также поддерживает пользовательских поставщиков токенов делегирования с помощью механизма служб Java. Реализации org.apache.spark.security.HadoopDelegationTokenProviderможно сделать доступными для Spark, перечислив их имена в соответствующем JAR-файле метаданных в каталоге META-INF/services. Поддержка токена делегирования в настоящее время поддерживается только в режимах YARN и Mesos. Можно вручную исключить обновление токена делегирования Kerberos в планировщике ресурсов, который пока поддерживается только на YARN.
Долго работающие приложения могут столкнуться с проблемами, если время их выполнения превышает максимальное время жизни токена делегирования, настроенное в службах, к которым ему необходимо получить доступ. Spark поддерживает автоматическое создание новых токенов для таких приложений в YARN и Kubernetes (в клиентском и кластерном режимах) и в Mesos при использовании клиентского режима. Эту функцию можно включить, используя таблицу ключей keytab, чтобы приложение поддерживало действительный вход в систему Kerberos, который можно использовать для получения токенов делегирования на неопределенный срок.
При использовании таблицы ключей в кластерном режиме она будет скопирована на компьютер, на котором запущен драйвер Spark. В случае YARN это означает использование HDFS в качестве промежуточной области для keytab. Поэтому настоятельно рекомендуется, чтобы YARN и HDFS были защищены хотя бы шифрованием. Вместо этого также можно использовать кэш билетов, установив параметр spark.kerberos.renewal.credentials в значение ccache. При этом для аутентификации будет использоваться локальный кэш билетов Kerberos. Spark будет обновлять билет в течение срока его действия, но после истечения срока его действия необходимо будет приобрести новый билет с помощью уже упомянутой утилиты kinit. Пользователь должен поддерживать обновленный кэш билетов, который может использовать Spark. Расположение кэша билетов можно настроить, установив переменную среды KRB5CCNAME.
При развертывании Spark-приложений в Kubernetes, токены делегирования для аутентификации нелокальных процессов хранятся в секретах, которые совместно используются драйвером Spark и его исполнителями. Чтобы отправить задание Kerberos, следует определить переменную окружения: HADOOP_CONF_DIR или spark.kubernetes.hadoop.configMapName и обеспечить видимость KDC внутри контейнеров. Если необходимо использовать удаленный каталог HADOOP_CONF, который содержит файлы конфигурации Hadoop, следует установить в конфигурации spark.kubernetes.hadoop.configMapName уже существующий ConfigMap.
Тонкости аутентификации
В настоящее время Apache Spark поддерживает аутентификацию для каналов RPC с использованием общего секрета. Аутентификацию можно включить, установив параметр конфигурации spark.authenticate. Точный механизм, используемый для создания и распространения общего секрета, зависит от развертывания. Обычно секрет определяется в конфигурации spark.authenticate.secret. Если один и тот же секрет используется всеми приложениями и системными службами (демонами) Spark, это ограничивает безопасность таких развертываний, особенно в многопользовательских кластерах. Сервер отправки REST и MesosClusterDispatcher не поддерживают аутентификацию. Поэтому следует убедиться, что весь сетевой доступ к REST API и MesosClusterDispatcher (порты 6066 и 7077 соответственно по умолчанию) ограничен хостами, которым доверено отправлять задания.
При развертывании Spark-приложений под управлением YARN создание и распространение общего секрета выполняется автоматически: каждое приложение использует уникальный общий секрет. В случае YARN эта функция зависит от включенного шифрования YARN RPC для безопасного распределения секретов.
В Kubernetes фреймворк также автоматически генерирует секрет аутентификации, уникальный для каждого приложения. Секрет распространяется на поды-исполнители с использованием переменных среды. Это означает, что любой пользователь, который может перечислить модули в пространстве имен, где запущено Spark-приложение, также может видеть свой секрет аутентификации. Администратор Kubernetes должен настроить правила контроля доступа, чтобы обеспечить безопасность аутентификации приложения. В качестве альтернативы можно монтировать секреты аутентификации, используя файлы и секреты Kubernetes, которые пользователь монтирует в свои поды. При использовании файлов фреймворк не будет монтировать эти файлы в контейнеры – разработчику придется сделать это самостоятельно. При этом следует убедиться, что секретные файлы безопасно развернуты в контейнерах и что секретный файл драйвера согласуется с секретным файлом исполнителей.
Включение аутентификации для веб-интерфейсов осуществляется с помощью фильтров сервлетов javax. Необходим фильтр, который реализует нужный метод проверки подлинности. Изначально Spark не предоставляет встроенных фильтров для этого. Однако, фреймворк поддерживает управление доступом к пользовательскому интерфейсу при наличии фильтра проверки подлинности. Каждое приложение может быть настроено с собственными отдельными списками управления доступом (ACL) на просмотр пользовательского интерфейса приложения и изменение, включая уничтожение заданий в работающем приложении.
ACL-списки можно настроить для пользователей и для групп, используя в качестве входных данных списки, разделенные запятыми, чтобы предоставить нужные привилегии сразу нескольким пользователям или группам. Это удобно при работе в общем кластере: знак *, добавленный к определенному ACL, означает, что все пользователи будут иметь соответствующую привилегию. По умолчанию в списки управления доступом добавляется только пользователь, подавший заявку. Членство в группе устанавливается с помощью настраиваемого поставщика сопоставления групп, который настраивается с помощью конфигурации spark.user.groups.mapping.
В YARN просмотр и изменение ACL-списков предоставляются службе YARN при отправке приложений и контролируют, кто имеет соответствующие привилегии через интерфейсы YARN.
Аутентификация для веб-интерфейса сервера истории включается так же, как и для обычных приложений, с использованием фильтров сервлетов. Сервер истории использует те же параметры для настройки поставщика сопоставления групп, что и обычные Spark-приложения. В этом случае провайдер сопоставления групп будет применяться сервером истории ко всем серверам пользовательских интерфейсов, а конфигурации отдельных приложений будут игнорироваться.
Конфигурация SSL в Apache Spark организована иерархически. Пользователь может настроить параметры SSL по умолчанию, которые будут использоваться для всех поддерживаемых коммуникационных протоколов, если они не будут перезаписаны настройками, специфичными для протокола. Так можно указать общие настройки для всех протоколов, не отключая возможность настройки каждого из них по отдельности. Наконец, Apache Spark можно настроить для включения заголовков HTTP, чтобы предотвратить такие уязвимости как межсайтовый скриптинг (XSS), межфреймовый скриптинг (XFS), MIME-Sniffing, а также обеспечить строгую транспортную безопасность HTTP.
Шифрование и логирование
Apache Spark поддерживает шифрование на основе AES для подключений RPC. Шифрование AES использует библиотеку Apache Commons Crypto, доступ к которой настраивается в конфигурации Spark. Существует также поддержка шифрования на основе SASL, которое считается устаревшим, но по-прежнему используется в операциях перетасовки до версии 2.2.0. Также Spark поддерживает шифрование временных данных, записываемых на локальные диски. Сюда относятся shuffle-файлы, spill-эффект и блоки данных, хранящиеся на диске для кэширования и широковещательных переменных. Выходные данные, созданные приложениями с помощью saveAsHadoopFile или saveAsTable, а также временные файлы, явно созданные пользователем, шифруются по-другому.
Если Spark-приложения ведут журнал событий, то следует вручную создать spark.eventLog.dir — каталог, в который попадают журналы событий. Чтобы защитить файлы журналов, права доступа к каталогу должны быть установлены на drwxrwxrwxt. А владелец и группа каталога должны соответствовать суперпользователю, на котором работает сервер истории Spark. Это позволит всем пользователям записывать в каталог, но исключит возможность непривилегированным пользователям читать, удалять или переименовывать файл журнала, если он не принадлежит им. Файлы журнала событий будут созданы Spark с такими разрешениями, что только пользователь и группа имеют доступ для чтения и записи. Аналогичные действия следует выполнить для каталога, в который попадают журналы драйверов spark.driver.log.dfsDir, если приложения сохраняют журналы драйверов в клиентском режиме с включенной конфигурацией spark.driver.log.persistToDfs.enabled.
Читайте в нашей новой статье про обнаруженные и исправленные проблемы информационной безопасность Apache Spark за последние 3 года.
Узнайте больше про использование Apache Spark для разработки приложений аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Основы Apache Spark для разработчиков
- Анализ данных с Apache Spark
- Потоковая обработка в Apache Spark
- Машинное обучение в Apache Spark
- Графовые алгоритмы в Apache Spark
