У меня есть небольшая сеть, включающая NAS, на котором я подготовил, с некоторыми усилиями, сервер Kerberos. Сервер Kerberos позволяет хостам Linux в сети создавать безопасные монтирования NFS. Ключи служб, созданные на KDC, распространяются на соответствующие хосты, а монтирования настраиваются с помощью безопасности Kerberos. Небезопасные монтирования блокируются политикой, настроенной на NAS.
Неудобно, что пользователи могут получить доступ к файлам на монтированиях только при наличии у них активных билетов на хосте от KDC. Это требование является ограничительным из-за неудобства, и тем более из-за ограничения доступа к монтированиям автоматизированными задачами, запущенными с разрешениями обычного пользователя.
В ранние дни NFS файлы на удаленном томе отображались как локальные, начиная с загрузки и непрерывно в течение всего сеанса системы. Безопасность и управление идентификацией являются важными преимуществами Kerberos в NFS, но требование предоставления пользователям билетов часто не является необходимым. Поскольку распределение ключей и контролируемый доступ к хостам предотвращают нежелательный доступ к монтированиям NFS, мне не нужны пользовательские билеты.
В идеале я хотел бы, чтобы пользователи имели доступ к монтированиям, имеющим защиту Kerberos, без запроса билета от KDC или даже без необходимости регистрации принципала на нем. Любой пользователь имел бы доступ в любое время к любому файлу, при условии, что доступ не будет ограничен разрешениями на каждый файл.
Насколько близко к этому целевому сценарию можно приблизиться с помощью существующих инструментов?
решение1
Короткий ответ заключается в том, что текущий механизм аутентификации NFS Kerberos (RPCSEC_GSS) не поддерживает это. Принципал, который делает вызов, — это тот, кто получает доступ. Так что если вы не хотите, чтобы пользователивручнуюполучить билеты, тогда вам нужно будет, чтобы хост автоматически получал билетыдляих.
В будущем новый протокол RPCSEC_GSSv3 может иметь опции, позволяющие хостам выдавать себя за произвольных пользователей, но он еще не завершен и не реализован.
Если вы хотите разрешить хостам выдавать себя за любой UID, то вам вообще не нужен Kerberos — переключитесь обратно в sec=sys
режим безопасности, который использовался «в старые времена». В этом режиме хост буквально может указать символический идентификатор пользователя. (Конечно, проверки разрешений все еще происходят.)
В конце концов, нет никакой функциональной разницы между разрешением хосту выдавать себя за любого пользователя через Kerberos (аутентификация с использованием /etc/krb5.keytab хоста) и разрешением хосту выдавать себя за любого пользователя с помощью базового утверждения UID (аутентификация с использованием закрытого ключа IPsec или WireGuard хоста) — и последний вариант обеспечит вам гораздо более высокую производительность, чем может достичь GSSAPI.
В Kerberos, при использовании только существующих инструментов (без прямой реализации какой-либо аутентификации на уровне хоста для RPC), наиболее близким к этому являетсяограниченное делегирование с переходом протокола(S4U2Self + S4U2Proxy), где службе разрешено получать билеты на определенные другие службы от имени пользователя. Это обычно используется в средах Active Directory, но также поддерживается MIT Kerberos KDC (ивероятноHeimdal KDCs – код есть, спасибо Samba, но я не знаю, как включить его в Heimdal).
Чтобы включить эту функцию в MIT Kerberos KDC, вам необходимо использовать бэкэнд LDAP; файловый бэкэнд HDB не поддерживает хранение дополнительных полей.
Установите
ok_to_auth_as_delegate
флаг принципала на принципале хоста клиента (это можно сделать через kadmin или с помощью операции OR0x200000
вkrbTicketFlags
атрибуте LDAP).kadmin.local modprinc +ok_to_auth_as_delegate host/foo.example.com
Установите атрибут LDAP принципала клиента
krbAllowedToDelegateTo
на список принципалов служб NFS, для которых он может создавать поддельные билеты. (Одна служба на значение.)ldapmodify <<EOF dn: krbPrincipalName=host/[email protected],cn=EXAMPLE.COM,ou=Kerberos,o=Example add: krbAllowedToDelegateTo krbAllowedToDelegateTo: nfs/fs1.example.com - EOF
Проверьте работу функций S4U с правами root:
# Acquire host credentials using system keytab host_cc=FILE:/tmp/krb5cc_host kinit -c $host_cc -k klist -c $host_cc # Acquire NFS tickets on behalf of the user using S4U2Proxy kvno -c $host_cc -I $user_name -P nfs/fs1.example.com klist -c $host_cc # Do the same, but put the tickets in that user's cache # so that rpc.gssd would be able to find them user_cc=FILE:/tmp/krb5cc_$(id -u $user) kvno -c $host_cc -I $user -P nfs/fs1.example.com --out-cache $user_cc chown $user: $user_cc
Установитьgss-проксина клиенте и отредактируйте его include,
nfs-client.conf
чтобы использовать S4U2Proxy вместо отдельных клиентских keytab:[service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U impersonate = yes allow_any_uid = yes trusted = yes euid = 0
Этот пример основан наhttps://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#имитация-пользователя-через-ограниченное-делегирование.
Настройте клиентаrpc.gssdдемон для использования gss-proxy, добавив
GSS_USE_PROXY=1
в среду:# systemctl edit rpc-gssd [Service] Environment=GSS_USE_PROXY=1 # systemctl restart rpc-gssd
Если Kerberos используется исключительно для NFS и если каждому хосту нужен только ограниченный набор пользователей, то хост может хранитьклиентские клавиши(которые хранят ключи, полученные из паролей) для этих пользователей. Это примерно эквивалентно хранению паролей пользователей, поскольку keytab позволяет