Как Kerberos обрабатывает несколько запросов TGT в одном узле для одной и той же службы и для одного и того же клиента? - PullRequest
Новая
       6

Как Kerberos обрабатывает несколько запросов TGT в одном узле для одной и той же службы и для одного и того же клиента?

0 голосов
/ 17 мая 2018

Для моего понимания архитектуры Kerberos клиент должен получить конкретный Ticket-Granting-Ticket (TGT) от сервера аутентификации, чтобы иметь возможность взаимодействовать со службой.Эти TGT содержат:

  • идентификатор клиента
  • сетевой адрес клиента
  • срок действия билета
  • ключ сеанса клиента / TGS.

Я получил это от здесь

Давайте представим, что у меня есть основной рабочий процесс, который содержит: файлы pig, hive и spark, мне понадобятся три различных TGT,по одному на услугу, чтобы использовать их все успешно.

Одним из элементов в TGT является период действия билета.Давайте представим, что это установлено на 8 часов.

Насколько я понимаю, если основной рабочий процесс требует, скажем, 10 часов, он может потерпеть неудачу после 8-го часа, так как срок действия билета закончится.

Так что, как я понимаю, каждые 8 ​​часов будет необходимо обновлять этот TGT, чтобы без проблем взаимодействовать со службой.

Теперь я думал, как возможный подход, чтобы иметь фон.обновляйте этот TGT каждые 8 ​​часов, поэтому у клиента всегда будет действительный ключ сеанса TGS для любой необходимой службы.

Возможная проблема этого подхода заключается в том, что между этим обновлением может быть промежуток, даже 30 секунд.промежуток или 1 минута для любой задержки, которая может привести к тому, что клиент имеет недопустимый сеансовый ключ TGS.

Мой вопрос : возможно ли обновлять этот сеансовый ключ TGS каждые 6 часов,что значит получить новый TGT с предыдущим все еще в силе?И что произойдет, если вы сделаете этот запрос TGT, когда действительный еще существует?заменен / удален старый, оба хранятся в клиенте или этот новый запрос просто игнорируется?

Я совершенно новичок в этом, поэтому, если есть другие способы решения этой проблемы, пожалуйста, дайте мне знать.

1 Ответ

0 голосов
/ 17 мая 2018

Да, вы можете обновить свою программу, чтобы использовать эту таблицу ключей, вместо того чтобы полагаться на TGT, который уже существует в кэше.Это делается с помощью класса UserGroupInformation из пакета Hadoop Security. 

val configuration = new Configuration
configuration.addResource("/etc/hadoop/conf/hdfs-site.xml")
UserGroupInformation.setConfiguration(configuration)

UserGroupInformation.getCurrentUser.setAuthenticationMethod(AuthenticationMethod.KERBEROS)
UserGroupInformation.loginUserFromKeytabAndReturnUGI(
  "hadoop.kerberos.principal", " path of hadoop.kerberos.keytab file")
  .doAs(new PrivilegedExceptionAction[Unit]() {
    @Override
    def run(): Unit = {

      // logic

    }
  })

Выше мы указываем имя нашего участника службы и путь к сгенерированному нами файлу keytab.Пока эта таблица ключей действительна, наша программа будет использовать желаемый субъект службы для всех действий, независимо от того, прошел ли пользователь, выполняющий программу, аутентификацию и получил TGT.

...