Архитектура Knox
Функции
Knox является шлюзом, предоставляющим единую точку аутентификации и доступа к сервисам кластера Hadoop.
Основные возможности Knox перечислены ниже:
-
Безопасность периметра для REST API сервисов кластера Hadoop:
-
Предоставление токенов и аутентификации.
-
Возможность интегрировать аутентификацию с корпоративными и облачными системами управления (LDAP).
-
Предоставление SSL для сервисов, которые не имеют возможности использовать протокол по умолчанию.
-
Централизованный контроль за счет использования единого шлюза, который поддерживает аудит и авторизацию (при помощи Ranger).
-
-
Единый URL для объединения REST API сервисов кластера Hadoop:
-
Контроль количества эндпойнтов.
-
Сокрытие внутренней топологии Hadoop от потенциальных атак.
-
-
Упрощенный доступ благодаря инкапсуляции сервисов с Kerberos или использованию одного SSL-сертификата.
Архитектура
Шлюз Knox является слоем поверх сервера Jetty JEE и обладает двумя механизмами расширения: сервис и провайдер. Сервисный фреймворк позволяет добавлять поддержку новых HTTP-эндпойнтов, а провайдер позволяет добавлять функции, которые используются различными сервисами.
Работа Knox состоит из двух фаз: развертывание и runtime. Во время фазы развертывания топологии конвертируются в детали имплементации, основанные на веб-архивах JEE (WAR). После этого в фазе runtime входящие запросы обрабатываются с помощью фильтров, настроенных в WAR. Более детальные диаграммы, которые отражают имплементацию описанных сущностей, можно найти в документации Knox.
Развертывание
Фаза развертывания служит для конвертации понятных человеку дескрипторов топологий в оптимизированные запускаемые артефакты. Данный процесс можно представить как компиляцию дескриптора в JEE WAR, который развертывается во встроенном контейнере JEE.
Этот фреймворк имеет одну особенность в виде сущности под названием contributor — она генерирует артефакты WAR из топологий. Согласно ее шаблону проектирования каждая топология сначала разбирается на конструкции, затем соответствующий contributor назначается каждой конструкции внутри файла топологии. После этого contributor получает конструкцию и обновляет артефакты WAR. Принцип работы Knox в этой фазе представлен ниже:
-
Топология загружается из директории conf/topologies во внутреннюю структуру.
-
Сервер-шлюз отправляет запрос фабрике развертывания на создание структуры WAR.
-
Фабрика развертывания создает базовую структуру WAR.
-
Каждая конструкция в топологии (провайдер и сервис) посещается, и для неё вызывается соответствующий contributor, который модифицирует структуру WAR, основываясь на информации в файле топологии.
-
Конечный вариант WAR возвращается шлюзу.
-
WAR динамически разворачивается через API внутреннего контейнера.
Runtime
Фаза runtime проще по своей логике относительно фазы развертывания, так как следует известным JEE-моделям. Ниже представлена диаграмма, отражающая порядок обработки запросов:
-
Клиент отправляет запрос некоторому сервису. Этот запрос получается встроенным JEE-контейнером.
-
В отображении URL к цепям фильтров ищется нужная цепь фильтров.
-
Вызывается цепь фильтров (которая и сама является фильтром).
-
Каждый фильтр вызывает последующий фильтр в цепи.
-
Происходит вызов последнего фильтра. Обычно это особый фильтр отправки, который ответственен за отправку запроса на конечный ресурс. Фильтры отправки также отвечают за чтение ответа.
-
Получение ответа.
-
Ответ пробрасывается через различные обертки, добавленные фильтрами. Эти обертки могут изменять ответ в зависимости от их настройки.
-
Ответ получается контейнером через обертку фильтра ответа.
-
Ответ возвращается клиенту.
Knox в ADPS
В то время как Kerberos используется для аутентификации внутри системы Hadoop, Knox позволяет новым пользователям использовать API системы без необходимости работы с Kerberos. О роли Knox в системе ADPS можно узнать в статье Обзор ADPS.
Так как в Knox можно настроить LDAP-аутентификацию и авторизацию через Ranger, следующая схема работы может быть построена. Часть с Ranger представляет работу плагина Ranger Knox.
