Клиент OpenLDAP внутри контейнера докеров
У меня есть докер-контейнер под управлением 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 у хоста.
Я ни в коем случае не эксперт в этом, поэтому комментарии ниже по этому обсуждению приветствуются ...