Cliente OpenLDAP dentro de um contêiner docker

Question

Eu tenho um contêiner docker rodando o CentOS 6 com um usuário não-root e OpenLDAP. Quando eu uso getent passwd , ele apenas retorna os dados de /etc/passwd . O arquivo de configuração /etc/nsswitch.conf é personalizado de acordo (veja abaixo) e authconfig-gtk é usado para configuração. Curiosamente, eu sou capaz de buscar todas as informações do usuário com

ldapsearch -x -b "dc=physik,dc=rwth-aachen,dc=de"

mas não está acessível ou não é usado dentro do contêiner docker. Eu confiei ou perdi alguma coisa?

Pacotes instalados:

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

    

Answer 1

Com nslcd -d , vi que o endereço já foi usado pelo sistema host. Eu consertei isso montando o soquete ao executar docker run com

-v /var/run/nslcd/socket:/var/run/nslcd/socket

    

Answer 2

Eu passei a maior parte desta tarde tentando executar um serviço que parece exigir raiz (nslcd) dentro de um contêiner na inicialização enquanto o contêiner é executado como um usuário não-root (-u NON_ROOT_USER), conforme dita a boa segurança. Como os especialistas em docker já sabiam, você não pode fazer isso porque os contêineres do docker não usam o processo init.d típico e, portanto, TUDO (incluindo CMD e ENTRYPOINT) é executado como o usuário do contêiner especificado.

A resposta do próprio Bonzai é uma solução interessante para esse problema, mas deve-se notar que, ao fazer isso, você está usando o daemon nslcd do seu host e não qualquer coisa iniciada dentro do contêiner. Eu tenho isso para trabalhar para mim também, sem iniciar o nslcd dentro do contêiner, mas simplesmente configurando o contêiner como se o nslcd tivesse sido iniciado durante o init.d. Em seguida, executo o contêiner usando o docker run -u NON_ROOT_USER e "peço emprestado" o daemon nslcd do host.

Eu não sou de forma alguma um especialista nisso, então comentários abaixo sobre esta discussão são bem-vindos ...