Binding NSCD, SSSD sockets inside container

[Jérôme Petazzoni]

On Tue, Sep 24, 2013 at 2:09 AM, Alexander Larsson <alexande...@gmail.com> wrote:

[...] i've been thinking of how to move some other configuration from the container to the daemon. It wold be very cool if Docker could automatically detect NSCD (and maybe SSSD) sockets and (optionally) bind them into the container. Then a container could just be configured to proxy to these, therefor moving a lot of setup to the host. It would also allow e.g. name lookup caches to be cross-container.

Is it enough to bind-mount a UNIX socket?

Or does it require any kind of special extra configuration?

Also, what's the behavior of a NSCD- or SSSD-enabled distro when those sockets are not present?

(The question hidden behind the last one is: "Should a container be specifically configured to use those sockets, or will the resolver automagically check for the sockets and fall back on files?")

If there is a comprehensive doc about that stuff, feel free to point me to it, btw.

--

@jpetazzo

Latest blog post: http://blog.docker.io/2013/09/docker-joyent-openvpn-bliss/

[Alexander Larsson]

On Tuesday, 24 September 2013 18:07:58 UTC+2, Jérôme Petazzoni wrote:

On Tue, Sep 24, 2013 at 2:09 AM, Alexander Larsson <alexande...@gmail.com> wrote:

[...] i've been thinking of how to move some other configuration from the container to the daemon. It wold be very cool if Docker could automatically detect NSCD (and maybe SSSD) sockets and (optionally) bind them into the container. Then a container could just be configured to proxy to these, therefor moving a lot of setup to the host. It would also allow e.g. name lookup caches to be cross-container.

Is it enough to bind-mount a UNIX socket?

Or does it require any kind of special extra configuration?

Also, what's the behavior of a NSCD- or SSSD-enabled distro when those sockets are not present?

(The question hidden behind the last one is: "Should a container be specifically configured to use those sockets, or will the resolver automagically check for the sockets and fall back on files?")

nscd client support is part of glibc, if the /var/run/nscd/socket is there and connection to it succeeds it will be automatically used.

For instance:

$ sudo docker run -i -t -v /var/run/nscd:/var/run/nscd mattdm/fedora:f19 /bin/bash
bash-4.2# groups alex
alex : wheel

VS:

$ sudo docker run -i -t  mattdm/fedora:f19 /bin/bashbash-4.2# groups alex
groups: alex: no such user

See how it picked up the host groups file when the socket was there. It has lookups for a bunch of stuff:
       Nscd  provides  caching for accesses of the passwd(5), group(5), and hosts(5) databases through
       standard libc interfaces, such as getpwnam(3), getpwuid(3), getgrnam(3), getgrgid(3),  gethost‐
       byname(3), and others.

So, no configuration is needed to the guest, and the fallback is automatic (if nscd connection fails it falls back to the standard nsswitch.conf setup). However, forwarding nscd does allow the container access to some information that may belong to the host (e.g. ldap data, etc), so its not always something you want to use. Thus, it needs some level of configuration from the docker side.

SSSD is somewhat similar, but it has its own nss and pam modules that you have to install and configure in the container. It has sockets in /var/lib/sss, but I don't know the exact behaviour of these. I believe it depends on how you configure nss/pam whether and how it falls back.

 

If there is a comprehensive doc about that stuff, feel free to point me to it, btw.

 
Nscd is a basic component of glibc, just look at "man nscd".

For SSSD there are some docs at e.g:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Introduction.html

[Dmitri Pal]

On Tuesday, September 24, 2013 12:07:58 PM UTC-4, Jérôme Petazzoni wrote:

On Tue, Sep 24, 2013 at 2:09 AM, Alexander Larsson <alexande...@gmail.com> wrote:

[...] i've been thinking of how to move some other configuration from the container to the daemon. It wold be very cool if Docker could automatically detect NSCD (and maybe SSSD) sockets and (optionally) bind them into the container. Then a container could just be configured to proxy to these, therefor moving a lot of setup to the host. It would also allow e.g. name lookup caches to be cross-container.

Hello,

First of all please do not use NSCD with the maps that are served by SSSD theya re sort of mutually exclusive. SSSD does caching and if you use it NSCD is not needed and should be turned off. The only exception is the maps that are not handled by SSSD. However those are rarely used and so far we have not heard any clear requests to extend the set of maps supported by SSSD. If there are please file and RFE here:  https://fedorahosted.org/sssd/

Secondarily, I completely agree that SSSD should run in the context of the host and containers would load nss_sss and connect to the main group of processes. That actually works fine with any flavour of container if of cause you have not set SELinux policies to prevent communication over SSSD NSS responder domain socket. So you can try it and I do not see any big issues so far there. If you find any please report them on SSSD mailing list or in trac.

However there is a challenge moving forward that I do not see a good solution for.
SSSD can connect to different identity sources. So let us say that we have a container based solution that is presented by a service provider and there are different businesses that have their own directories. With per host setup of SSSD the SSSD would need to have access to multiple sources and this is fine, SSSD can do it. What is not fine is that SSSD can't associate containers with sources. What needs to happen is the following:

1) A process from container connects to SSSD over the using socket via nss_sss (happens now)
2) SSSD NSS responder accepts connection (happens now)
3) SSSD NSS responder asks socket for the UUID of the container where the connection is coming from
4) SSSD NSS responder asks something (and I do not know what it would be) what is the mapping of this UUID to a Tenant that this container belongs to.
5) Then SSSD NSS responder can map the Tenant to the identity sources available and would serve the right information.

Now to be clear I am not a specialist in containers so please take the following with a grain of salt.
IMO what we need for containers is: identity (and I was told that the containers already have unique identity so that might be a solved problem), properties (tags) that can be associated with the container when it is created (this is how tenant data can be passed in because management software probably knows this information), API to query these properties based on the UUID, ability to ask for container UUID on the socket. IMO some part of this should be done by Kernel becuase it is the only trusted intermediary between the container and SSSD. SSSD can trust kernel but can't trust the application itself so the properties should be on the container level.

HTH

Thanks
Dmitri

[Morgan Jones]

Hi Alaxander,

I'm fairly new to containers and i'm trying to setup ldap authentication within my container. I have jupyterhub instance containerised in centos7. The jupyterhub instance authenticates with pam by default, and I'd rather not change this, as the users need access to an nfs mount (so UID, GID etc. need to match).

This nscd socket idea is great. But i'm having a bit of trouble. I can getent passwd <user_on_host>, that works. groups works also, as well as su <user_on_host>. However the nscd socket provides no authentication. Is it possible for this socket to do that from within the container? or am i barking up the wrong tree...

At the moment i'm looking at running an SSSD service in the container as well as the jupyterhub service. I'm aware that this isn't desirable, but i've got nowhere else to go really...

Any help would be really appreciated :)

Cheers,

Morgan