Моя цель - запустить контейнер Windows Docker, который может проходить аутентификацию через Kerberos для доступа к Windows ресурсам. Для этого я отразил установку, которая отлично работает для Linux контейнеров. Я создал Docker образ на основе winamd64 / python, который устанавливает самый последний Kerberos MSI для Windows. Он запускает kinit для keytab для моего пользователя * и успешно генерирует тикет в указанном мной файле кэша. Фрагмент ниже:
RUN cmd /c "type nul > /path/to/krbcache"
RUN cmd /c "setx KRB5_CONFIG C:\path\to\krb5.conf"
RUN cmd /c "setx KRB5CCNAME C:\path\to\krbcache"
WORKDIR /path/to/
RUN cmd /c "kinit -k -t myuser_keytab myuser@REALM"
Когда я запускаю c в этот контейнер, я вижу тикет в файле krbcache, и все кажется великолепным. Но когда я запускаю klist, я вижу следующую ошибку:
A specified logon session does not exist. It may already have been terminated.
Более того, когда я запускаю c в работающий контейнер и запускаю kinit, это успешно завершается. Но если я открою вторую оболочку и выполнил команду c в том же работающем контейнере, klist сообщит о другом LogonId и не будет знать о сеансе.
Exec1@ContainerA>klist
Current LogonId is 0:0x21fdb825
Cached Tickets: (0)
Exec2@ContainerA>klist
Current LogonId is 0:0x2210bba0
...
A specified logon session does not exist. It may already have been terminated.
Несколько вопросов:
Почему для каждого exe c cmd.exe в одном и том же контейнере отображаются LogonIds как разные?
Почему таблица ключей успешно используется для генерировать тикет в кеше тикетов, но klist никогда не отображает кешированный тикет? В этом посте указана та же проблема в стандартном мире Windows, не относящемся к контейнерам, но разница в том, что билет все еще правильно аутентифицирован для этого пользователя, и в этом случае мой билет, похоже, вообще не используется ,
* Намерение не заключается в том, чтобы в долгосрочной перспективе поместить таблицу ключей в мое Docker изображение. Я просто делаю это в целях тестирования на моем компьютере разработчика.