У меня есть докер-контейнер под управлением CentOS 6 с пользователем без полномочий root и OpenLDAP. Когда я использую getent passwd он просто возвращает данные из /etc/passwd. Конфигурационный файл /etc/nsswitch.conf настраивается соответствующим образом (см. ниже) и authconfig-gtk используется для конфигурации. Интересно, что я могу получить всю информацию о пользователе с помощью
ldapsearch -x -b "dc=physik,dc=rwth-aachen,dc=de"
но он недоступен или не используется внутри контейнера докеров. Я что-то неправильно сконфигурировал или пропустил?
Установленные пакеты:
openldap openldap-clients nss-pam-ldapd authconfig-gtk
/etc/nsswitch.conf
passwd: files ldap
shadow: files ldap
group: files ldap
hosts: files dns
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files
netgroup: files ldap
publickey: nisplus
automount: files ldap
aliases: files nisplus
/etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
account required pam_access.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_ldap.so
С участием nslcd -d Я увидел, что адрес уже занят хост-системой. Я исправил это, установив сокет при выполнении docker run с участием
-v /var/run/nslcd/socket:/var/run/nslcd/socket
Я просто потратил большую часть дня, пытаясь запустить службу, которая, похоже, требует root (nslcd) внутри контейнера при запуске, когда контейнер запускается от имени пользователя без полномочий root (-u NON_ROOT_USER), как того требует хорошая безопасность. Как вы уже знали, специалисты по докерам, вы не можете этого сделать, потому что контейнеры докеров не используют типичный процесс init.d, и поэтому ВСЕ (включая CMD и ENTRYPOINT) запускается от имени указанного пользователя контейнера.
Собственный ответ Бонзая является интересным решением этой проблемы, но следует отметить, что, делая это, вы используете демон nslcd вашего хоста, а не что-либо, запущенное в контейнере. У меня это тоже работало, без запуска nslcd внутри контейнера, а просто путем настройки контейнера, как если бы nslcd был запущен во время init.d. Затем я запускаю контейнер с помощью docker run -u NON_ROOT_USER и «заимствую» демон nslcd у хоста.
Я ни в коем случае не эксперт в этом вопросе, поэтому комментарии ниже по этому поводу приветствуются ...