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

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

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

Я получил это отсюда

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

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

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

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

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

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

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

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

Источник

1 ответ

Решение

Да, вы можете обновить свою программу, чтобы использовать эту таблицу ключей вместо того, чтобы полагаться на 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.

Источник
Другие вопросы по тегам