kerberos билет и использование токена делегирования в Hadoop Oozie shell action

Question

Я новичок в hadoop и пытаюсь понять, почему мое действие оболочки oozie не берет новый билет даже после выполнения kinit. вот мой сценарий.

1. Я использую свой идентификатор «А» и имею билет на кеберос для своего идентификатора. Я отправляю oozie worklow с действием оболочки, используя мой идентификатор. Внутри действия оболочки oozie Я делаю еще один kinit, чтобы получить билет на ID «B». Только этот идентификатор «B» имеет доступ к некоторому файлу HDFS. kinit работает отлично, так как klist показал билет на идентификатор «B». Теперь, когда я читаю файл HDFS, доступ к которому имеет только B, я получаю разрешение на отказ в ошибке, говоря, что «A» не имеет разрешения на доступ к этому файлу. Но когда я делаю то же самое из linux cli, вне oozie, после того, как я делаю kinit и беру билет на «B», я могу прочитать файл HDFS как «B». Но тот же самый шаг не работает внутри действия оболочки oozie, и команды hadoop fs всегда, похоже, работают как пользователь, который представил рабочий процесс oozie, а не пользователь, для которого присутствует билет kerberos. Может кто-нибудь объяснить, почему это происходит? Я не могу это понять.

2. В том же действии оболочки, хотя команда hadoop fs не изменилась на пользователя «B», оболочка hbase работает как пользователь B. Только для тестирования я создал таблицу hbase, к которой имеет доступ только «A». Я добавил оболочку hbase для выполнения команды get в этой таблице. Если я сделаю kinit -kt для пользователя «B» и получит свой билет, это тоже не получится, если «B» не имеет доступа к этой таблице. Поэтому я думаю, что hbase берет новый билет вместо токена делегирования пользователя, представляющего рабочий процесс oozie. Когда я не выполняю kinit -kt внутри действия оболочки, команда hbase успешно завершается. Если я делаю kinit, я даже не мог запускать запросы на улей, говоря, что «A» не имеет доступа к какому-либо каталогу, например/tmp/B /, к которому имеет доступ только «B», поэтому я не мог понять, как работает куст, если он принимает токен делегирования, который создается при отправке рабочего процесса oozie или если он берет новый билет, созданный для нового пользователя.
   Может кто-нибудь, пожалуйста, помогите мне понять приведенный выше сценарий? Какие службы hadoop берут новый билет для аутентификации и какие команды принимают токен делегирования (например, команды hadoop fs)? Это то, как это работает, или я делаю что-то неправильно? Я просто не понимаю, почему одна и та же команда hadoop fs работала извне oozie как другой пользователь, но не работала внутри действия оболочки oozie даже после kinit.

3. Когда этот токен делегирования фактически создается? Создается ли он только при подаче oozie worklow или даже я выдаю команды hadoop fs? Спасибо!

Answer 1

В теории - Oozie автоматически передает учетные данные подателю (т.е. А) пряжу контейнеров, работающих на работу. Вам не нужно заботиться о kinit, потому что на самом деле это слишком поздно для этого.
Вы не должны выдавать себя за другого пользователя внутри из работы Oozie, что противоречило бы цели строгой аутентификации Kerberos

На практике это более сложно - (1) ядро ​​Hadoop услуги (HDFS, НИТИ) проверьте токен Kerberos только один раз, затем они создадут «токен делегирования», который распределяется между всеми узлами и всеми службами.

(2) пользователь oozie службы особые привилегии, он может сделать вид Hadoop «Суд», так что он подключается к ПРЯЖАМ, как oozie но ПРЯЖА создает «фишку делегирования» для работы заявителя (т.е. A) и вот и все, вы не можете изменить изменение этого токена.

(3) ну, на самом деле вы можете использовать альтернативный маркера, но только с некоторым пользовательским Java кодом, который явно создает UserGroupInformation объекта для альтернативного пользователя. Интерфейсы командной строки Hadoop этого не делают.

(4) как насчет неосновного Hadoop, то есть HBase или Hive Metastore, или не-Hadoop, т. Е. Zookeeper? Они вообще не используют «токены делегирования». Либо вы явно укажете UserGroupInformation в Java-коде, либо токен Kerberos по умолчанию используется во время подключения.
Вот почему ваша оболочка HBase работала, и если бы вы использовали Beeline (тонкий клиент JDBC) вместо Hive (устаревший толстый клиент), он, вероятно, тоже сработал бы.

(5) Oozie пытается заполнить этот пробел с конкретными <credentials> варианты улья, Beeline ("Hive2" действие), HBase и т.д.; Я не уверен, как это работает, но это должно подразумевать кеш кеша Kerberos, отличного от дефолта, локально для ваших контейнеров заданий.

Answer 2

Мы обнаружили, что после того, как запущен рабочий процесс oozie, мы можем стать другим лидером по обузданию. Мы должны запустить действие оболочки, которое затем запускает java с пользовательским -Djava.security.auth.login.config = custom_jaas.conf, который затем предоставит jvm kinit'ed как кому-то еще. Это происходит по линии Самсона (3), хотя этот кинит может быть даже совершенно иным царством.