Важно: Данный раздел актуален для Платформы данных On-Premise.
¶ 1 Введение
¶ 1.1 Наименование и условное обозначение
Наименование системы: RT.StreamingNiFi.
¶ 1.2 Область применения
RT.StreamingNiFi – программное обеспечение, предназначенное для организации ETL-процессов в рамках экосистемы RT.DataLake (Hadoop).
¶ 2 Администрирование RT.StreamingNiFi
¶ 2.1 Рекомендации по конфигурации
При работе в Linux необходимо учесть последующие рекомендации, так как типичные значения по умолчанию для Linux могут быть не настроены под нужды такого интенсивного приложения с высоким уровнем ввода-вывода, как RT.StreamingNiFi.
¶ 2.1.1 Максимальное количество дескрипторов файлов
RT.StreamingNiFi в любой момент потенциально может иметь очень большое количество открытых дескрипторов файлов. Увеличьте ограничения, отредактировав /etc/security/limits.conf, добавив что-то вроде:
* hard nofile 50000
* soft nofile 50000¶ 2.1.2 Максимальное количество разветвленных процессов
RT.StreamingNiFi может быть настроен на создание значительного количества потоков. Чтобы увеличить допустимое число, отредактируйте /etc/security/limits.conf.
* hard nproc 10000
* soft nproc 10000И ваш дистрибутив может потребовать редактирования /etc/security/limits.d/90-nproc.conf, добавив:
¶ 2.1.3 Увеличение количества доступных портов TCP-сокетов
Это особенно важно, если ваш поток будет устанавливать и отключать большое количество сокетов за небольшой промежуток времени.
sudo sysctl -w net.ipv4.ip_local_port_range="10000 65000"¶ 2.1.4 Продолжительность статуса сокетов TIMED_WAIT при закрытии
Установите, как долго сокеты остаются в статусе TIMED_WAIT при закрытии.
Вы не хотите, чтобы ваши сокеты простаивали слишком долго, поскольку вы хотите иметь возможность быстро настраивать и отключать новые сокеты. Установите что-то вроде этого:
для ядра 2.6
sudo sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait="1"для ядра 3.0
sudo sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait="1"¶ 2.1.5 Отключение обмена в Linux
Для некоторых приложений свопинг является нормой. Для RT.StreamingNiFi это не так, так как он всегда должен быть запущенным. Чтобы сообщить Linux, что вы хотите отключить свопинг, вы можете отредактировать /etc/sysctl.conf, добавив следующую строку:
vm.swappiness = 0Для партиций, обрабатывающих различные репозитории RT.StreamingNiFi, отключите такие функции, как atime. Это может привести к неожиданному увеличению производительности. Отредактируйте файл /etc/fstab и для необходимых партиций добавьте параметр noatime.
¶ 2.2 Рекомендуемые исключения антивируса
Антивирусному ПО может потребоваться много времени для сканирования больших каталогов и многочисленных файлов в них. Кроме того, если антивирусное ПО блокирует файлы или каталоги во время сканирования, эти ресурсы становятся недоступными для процессов RT.StreamingNiFi, что приводит к задержке или недоступности этих ресурсов в инстансе/кластере RT.StreamingNiFi. Чтобы предотвратить возникновение этих проблем с производительностью и надёжностью, настоятельно рекомендуется настроить антивирусное ПО на пропуск сканирования следующих каталогов RT.StreamingNiFi:
content_repository
flowfile_repository
logs
provenance_repository
state¶ 2.3 Конфигурация логирования
RT.StreamingNiFi использует logback в качестве имплементации ведения лога во время выполнения. Каталог conf содержит стандартную конфигурацию logback.xml с настройками приложения и уровня по умолчанию. Руководство logback содержит полный справочник доступных опций.
¶ 2.3.1 Стандартные файлы логов
Стандартная конфигурация лога включает в себя следующие определения приложений и связанные файлы логов:
|
Файл |
Описание |
|---|---|
| nifi-app.log | Лог приложения, содержащий сообщения фреймворка и компонентов. |
| nifi-bootstrap.log | Лог начальной загрузки, содержащий сообщения о запуске и завершении работы. |
| nifi-deprecation.log | Лог прекращения поддержки, содержащий предупреждения о компонентах и функциях, которые перестают поддерживаться вендором. |
| nifi-request.log | Лог HTTP-запросов, содержащий сообщения доступа к пользовательскому интерфейсу и REST API. |
| nifi-user.log | Лог пользователя, содержащий сообщения аутентификации и авторизации. |
¶ 2.3.2 Логирование прекращения поддержки
Файл nifi-deprecation.log содержит предупреждающие сообщения, описывающие компоненты и функции, которые будут удалены в последующих версиях. Предупреждения о прекращении поддержки следует оценивать и устранять, чтобы избежать серьёзных изменений при обновлении до новой мажорной версии. Устранение предупреждений о прекращении поддержки включает обновление до новых компонентов, изменение настроек свойств компонентов или рефакторинг классов пользовательских компонентов.
Логирование прекращения поддержки предоставляет метод проверки совместимости перед обновлением одной мажорной версии выпуска на другую. Обновление до последней минорной версии обеспечит наиболее точный набор предупреждений о прекращении поддержки.
Важно отметить, что логирование прекращения поддержки применимо как к компонентам, так и к функциям. Для логирования выводимых из поддержки функций требуется ссылка на затрагиваемое свойство или метод во время их выполнения. Отключённые компоненты с устаревшими свойствами или методами не будут создавать логи прекращения поддержки. По этой причине важно тестировать все настроенные компоненты достаточно долго, чтобы проверить стандартное поведение потока.
Логирование прекращения поддержки может генерировать повторяющиеся сообщения в зависимости от конфигурации компонента и шаблонов использования. Отключение логирования прекращения поддержки для определённого класса компонентов можно настроить, добавив элемент logger в logback.xml. Атрибут name должен начинаться с deprecation, за которым следует класс компонента. Установка атрибута level в значение OFF отключает логирование прекращения поддержки для указанного компонента.
<logger name="deprecation.org.apache.nifi.processors.ListenLegacyProtocol" level="OFF" />¶ 2.4 Конфигурирование безопасности
RT.StreamingNiFi предоставляет несколько различных вариантов конфигурации для целей безопасности. Наиболее важные свойства находятся в разделе security properties в файле nifi.properties. Для безопасной работы необходимо установить следующие свойства:
|
Свойство |
Описание |
|---|---|
| nifi.security.keystore | Имя файла Keystore, содержащего закрытый ключ сервера. |
| nifi.security.keystoreType | Тип Keystore. Должен быть PKCS12, JKS или BCFKS. JKS является предпочтительным типом, файлы BCFKS и PKCS12 загружаются поставщиком BouncyCastle. |
| nifi.security.keystorePasswd | Пароль Keystore. |
| nifi.security.keyPasswd | Пароль для сертификата в Keystore. Если значение не установлено, будет использоваться значение nifi.security.keystorePasswd. |
| nifi.security.truststore | Имя файла Truststore, которое будет использоваться для авторизации пользователей, подключающихся к RT.StreamingNiFi. Защищённый инстанс без Truststore отклоняет все входящие подключения. |
| nifi.security.truststoreType | Тип Truststore. Должен быть PKCS12, JKS или BCFKS. JKS является предпочтительным типом, файлы BCFKS и PKCS12 загружаются поставщиком BouncyCastle. |
| nifi.security.truststorePasswd | Пароль Truststore. |
После настройки вышеуказанных свойств мы можем включить доступ к пользовательскому интерфейсу через HTTPS вместо HTTP. Это достигается путём установки свойств nifi.web.https.host и nifi.web.https.port. Свойство nifi.web.https.host указывает, на каком имени хоста должен работать сервер. Если требуется, чтобы интерфейс HTTPS был доступен со всех сетевых интерфейсов, следует использовать значение 0.0.0.0. Чтобы администраторы могли настроить запуск приложения только на определённых сетевых интерфейсах, можно указать свойства nifi.web.http.network.interface* или nifi.web.https.network.interface*.
Внимание. При включении HTTPS важно, чтобы свойство nifi.web.http.port было отключено. RT.StreamingNiFi поддерживает работу только по HTTP или HTTPS, а не по обоим одновременно.
Веб-сервер RT.StreamingNiFi требует аутентификацию клиента на основе сертификата для пользователей, получающих доступ к пользовательскому интерфейсу, если не настроен альтернативный механизм аутентификации, для которого потребуется односторонний SSL (например, LDAP, OpenID Connect и т.д.). Включение альтернативного механизма аутентификации настроит веб-сервер на аутентификацию клиента на базе сертификатов WANT. Это позволит поддерживать пользователей с сертификатами, а те, у кого их нет, смогут входить в систему с учётными данными.
Теперь, когда пользовательский интерфейс защищён, мы можем легко защитить соединения Site-to-Site, а также коммуникации внутри кластера. Это достигается путём установки свойств nifi.remote.input.secure и nifi.cluster.protocol.is.secure соответственно в значение true. Для этих коммуникаций всегда требуется двусторонний SSL, поскольку ноды будут использовать настроенные keystore\truststore для аутентификации.
Автоматическое обновление SSL context factory RT.StreamingNiFi можно включить, используя следующие свойства:
|
Свойство |
Описание |
|---|---|
| nifi.security.autoreload.enabled | Указывает, следует ли автоматически перезагружать SSL context factory при обнаружении обновлений keystore и truststore. По умолчанию для него установлено значение false. |
| nifi.security.autoreload.interval | Указывает интервал, с которым keystore и truststore проверяются на наличие обновлений. Применяется только в том случае, если для параметра nifi.security.autoreload.enabled установлено значение true. Значение по умолчанию – 10 secs. |
Как только для свойства nifi.security.autoreload.enabled установлено значение true, любые действительные изменения в настроенном keystore и truststore приведут к перезагрузке SSL context factory RT.StreamingNiFi, что позволит клиентам принять изменения. Это предназначено для того, чтобы позволить обновлять сертификаты с истёкшим сроком действия в keystore и добавлять новые доверенные сертификаты в truststore, и все это без необходимости перезапуска сервера RT.StreamingNiFi.
Внимание. Изменения любого из свойств nifi.security.keystore* или nifi.security.truststore* не будут учитываться логикой автоматического обновления, которая предполагает, что пароли и пути к хранилищу останутся прежними.
¶ 2.4.1 TLS Toolkit
Для упрощения установки RT.StreamingNiFi и автоматического создания необходимых keystore, truststore и соответствующих файлов конфигурации можно использовать CLI tls-toolkit, что так же обеспечит безопасность многочисленных нод RT.StreamingNiFi.
¶ 2.4.1.1 Wildcard-сертификаты
Wildcard-сертификаты (т.е. две ноды node1.nifi.apache.org и node2.nifi.apache.org, которым назначается тот же сертификат с записью CN или SAN *.nifi.apache.org) официально не поддерживаются и не рекомендуются. Использование wildcard-сертификатов имеет множество недостатков. Записи SAN с wildcard допустимы, если каждый сертификат содержит дополнительную уникальную запись SAN и запись CN.
Потенциальные проблемы использования wildcard-сертификатов:
- Кластерные связи многократно используют идентификаторы сертификатов для определения ноды, а если сертификат представляет собой подстановочное DN, то он не даст ответа;
- Администраторам может потребоваться предоставить кастомный идентификатор ноды в authorizers.xml для *.nifi.apache.org, поскольку все действия прокси-сервера разрешаются только в сертификате DN;
- Администраторы не имеют возможности отслеживать, в какой ноде выполняется действие, так как все они направляются в один и тот же DN;
- Администраторы, запускающие несколько инстансов на одном компьютере и используя разные порты для их идентификации, могут случайно поместить ноду node1 с портом node2, и адрес будет в итоге удалён, потому что она использует тот же сертификат, а обработчик ноды блокирует его, так как имя ноды node1не указано в качестве допустимого хоста для инстанса node2;
- Если wildcard-сертификат скомпрометирован, все ноды оказываются под угрозой.
Внимание. Для keystores и truststores в RT.StreamingNiFi рекомендуются JKS. Этот инструмент позволяет задавать другие типы keystore в командной строке и игнорировать тип PKCS12 для использования в качестве truststore, потому что данный формат имеет проблемы совместимости между имплементациями BouncyCastle и Oracle.
¶ 2.4.1.2 Режимы работы
Инструмент командной строки tls-toolkit имеет два основных режима работы:
- Standalone (автономный) – создает организацию сертификатов, keystore, truststore и файлы nifi.properties в одной команде;
- Client/Server (Клиент/Сервер) – использует Certificate Authority Server, который принимает запросы на подписание сертификатов от клиентов, подписывает и отправляет обратно. И клиент, и сервер проверяют идентификацию друг друга через общий секрет.
¶ 2.4.1.2.1 Standalone
Автономный режим вызывается запуском ./bin/tls-toolkit.sh standalone -h и отображает информацию об использовании с описаниями опций, которые могут быть указаны.
В автономном режиме с tls-toolkit можно использовать следующие параметры командной строки:
- -a, --keyAlgorithm <arg> – алгоритм использования сгенерированных ключей (по умолчанию: RSA);
- -B, --clientCertPassword <arg> – пароль сертификата клиента. Должно быть либо одно значение, либо одно для каждого DN клиента (если не задано, генерируется автоматически);
- -c, --certificateAuthorityHostname <arg> – имя хоста RT.StreamingNiFi Certificate Authority (по умолчанию: localhost);
- -C, --clientCertDn <arg> – создание сертификата клиента, подходящего для использования в браузере, с указанным DN (может быть указан несколько раз);
- -d, --days <arg> – количество дней, в течение которых выданный сертификат является действительным (по умолчанию: 1095);
- -f, --nifiPropertiesFile <arg> – базовый файл nifi.properties для обновления (если не указан, используется встроенный файл, идентичный файлу по умолчанию при установке NiFi);
- -g, --differentKeyAndKeystorePasswords – использование другого сгенерированного пароля для ключа и keystore;
- -G, --globalPortSequence <arg> – использование последовательных портов, которые вычисляются для всех хостов в соответствии с предоставленными выражениями имен хостов (могут быть указаны несколько раз, но должны быть одинаковыми от запуска до запуска);
- -h, --help – печать справки и выход;
- -k, --keySize <arg> – количество бит для генерации ключей (по умолчанию: 2048);
- -K, --keyPassword <arg> – пароль ключа. Либо одно значение, либо одинаковое для каждого хоста (если не задано, генерируется автоматически);
- -n, --hostnames <arg> – список имен хостов через запятую;
- --nifiDnPrefix <arg> – строка для добавления имени хоста (в начало) при определении DN (по умолчанию: CN=);
- --nifiDnSuffix <arg> – строка для добавления имени хоста (в конец) при определении DN (по умолчанию: OU=NIFI);
- -o, --outputDirectory <arg> – каталог для вывода keystore, truststore и config-файлов (по умолчанию: ../bin);
- -O, --isOverwrite – перезапись существующего вывода хоста;
- -P, --trustStorePassword <arg> – пароль truststore. Либо одно значение, либо одинаковое для каждого хоста (если не задано, генерируется автоматически);
- -s, --signingAlgorithm <arg> – алгоритм подписи сертификатов (по умолчанию: SHA256WITHRSA);
- -S, --keyStorePassword <arg> – пароль keytstore. Либо одно значение, либо одинаковое для каждого хоста (если не задано, генерируется автоматически);
- --subjectAlternativeNames <arg> – разделенный запятыми список доменов для использования в качестве альтернативных имен в сертификате;
- -T, --keyStoreType <arg> – тип создаваемого keystore (по умолчанию: jks).
Шаблоны имен хостов:
- Для указания диапазона имен хостов используются квадратные скобки, например: [01-20];
- Круглые скобки используются для определения, что на хосте (хостах) работает больше, чем один инстанс RT.StreamingNiFi, например: (5).
Примеры:
- Создать 4 набора keystore , truststore, nifi.properties для localhost вместе с сертификатом клиента с предоставленным DN:
bin/tls-toolkit.sh standalone -n 'localhost(4)' -C 'CN=username,OU=NIFI'Создать keystore, truststore, nifi.properties для 10 имен хостов RT.StreamingNiFi в каждом из 4 поддоменов:
bin/tls-toolkit.sh standalone -n 'nifi[01-10].subdomain[1-4].domain'Создать 2 набора keystore, truststore, nifi.properties для 10 имен хостов RT.StreamingNiFi в каждом из 4 поддоменов вместе с сертификатом клиента с предоставленным DN:
bin/tls-toolkit.sh standalone -n 'nifi[01-10].subdomain[1-4].domain(2)' -C 'CN=username,OU=NIFI'¶ 2.4.1.2.2 Client/Server
Режим Клиент/Сервер опирается на Центр сертификации (Certificate Authority, CA) для выдачи сертификатов. Центр можно остановить, если узлы не подключены к сети.
¶ 2.4.1.2.2.1 Server
Сервер CA вызывается запуском ./bin/tls-toolkit.sh -h, который печатает информацию об использовании с описаниями опций, которые могут быть заданы.
В режиме сервера с tls-toolkit можно использовать следующие параметры командной строки:
- -a, --keyAlgorithm <arg> – алгоритм использования сгенерированных ключей (по умолчанию: RSA);
- --configJsonIn <arg> – место для чтения информации о конфигурации, подразумевает useConfigJson, если установлено (по умолчанию: значение configJson);
- -d, --days <arg> – количество дней, в течение которых выданный сертификат является действительным (по умолчанию: 1095);
- -D, --dn <arg> – DN для сертификата CA (по умолчанию: CN=YOUR_CA_HOSTNAME,OU=NIFI);
- -f, --configJson <arg> – место записи информации о конфигурации (по умолчанию: config.json);
- -F, --useConfigJson – флаг, указывающий, что вся конфигурация считывается из configJson(для облегчения автоматического использования, иначе в configJsonпроизводится только запись);
- -g, --differentKeyAndKeystorePasswords – использование другого сгенерированного пароля для ключа и keystore;
- -h, --help – печать справки и выход;
- -k, --keySize <arg> – количество бит для генерации ключей (по умолчанию: 2048);
- -p, --PORT <arg> – порт для прослушивания центром сертификации (по умолчанию: 8443);
- -s, --signingAlgorithm <arg> – алгоритм подписи сертификатов (по умолчанию: SHA256WITHRSA);
- -T, --keyStoreType <arg> – тип создаваемого keystore (по умолчанию: jks);
- -t, --token <arg> – маркер для предотвращения MITM (должен быть таким же, как тот, что используется клиентами).
¶ 2.4.1.2.2.1 Client
Клиент может использоваться для запроса новых сертификатов из центра сертификации. Утилита клиента генерирует пару ключей и запрос подписи сертификата (CSR, Certificate Signing Request), после чего отправляет CSR в центр сертификации. Клиент вызывается запуском ./bin/tls-toolkit.sh client -h, который печатает информацию об использовании с описаниями опций, которые могут быть заданы.
В режиме клиента с tls-toolkit можно использовать следующие параметры командной строки:
- -a, --keyAlgorithm <arg> – алгоритм использования сгенерированных ключей (по умолчанию: RSA);
- -c, --certificateAuthorityHostname <arg> – имя хоста RT.StreamingNiFi Certificate Authority (по умолчанию: localhost);
- -C, --certificateDirectory <arg> – каталог записи сертификата CA (по умолчанию: .);
- --configJsonIn <arg> – место для чтения информации о конфигурации, подразумевает useConfigJson, если установлено (по умолчанию: значение configJson);
- -D, --dn <arg> – DN для сертификата клиента (по умолчанию: CN=<localhost name>,OU=NIFI, заполняется автоматически инструментом);
- -f, --configJson <arg> – место записи информации о конфигурации (по умолчанию: config.json);
- -F, --useConfigJson – флаг, указывающий, что вся конфигурация считывается из configJson(для облегчения автоматического использования, иначе в configJsonпроизводится только запись);
- -g, --differentKeyAndKeystorePasswords – использование другого сгенерированного пароля для ключа и keystore;
- -h, --help – печать справки и выход;
- -k, --keySize <arg> – количество бит для генерации ключей (по умолчанию: 2048);
- -p, --PORT <arg> – порт для прослушивания центром сертификации (по умолчанию: 8443);
- --subjectAlternativeNames <arg> – разделенный запятыми список доменов для использования в качестве альтернативных имен в сертификате;
- -T, --keyStoreType <arg> – тип создаваемого keystore (по умолчанию: jks);
- -t, --token <arg> – маркер для предотвращения MITM (должен быть таким же, как тот, что используется клиентами).
В результате запуска клиента предоставляется сертификат CA, keystore, truststore и config.json с информацией о них, а также их пароли.
Сертификат клиента можно легко импортировать в браузер, указав: -T PKCS12.
¶ 2.5 Аутентификация пользователя
RT.StreamingNiFi поддерживает аутентификацию пользователей через сертификаты клиента, через имя пользователя и пароль, через Knox или через OpenId Connect.
Проверка подлинности имени пользователя и пароля выполняется с помощью “Идентификатора входа в систему” (“Login Identity Provider”) – это подключаемый механизм для аутентификации пользователей через их имя и пароль, настройка которого осуществляется в файле nifi.properties. В настоящее время RT.StreamingNiFi предлагает проверку имени пользователя и пароля с параметрами Provider Identity Provider для LDAP и Kerberos.
Свойство nifi.login.identity.provider.configuration.file указывает файл конфигурации для Идентификатора входа в систему. Свойство nifi.security.user.login.identity.provider указывает, какой из настроенных Login Identity Provider должен использоваться. По умолчанию свойство не настроено, что означает, что username/password должно быть явно включено.
При аутентификации через OpenId Connect сервер RT.StreamingNiFi перенаправляет пользователей для проверки подлинности в Провайдер, а затем RT.StreamingNiFi вызывает Провайдер для получения идентификации пользователя.
При аутентификации через Knox сервер RT.StreamingNiFi перенаправляет пользователей для проверки подлинности в Knox, а затем RT.StreamingNiFi во время аутентификации пользователя проверяет токен Knox.
Внимание. Аутентификация пользователя в RT.StreamingNiFi может быть настроена только по username/password, OpenId Connect или Knox. Сервер не поддерживает одновременный запуск каждого из них. При этом RT.StreamingNiFi потребуются сертификаты клиентов для аутентификации пользователей через HTTPS, если ничто иное не настроено.
К защищенному инстансу RT.StreamingNiFi нельзя получить доступ анонимно, если в LDAP или Kerberos не настроен Login Identity Provider, который, в свою очередь, должен быть настроен на явное разрешение анонимного доступа. При этом анонимный доступ в настоящее время невозможен по умолчанию в FileAuthorizer.
Внимание. RT.StreamingNiFi не выполняет аутентификацию пользователя через HTTP (используя HTTP, всем пользователям предоставляются все роли).
¶ 2.5.1 Lightweight Directory Access Protocol (LDAP)
Далее приведен пример с описанием настроек Login Identity Provider, который интегрируется с Directory Server для аутентификации пользователей.
<provider>
<identifier>ldap-provider</identifier>
<class>org.apache.nifi.ldap.LdapProvider</class>
<property name="Authentication Strategy">START_TLS</property>
<property name="Manager DN"></property>
<property name="Manager Password"></property>
<property name="TLS - Keystore"></property>
<property name="TLS - Keystore Password"></property>
<property name="TLS - Keystore Type"></property>
<property name="TLS - Truststore"></property>
<property name="TLS - Truststore Password"></property>
<property name="TLS - Truststore Type"></property>
<property name="TLS - Client Auth"></property>
<property name="TLS - Protocol"></property>
<property name="TLS - Shutdown Gracefully"></property>
<property name="Referral Strategy">FOLLOW</property>
<property name="Connect Timeout">10 secs</property>
<property name="Read Timeout">10 secs</property>
<property name="Url"></property>
<property name="User Search Base"></property>
<property name="User Search Filter"></property>
<property name="Identity Strategy">USE_DN</property>
<property name="Authentication Expiration">12 hours</property>
</provider>С помощью данной конфигурации аутентификация имени пользователя и пароля может быть активирована путем ссылки на провайдер в nifi.properties:
nifi.security.user.login.identity.provider=ldap-provider
|
Свойство |
Описание |
|---|---|
| Authentication Strategy | Аутентификация подключения к LDAP-серверу. Возможные значения: ANONYMOUS, SIMPLE, LDAPS или START_TLS. |
| Manager DN | DN менеджера, который используется для привязки к LDAP-серверу для поиска пользователей. |
| Manager Password | Пароль менеджера, который используется для привязки к LDAP-серверу для поиска пользователей. |
| TLS - Keystore | Путь к Keystore при подключении к LDAP с использованием LDAPS или START_TLS. |
| TLS - Keystore Password | Пароль для Keystore при подключении к LDAP с использованием LDAPS или START_TLS. |
| TLS - Keystore Type | Тип Keystore при подключении к LDAP с использованием LDAPS или START_TLS (то есть JKS или PKCS12). |
| TLS - Truststore | Путь к Truststore при подключении к LDAP с использованием LDAPS или START_TLS. |
| TLS - Truststore Password | Пароль для Truststore при подключении к LDAP с использованием LDAPS или START_TLS. |
| TLS - Truststore Type | Тип Truststore при подключении к LDAP с использованием LDAPS или START_TLS (то есть JKS или PKCS12). |
| TLS - Client Auth | Политика аутентификации клиента при подключении к LDAP с использованием LDAPS или START_TLS. Возможные значения: REQUIRED, WANT, NONE. |
| TLS - Protocol | Протокол при подключении к LDAP с использованием LDAPS или START_TLS (TLS, TLSv1.1, TLSv1.2 и т.д.). |
| TLS - Shutdown Gracefully | Указывает, следует ли корректно завершать работу TLS перед закрытием целевого контекста. По умолчанию: false. |
| Referral Strategy | Стратегия обработки рефералов. Возможные значения: FOLLOW, IGNORE, THROW. |
| Connect Timeout | Время ожидания соединения (10 секунд). |
| Read Timeout | Время ожидания чтения (10 секунд). |
| Url | Разделенный пробелами список URL-адресов серверов LDAP (например, ldap://<hostname>:<port>). |
| User Search Base | Базовый DN для поиска пользователей (например, CN=Users,DC=example,DC=com). |
| User Search Filter | Фильтр для поиска пользователей в User Search Base (sAMAccountName={0}). Указанное пользователем имя вставляется в {0}. |
| Identity Strategy | Стратегия идентификации пользователей. Возможные значения: USE_DN и USE_USERNAME. По умолчанию: - USE_DN (для сохранения обратной совместимости). USE_DN использует полный DN пользовательской записи (рекомендуется). USE_USERNAME использует имя пользователя, под которым он вошел в систему. |
| Authentication Expiration | Продолжительность действия проверки подлинности пользователя. Если пользователь никогда не выходит из системы, он должен будет снова войти в систему в течение указанного времени. |
¶ 2.5.2 Kerberos
Далее приведен пример с описанием настроек Login Identity Provider, который интегрируется с Kerberos Key Distribution Center (KDC) для аутентификации пользователей.
provider>
<identifier>kerberos-provider</identifier>
<class>org.apache.nifi.kerberos.KerberosProvider</class>
<property name="Default Realm">NIFI.APACHE.ORG</property>
<property name="Kerberos Config File">/etc/krb5.conf</property>
<property name="Authentication Expiration">12 hours</property>
</provider>С помощью данной конфигурации аутентификация имени пользователя и пароля может быть активирована путем ссылки на провайдер в nifi.properties:
nifi.security.user.login.identity.provider=kerberos-provider
|
Свойство |
Описание |
|---|---|
| Default Realm | Область по умолчанию для предоставления пользователю в случае, если пользователь вводит неполный пользовательский принципал (например, NIFI.APACHE.ORG). |
| Kerberos Config File | Абсолютный путь к файлу конфигурации клиента Kerberos. |
| Authentication Expiration | Продолжительность действия проверки подлинности пользователя. Если пользователь никогда не выходит из системы, он должен будет снова войти в систему в течение указанного времени. |
¶ 2.5.3 OpenId Connect
Для включения аутентификации через OpenId Connect необходимо настроить свойства в nifi.properties, представленные далее в таблице.
|
Свойство |
Описание |
|---|---|
| nifi.security.user.oidc.discovery.url | URL-адрес обнаружения необходимого OpenId Connect Provider. |
| nifi.security.user.oidc.connect.timeout | Время ожидания соединения при обмене данными с OpenId Connect Provider. |
| nifi.security.user.oidc.read.timeout | Время ожидания чтения при обмене данными с OpenId Connect Provider. |
| nifi.security.user.oidc.client.id | Идентификатор клиента для RT.StreamingNiFi после регистрации в OpenId Connect Provider. |
| nifi.security.user.oidc.client.secret | Секрет клиента для RT.StreamingNiFi после регистрации в OpenId Connect Provider. |
| nifi.security.user.oidc.preferred.jwsalgorithm | Предпочтительный алгоритм проверки токенов идентификации. Если значение свойства пустое, по умолчанию используется RS 256, поддерживаемое OpenId Connect Provider в соответствии со спецификацией. Если значение равно HS256, HS384 или HS512, RT.StreamingNiFi пытается проверить защищенные токены HMAC, используя указанный секретный ключ. Если значение свойства равно none, RT.StreamingNiFi пытается проверить незащищенные/простые токены. Иные значения для алгоритма анализируются как алгоритм RSA или EC, который используется совместно с JSON Web Key (JWK), предоставленным через jwks_uri в метаданных URL-обнаружения. |
¶ 2.5.4 Knox
Для включения аутентификации через Knox необходимо настроить свойства в nifi.properties, представленные далее в таблице.
|
Свойство |
Описание |
|---|---|
| nifi.security.user.knox.url | URL-адрес страницы входа в Knox. |
| nifi.security.user.knox.publicKey | Путь к открытому ключу Knox для проверки подписей токенов аутентификации в HTTP Cookie. |
| nifi.security.user.knox.cookieName | Имя файла HTTP Cookie, которое Knox создает после успешного входа в систему. |
| nifi.security.user.knox.audiences | (Опционально) Разделенный запятыми список разрешенных подключений. Если значение задано, подключение должно присутствовать в списке. Разрешенные подключения, заполненные токеном, могут быть настроены в Knox. |
¶ 2.5.5 Настройка пользователей и политик доступа
В зависимости от характеристик настроенных параметров UserGroupProvider и AccessPolicyProvider пользователи, группы и политики могут конфигурироваться в пользовательском интерфейсе. Если расширения не настроены, то в пользовательском интерфейсе пользователи, группы и политики доступны только для чтения. Если сконфигурированный авторизатор не использует UserGroupProvider и AccessPolicyProvider, пользователи и политики могут быть или не быть видимыми и настраиваемыми в пользовательском интерфейсе на основе базовой реализации.
Далее в главе предполагается, что пользователи, группы и политики настраиваются в пользовательском интерфейсе, и описывается:
- Создание пользователей и групп;
- Политики доступа;
- Настройка политик доступа на основе конкретных примеров.
¶ 2.5.6 Создание пользователей и групп
В пользовательском интерфейсе необходимо выбрать Users в глобальном меню, при этом открывается диалоговое окно для создания пользователей и групп и управления ими. Для создания пользователей и групп используется кнопка Add User.
Для создания пользователя в новом открывшемся диалоговом окне необходимо выбрать Individual и ввести информацию Identity, соответствующую методу аутентификации защиты инстанса RT.StreamingNiFi. После чего нажать ОК.
Для создания группы в диалоговом окне следует выбрать Group, ввести имя группы в поле Identity и отметить пользователей в Members, которые необходимо включить в группу. После чего нажать ОК.
¶ 2.5.7 Политики доступа
Управление возможностями пользователей и групп RT.StreamingNiFi осуществляется с помощью политик доступа. Существует два типа политик доступа, которые могут быть применены к ресурсу:
- View (просмотр) – если ресурсу назначается политика просмотра, то добавленные в эту политику пользователи и группы могут только видеть детали данного ресурса;
- Modify (изменение) – если ресурсу назначается политика изменения, то добавленные в эту политику пользователи и группы могут изменить конфигурацию данного ресурса.
Создавать и применять политики доступа можно как на глобальном уровне, так и на уровне компонентов.
¶ 2.5.7.1 Global Access Policies
Политики глобального доступа управляют следующими полномочиями на уровне системы:
|
Policy |
Privilege |
Global Menu Selection | Resource Descriptor |
|---|---|---|---|
| view the UI | Разрешение пользователям просматривать UI. | N/A | /flow |
| access the controller | Позволяет пользователям просматривать/изменять контроллер, включая задачи отчетности, службы контроллеров и узлы в кластере. | Controller Settings | /controller |
| query provenance | Позволяет пользователям отправлять Provenance Search и запрашивать Event Lineage. | Data Provenance | /provenance |
| access restricted components | Позволяет пользователям создавать/изменять ограниченные компоненты при условии наличия других разрешений. Ограниченные компоненты могут указывать, какие конкретные разрешения требуются. Разрешения могут предоставляться для определенных ограничений или независимо от них. Если разрешение предоставляется независимо от ограничений, пользователь может создавать/изменять все ограниченные компоненты. | N/A | /restricted-components |
| access all policies | Позволяет пользователям просматривать/изменять политики для всех компонентов. | Policies | /policies |
| access users/user groups | Позволяет пользователям просматривать/изменять пользователей и группы пользователей. | Users | /tenants |
| retrieve site-to-site details | Позволяет другим инстансам RT.StreamingNiFi извлекать информацию site-to-site. | N/A | /site-to-site |
| view system diagnostics | Позволяет пользователям просматривать системную диагностику. | Summary | /system |
| proxy user requests | Позволяет прокси отправлять запросы от имени других пользователей. | N/A | /proxy |
| access counters | Позволяет пользователям просматривать/изменять счетчики доступа. | Counters | /counters |
¶ 2.5.7.2 Component Level Access Policies
Политики доступа на уровне компонентов управляют следующими полномочиями на уровне компонентов:
|
Policy |
Privilege |
Resource Descriptor & Action |
|---|---|---|
| view the component | Позволяет пользователям просматривать детали конфигурации компонентов. | resource=”/<component-type>/<component-UUID>” action=”R” |
| modify the component | Позволяет пользователям изменять детали конфигурации компонентов. | resource=”/<component-type>/<component-UUID>” action=”W” |
| view provenance | Позволяет пользователям просматривать события происхождения, созданные компонентом. | resource=”/provenance-data/<component-type>/<component-UUID>” action=”R” |
| view the data | Позволяет пользователям просматривать метаданные и содержимое компонента в очередях потока в исходящих соединениях и через события происхождения. | resource=”/data/<component-type>/<component-UUID>” action=”R” |
| modify the data | Позволяет пользователям очищать очереди потоков в исходящих соединениях и повторно отправлять через события происхождения. | resource=”/data/<component-type>/<component-UUID>” action=”W” |
| view the policies | Позволяет пользователям просматривать список пользователей, которые могут просматривать/изменять компонент. | resource=”/policies/<component-type>/<component-UUID>” action=”R” |
| modify the policies | Позволяет пользователям изменять список пользователей, которые могут просматривать/изменять компонент. | resource=”/policies/<component-type>/<component-UUID>” action=”W” |
| receive data via site-to-site | Позволяет порту получать данные из инстансов RT.StreamingNiFi. | resource=”/data-transfer/input-ports/<port-UUID>” action=”W” |
| send data via site-to-site | Позволяет порту отправлять данные из инстансов RT.StreamingNiFi. | resource=”/data-transfer/output-ports/<port-UUID>” action=”W” |
Внимание. Политики доступа можно применять ко всем типам компонентов, кроме соединений. Разрешения на соединения определяются по индивидуальным политикам доступа к исходному и целевому компонентам соединения, а также по политике доступа группы процессов, содержащей компоненты. Более подробно это описано далее в примерах.
Внимание. Для доступа к List Queue и Delete Queue для соединения пользователю требуются политики “view the data” и “modify the data” на компоненте. Так же все узлы в кластерной среде должны быть добавлены к этим политикам, так как запрос пользователя может быть реплицирован через любой узел в кластере.
¶ 2.5.8 Настройка политик доступа на основе конкретных примеров
Самый эффективный способ понять, как создавать и применять политики доступа, – это пройтись по некоторым распространенным примерам. В приведенных далее сценариях User1 является администратором, а User2 – недавно добавленным пользователем, которому предоставлен доступ только к пользовательскому интерфейсу. На рисунке в качестве отправных точек показаны два процессора в рабочей области: GenerateFlowFile и LogAttribute.
User1 может добавлять компоненты в поток данных, а также перемещать, редактировать и подключать все процессоры. Детали и свойства процессоров и групп процессов root видны для User1.
_rt.streaming.png)
User2 не может добавлять компоненты в поток данных, а также перемещать, редактировать и подключать компоненты. Детали и свойства процессоров и групп процессов root скрыты от User2.
_rt.streaming.png)
¶ 2.5.8.1 Перемещение процессора
User1 необходимо выполнить следующие шаги для выдачи разрешения пользователю User2 на перемещение процессора GenerateFlowFile в потоке данных с сохранением привилегий у User1:
1. Выбрать процессор GenerateFlowFile.
2. Нажать значок Access Policies на панели управления Operate. При этом открывается диалоговое окно Access Policies.
3. Выбрать modify the component в раскрывающемся списке политики. Политика modify the component, которая в настоящее время существует на процессоре (дочернем), является унаследованной от группы процессов root (родительской), на которой User1 имеет привилегии.
4. Нажать ссылку Override. При замещении политики необходимо выбрать ее переопределение либо на копию унаследованной политики, либо на пустую политику. Для создания копии следует в диалоговом окне Override Policy выбрать Copy и нажать кнопку Override.
5. В созданной политике выбрать значок Add User. В поле User Identity ввести вручную или найти в списке User2 и нажать OK.
6. С такими изменениями User1 сохраняет возможность перемещения обоих процессоров в рабочей области. А User2 теперь может перемещать процессор GenerateFlowFile.
¶ 2.5.8.2 Изменение процессора
В приведенном примере “Перемещение процессора” User2 добавлен в политику modify the component для процессора GenerateFlowFile. Но без возможности просмотра свойств процессора User2 не может изменять его конфигурацию – чтобы отредактировать компонент, пользователь должен быть также включен в политику view the component.
User1 необходимо выполнить следующие шаги для реализации возможности изменения конфигурации процессора пользователю User2:
1. Выбрать процессор GenerateFlowFile.
2. Нажать значок Access Policies на панели управления Operate. При этом открывается диалоговое окно Access Policies.
3. Выбрать view the component в раскрывающемся списке политики. Политика view the component, которая в настоящее время существует на процессоре (дочернем), является унаследованной от группы процессов root (родительской), на которой User1 имеет привилегии.
4. Нажать ссылку Override и в открывшемся диалоговом окне, сохранив политику копирования по умолчанию, нажать кнопку Override.
5. В созданной политике выбрать значок Add User. В поле User Identity ввести вручную или найти в списке User2 и нажать OK.
С такими изменениями User1 сохраняет возможность просмотра и редактирования процессоров в рабочей области. А User2 теперь может просматривать и редактировать процессор GenerateFlowFile.
¶ 2.5.8.3 Создание подключения
При настройке политик так, как описано в предыдущих двух примерах, User1 может подключить GenerateFlowFile к LogAttribute.
При этом User2 не имеет права доступа на установку соединения процессоров.
Это объясняется тем, что:
- User2 не имеет доступа к изменениям в группе процессов;
- Несмотря на то, что User2 имеет право на просмотр и изменение исходного компонента (GenerateFlowFile), User2 не имеет политики доступа к целевому компоненту (LogAttribute).
User1 необходимо выполнить следующие шаги для реализации возможности подключения GenerateFlowFile к LogAttribute пользователю User2:
1. Выбрать группу процессов root, при этом панель управления Operate обновляется с подробными сведениями.
2. Выбрать значок Access Policies на панели управления Operate. При этом открывается диалоговое окно Access Policies.
3. В диалоговом окне в раскрывающемся списке политики выбрать modify the component.
4. Выбрать значок Add User. В поле User Identity ввести вручную или найти в списке User2 и нажать OK.
Добавляя User2 в политику modify the component группы процессов, User2 так же добавляется к политике modify the component в процессоре LogAttribute путем наследования. Чтобы проверить это, необходимо в рабочей области выделить процессор LogAttribute и выбрать значок Access Policies на панели управления Operate. При этом открывается диалоговое окно политик доступа процессора LogAttribute с наличием пользователя User2 в политике modify the component.
С такими изменениями User2 теперь может подключать процессор GenerateFlowFile к процессору LogAttribute.
¶ 2.5.8.4 Изменение соединения
В следующем сценарии User1и User2 добавляют процессор ReplaceText в группу процессов root.
User1 может выбрать и изменить существующее соединение между GenerateFlowFile и LogAttribute, чтобы подключить GenerateFlowFile к ReplaceText.
При этом User2 не имеет возможности выполнить такое действие.
User1 необходимо выполнить следующие шаги для реализации возможности подключения GenerateFlowFile к ReplaceText пользователю User2:
1. Выбрать группу процессов root, при этом панель управления Operate обновляется с подробными сведениями.
2. Выбрать значок Access Policies на панели управления Operate. При этом открывается диалоговое окно Access Policies.
3. В диалоговом окне в раскрывающемся списке политики выбрать view the component.
4. Выбрать значок Add User. В поле User Identity ввести вручную или найти в списке User2 и нажать OK.
Будучи добавленным к политикам просмотра и изменения для группы процессов User2 теперь может подключать процессор GenerateFlowFile к процессору ReplaceText.
¶ 2.6 Kerberos Service
RT.StreamingNiFi может быть настроен для использования Kerberos SPNEGO (или “Kerberos Service”) для аутентификации. В таком случае пользователи попадают в конечную точку REST /access/kerberos, и сервер отвечает кодом состояния 401 с заголовком задачи WWW-Authenticate: Negotiate. Далее сервер связывается с браузером для использования GSS-API и загрузки тикета пользователя Kerberos с указанием его в качестве заголовка Base64 в последующем запросе. Он принимает форму Authorization: Negotiate YII…, и RT.StreamingNiFi пробует подтвердить этот билет с помощью KDC. В случае успеха принципал пользователя возвращается как подлинный, и поток следует аутентификации login/credential, в результате которой в ответ выдается JWT для предотвращения ненужных издержек аутентификации Kerberos при каждом последующем запросе. В случае если билет пользователя не подтверждается, то он возвращается с соответствующим кодом ошибки. После чего пользователь может предоставить свои учетные данные для формы регистрации Kerberos при условии настроенного KerberosLoginIdentityProvider.
RT.StreamingNiFi отвечает на запросы Kerberos SPNEGO только по соединению HTTPS, поскольку незащищенные запросы никогда не проходят проверку подлинности.
Для включения аутентификации службы Kerberos в nifi.properties должны быть настроены следующие свойства:
|
Свойство |
Значение |
Описание |
|---|---|---|
| Service Principal | true | Принципал сервиса, используемый RT.StreamingNiFi для связи с KDC. |
| Keytab Location | true | Путь к файлу keytab, содержащему принципал сервиса. |
Примечания:
- Kerberos чувствителен к регистру во многих местах, и сообщения об ошибках (или их отсутствие) могут быть недостаточно понятны. Рекомендуется проверить у службы чувствительность к регистру в конфигурационных файлах. Конвенция – HTTP/fully.qualified.domain@REALM;
- Браузеры имеют разные уровни ограничений при работе с SPNEGO. Некоторые из них предоставляют локальный тикет Kerberos в любой запрашиваемый домен, в то время как другие выдают пустой список доверенных доменов. Справочная информация для общих браузеров приведена в Приложении 1;
- Некоторые браузеры (например, устаревший IE) не поддерживают последние алгоритмы шифрования, такие как AES, и ограничены устаревшими алгоритмами (например, DES). Это следует учитывать при создании keytabs;
- Должен быть настроен KDC, определен принципал сервиса для RT.StreamingNiFi и экспортирован keytab. Подробные инструкции по настройке и администрированию Kerberos Service выходят за рамки данного документа (MIT Kerberos Admin Guide), но далее приведен пример.
Пример добавления принципала для сервера на nifi.nifi.apache.org и экспорта ключа из KDC:
root@kdc:/etc/krb5kdc# kadmin.local
Authenticating as principal admin/admin@NIFI.APACHE.ORG with password.
kadmin.local: listprincs
K/M@NIFI.APACHE.ORG
admin/admin@NIFI.APACHE.ORG
...
kadmin.local: addprinc -randkey HTTP/nifi.nifi.apache.org
WARNING: no policy specified for HTTP/nifi.nifi.apache.org@NIFI.APACHE.ORG; defaulting to no policy
Principal "HTTP/nifi.nifi.apache.org@NIFI.APACHE.ORG" created.
Principal "HTTP/nifi.nifi.apache.org@NIFI.APACHE.ORG" created.
kadmin.local: ktadd -k /http-nifi.keytab HTTP/nifi.nifi.apache.org
Entry for principal HTTP/nifi.nifi.apache.org with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/http-nifi.keytab.
Entry for principal HTTP/nifi.nifi.apache.org with kvno 2, encryption type des-cbc-crc added to keytab WRFILE:/http-nifi.keytab.
kadmin.local: listprincs
HTTP/nifi.nifi.apache.org@NIFI.APACHE.ORG
K/M@NIFI.APACHE.ORG
admin/admin@NIFI.APACHE.ORG
...
kadmin.local: q
root@kdc:~# ll /http*
-rw------- 1 root root 162 Mar 14 21:43 /http-nifi.keytab
root@kdc:~#¶ 2.7 Удаление/Добавление компонентов сервиcа RT.StreamingNiFi
Доступно с версии 1.4.11.
Внимание. Описанные ниже операции не удаляют/добавляют хост из кластера – они лишь управляют компонентом NiFi Server и NiFi-Registry на хостах. Удаление хоста из кластера возможно в разделе “Hosts” кластера при условии, что к хосту не привязан ни один компонент.
Для добавления или удаления RT.StreamingNiFi с хостов необходимо воспользоваться соответствующими кнопками выпадающего меню, доступного по нажатию на иконку в поле “Actions” сервиса RT.StreamingNiFi.
¶ 2.7.1 Добавление компонентов Nifi Server и Nifi-Registry
Когда хосты становятся доступными для подключения по ssh для менеджера кластеров, необходимо выбрать действие Expand cервиса RT.StreamingNiFi из списка возможных операций. В появившемся диалоговом окне предоставляется выбор опций:
- Disable SELinux before cluster installation – отключение SELinux на добавляемых хостах. Для того, чтобы данная настройка применилась, после завершения операции Expand необходимо перезагрузить хосты вручную;
- Disable Firewalld before cluster installation – выключение firewalld на добавляемых хостах;
- Install OpenJDK before cluster installation – установка пакета java-1.8.0-openjdk на добавляемых хостах;
- Set vm.swappiness to 0 for all hosts – отключение swapping на добавляемых хостах;
- Append hosts into /etc/hosts file before cluster installation – запись добавляемых нод в /etc/hosts на всех хостах кластера. Данную опцию рекомендуется отключить, если настроен DNS.
После выбора опций для перехода к следующей странице конфигурации следует нажать кнопку “Next”, и в открывшейся форме необходимо распределить компонент Nifi Server по добавляемым хостам. Также есть возможность установить Nifi-Registry, если ранее он не был установлен. В случае если используется сервис Monitoring Clinets, его компоненты также необходимо разместить на добавляемых хостах.
Расширение сервиса запускается кнопкой Run. На добавленные хосты устанавливаются необходимые пакеты и производится их настройка. Текущая конфигурация Flow, представленная в flow.xml.gz, копируется на новый хост.
¶ 2.7.2 Удаление Nifi Server
Для удаления одного или нескольких Nifi Server с хостов кластера необходимо:
1. Выбрать действие Shrink cервиса RT.StreamingNiFi из списка возможных операций, что приводит к появлению окна распределения компонента по хостам;
2. Любым из двух способов удалить привязку компонента к хосту (компонент Nifi Server выделяется белым цветом, как возможный к удалению с хостов):
- Выбрать компонент в колонке Components и убрать выделение с хостов в колонке Hosts, рамки которых выделены зеленым цветом;
- Выбрать хост в колонке Hosts и убрать выделение с компонента Nifi Server в колонке Components, если рамка компонента Nifi Server выделяется зеленым цветом.
3. Нажать кнопку Run в нижней части окна.
Внимание. Описанная процедура не удаляет данные и пакет RT.StreamingNiFi c хоста – онa лишь выводит ноду из кластера RT.StreamingNiFi.
¶ 3 Интеграция сервисов MiNiFi и RT.StreamingNiFi
RT.StreamingNiFi предоставляет, помимо RT.StreamingNiFi и MiNiFi, поддержку централизованного управления MiNiFi Agent с помощью MiNiFi C2 Server. Данный сервис обеспечивает автоматическое обновление конфигураций MiNiFi Agent без сторонних вспомогательных средств. В данном разделе приведены основные шаги для настройки взаимодействия между MiNiFi и RT.StreamingNiFi сервисами:
- создание шаблона;
- проверка конфигурации.
¶ 3.1 Создание шаблона
Для выполнения какой-либо задачи MiNiFi Agent необходимо создать шаблон в интерфейсе RT.StreamingNiFi. В данном разделе представлен элементарный шаблон для сбора содержимого файла с машин MiNiFi Agent.
После установки RT.StreamingNiFi и MiNiFi, в разделе Template появляется шаблон с название simple-minifi-listener, который состоит из следующих элементов.
Чтобы создать шаблон для Агентов, необходимо перейти в MiNiFi Process Group и создать Flow, который будет выполнятся непосредственно MiNiFi Agent.
В нашем случае созданный Flow содержит процессор TailFile, который считывает содержимое файла и передает инстансу RT.StreamingNiFi.
Для успешной загрузки Flow на MiNiFi Agent, необходимо сохранить шаблон с названием указанным в nifi.minifi.notifier.ingestors.pull.http.query с добавлением версии (например, minifi.v1). Если вы изменили Flow, то для актуализации его на агентах необходимо увеличить версию шаблона (например, minifi.v2).
Автоматическое обновление конфигурации MiNiFi Agent происходит с периодичностью, заданной nifi.minifi.notifier.ingestors.pull.http.period.ms. Если шаблон был неправильно собран, то Агенты продолжат работу на последней работоспособной конфигурации.
¶ 3.2 Проверка конфигурации
Текущую конфигурацию Flow, которую запрашивают MiNiFi Agent у MiNiFi C2 Server, можно проверить, обратившись к API MiNiFi C2 Server.
¶ 4 Обзор RT.StreamingNiFi Toolkit
Набор инструментов RT.StreamingNiFi (RT.StreamingNiFi Toolkit) содержит несколько утилит командной строки (CLI) для настройки и поддержки RT.StreamingNiFi в автономных и кластеризованных средах. Утилиты включают в себя:
- CLI — Инструмент cli позволяет администраторам взаимодействовать с инстансами RT.StreamingNiFi и NiFi Registry для автоматизации таких задач, как развертывание версий потоков и управление группами процессов и узлами кластера.
- Encrypt Config — инструмент encrypt-config шифрует конфиденциальные ключи в файле nifi.properties, чтобы облегчить настройку защищенного инстанса RT.StreamingNiFi.
- File Manager — инструмент File Manager позволяет администраторам создавать резервные копии, устанавливать или восстанавливать RT.StreamingNiFi из резервной копии.
- Flow Analyzer — инструмент flow-analyzer создает отчет, который помогает администраторам понять максимальный объем данных, который может быть сохранен при обратном давлении (backpressure) для данного потока.
- Node Manager — инструмент Node Manager позволяет администраторам выполнять проверку состояния нод, а также возможность подключать, отключать или удалять ноды из кластера.
- Notify — инструмент Notify позволяет администраторам отправлять bulletins в интерфейс RT.StreamingNiFi.
- S2S — инструмент s2s позволяет администраторам отправлять или получать данные RT.StreamingNiFi flows site-to-site.
- TLS Toolkit — утилита tls-toolkit генерирует необходимые keystores, truststore и соответствующие конфигурационные файлы для облегчения настройки защищенного инстанса RT.StreamingNiFi.
- ZooKeeper Migrator — инструмент zk-migrator позволяет администраторам:
- переместить информацию ZooKeeper из одного кластера ZooKeeper в другой.
- перенести права ноды ZooKeeper.
¶ Приложение 1. Настройка браузеров для согласования SPNEGO
E. 1 Firefox
Выполните следующие действия, чтобы убедиться, что ваш браузер Firefox включен для выполнения проверки подлинности Spnego:
- Откройте Firefox.
- В поле адрес введите about:config.
- В поле фильтр/поиск введите negotiate.
- Параметр network.negotiate-auth.trusted-uris может быть установлен по умолчанию https://, который не работает для вас. Вообще говоря, этот параметр должен быть заменен адресом сервера, если требуется делегирование Kerberos.
- Рекомендуется использовать https для всех коммуникаций.
Е. 2 Chrome
С Google Chrome вам, как правило, нужно установить параметры командной строки, чтобы серверы белого списка с Chrome договорились.
- на машинах Windows (клиентах): Chrome разделяет конфигурацию с Internet Explorer, поэтому, если все изменения были применены к IE (как описано в E. 3), ничего не должно передаваться через параметры командной строки.
- на машинах (клиентах) Linux/Mac OS: параметр командной строки --auth-negotiate-delegate-whitelist должен использоваться только в том случае, если требуется делегирование Kerberos (в противном случае не устанавливайте этот параметр).
- Рекомендуется использовать https для всех коммуникаций.
--auth-server-whitelist="*.example.com"
--auth-negotiate-delegate-whitelist="*.example.com"Вы можете увидеть, какие политики включены, набрав chrome://policy/ в адресной строке Chrome.
С Linux Chrome также будет читать файлы политики из каталога /etc/opt/chrome/policies/managed.
mypolicy.json.
{
"AuthServerWhitelist" : "*.example.org",
"AuthNegotiateDelegateWhitelist" : "*.example.org",
"DisableAuthNegotiateCnemeLookup" : true,
"EnableAuthNegotiatePort" : true
}E. 3 Internet Explorer
Выполните следующие действия, чтобы убедиться, что браузер Internet Explorer включен для выполнения проверки подлинности Spnego.
- Откройте Internet Explorer.
- Выберите Инструменты > Параметры Intenet >> Безопасность>> вкладка.
- В разделе Локальная интрасеть убедитесь, что ваш сервер является доверенным, т.е. добавьте его в список.