Как следует настраивать файлы ключей на стороне клиента для каждой клиентской машины для доступа к сетевым службам? Мой рабочий пример - NFSv4, который требует, чтобы у каждого клиента была таблица ключей Kerberos локально на клиентских машинах (а также на хостах серверов NFS).
Какие недостатки, если таковые имеются, могут возникнуть в результате совместного использования одного и того же ключа в общем файле keytab (для целей NFS) между всеми клиентскими машинами, которым требуется доступ к хосту (-ам) NFS?
Если по результату №1 мы действительно нужно использовать отдельный ключ на другой вкладке на каждый клиент, каков эффективный и, что более важно, безопасный способ автоматизировать создание keytab для каждой из нескольких тысяч машин? Я не хочу создавать и экспортировать ключ для каждой коробки!
Общая keytab вообще бесполезна - принцип службы Kerberos привязан к имени хоста. Таким образом, обычная клавиша просто не будет работать. Вам не обязательно нужен специальный ключ NFS - в зависимости от того, какую версию ОС вы используете. Мы можем использовать HOST/full.qualified.hostname для аутентификации NFS на RHEL 6+.
Так что да, вам нужен keytab на каждой машине. Я знаю, что это ужасно, но это нормально.
Имейте в виду, что в домене Windows вы должны эффективно проделать то же самое с процессом «присоединения к домену» - одна из основных вещей, которая это делает, - это создание keytab на клиентах Windows.
Мы начали путь интегрированных доменов - привязывая наших клиентов Linux к Windows AD. При таком подходе вы можете использовать net команда в Linux, например net ads join который, я думаю, является частью SAMBA. Вы можете встроить в него имя пользователя и пароль и запустить его через любой уже имеющийся у вас механизм автоматизации. (net ads keytab create тоже делает .... ну именно то, что написано на жестяной банке. )
Если вы не используете AD, боюсь, я не знаю. Я бы предположил, что что-то подобное существует для создания keytab.
Я написал код для решения вашей проблемы, но он не сработает для всех. Проблема в том, что вы должны найти способ расширить доверие к ненадежному оборудованию. У каждого сайта будет свой способ сделать это.
Я использую ключ ssh, который устанавливается нашим управлением конфигурацией, чтобы расширить доверие к ненадежным машинам.
Код, который я написал, находится в
https://github.com/bbense/aeakos
Но на самом деле это скорее схема того, как решить сложную проблему автоматической установки keytabs.
Что касается использования общей вкладки для клиента, она может работать для некоторых служб на основе Kerberos, но я никогда не видел, чтобы она использовалась для керберизованной NFS. И вообще, вы хотите, чтобы на каждой машине был хотя бы host / foo.com, чтобы в полной мере использовать все возможности Kerberos. Если вы не можете этого сделать, в развертывании Kerberos нет смысла.
Теоретически общая клиентская keytab должна работать, если вы хотите, чтобы каждая машина имела доступ к одним и тем же серверам / файлам. На практике вам придется провести тщательный анализ того, как сервер nfs использует аутентификацию Kerberos для реализации авторизации, чтобы убедиться, что все работает правильно.
Часть успешного использования kerberos состоит в том, чтобы помнить, что он выполняет только аутентификацию, авторизация всегда зависит от приложения. Все, что я сделал с NFSV4, предполагает, что он ожидает уникальный идентификатор Kerberos для каждого клиентского хоста, но у меня нет доказательств того, что он требуется.