Has anyone been able to successfully get FreeIPA to work inside an LXC container? Currently the only way we’ve gotten it to work is setting the container to privileged mode which isn’t ideal.
Not a solution, but I have a Samba AD DC running in an LXD container. I could not start the samba-ad-dc service while the container was unprivileged. As soon as I switched to using a privileged container, everything worked perfectly. I asked about the initial failure on the Samba list without even mentioning that the container was unprivileged (at the time, I didn’t know this was an issue), and several people immediately responded “the LXD container must be privileged” . That would suggest this is a well known issue.
While it’s nice to have a clean security separation, when we’re talking about a container running directory services, which will afford very limited access to only trusted admins, it doesn’t seem like that much of a security issue to me. Containers affording ordinary user access are a different matter of course.
Whats the underlying issue?
Whats your container OS image?
In my experience to get freeipa server to work in a un privileged container you need to add --no-ntp flag to the install with needing to then run sed -i '2s#^#d /run/lock/dirsrv/ 0770 dirsrv dirsrv -\n#' /etc/tmpfiles.d/dirsrv-${ YOUR DIRECTORY REALM }.conf. The tmpfile’s need altering otherwise the ipa server wont start on the next startup of the container because the start up procedure wont have permissions to do something ( i dont remember what )
Centos8 is the base image. The problem with running non-privileged mode is that the when you try to login with IPA it can’t find your group to map it
Not sure what IPA does with your POSIX user within the OS, but it sounds strange to need this unless the IPA needs somehow access to the host UID:s (which itself is strange)…
Is this related to your LDAP setting and home-directories etc?
This is related to LDAP. Basically without privileged mode the errors we see in the IPA log on the container are that it cannot determine user’s LDAP group membership and thus denies their login.
Hmm, what user is used on the container vs the host?
It seems strange to me that the underlying host-users should be needed by IPA?
Inside the container, the UID:s are presented as within their own namespace. Like this below - you can see that inside my lxd-dashboard container, the POSIX user id of ubuntu is 1000.
erik@pixel:~$ lxc shell lxd-dashboard
root@lxd-dashboard:~# id ubuntu
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),117(netdev),118(lxd)
root@lxd-dashboard:~# logout
Whereas it is not even present on my “pixel” instance.
erik@pixel:~$ id ubuntu
id: ‘ubuntu’: no such user
Perhaps you can make IPA behave differently, not asking for a UID which is not present on in the container? I would love to see a IPA work also on ubuntu for that matter…
There is no specific clock for a container. You can have a VM with a different clock than the computer, but not a container. And to set the clock for the host you need a privileged container. It may be possible to hack the system calls to make the caller believe than they succeeded, to turn them in no-ops. But if you can configure the software to not run ntp, it’s vastly simpler. The host can take care of that.
Right, so it seems that perhaps you can explore FreeIPA assign UID:s in a lower range …
or explore LXD be able to use a higher range for UID offsets?
@stgraber might know how to deal with the former…
I’ve not used FreeIPA before though I frequently use sssd with samba4.
In such environments, sssd can be configured to choose a specific range of uid/gid to use inside of the container.
So I frequently only need the container to have access to about 1M uid/gid to have it behave. My containers are usually isolated (security.idmap.isolated=true so I need to set security.idmap.size=1000000 to ensure a large enough map).
You may run into more issues with uid/gid assignment schemes that use a much larger range of IDs as those are unfortunately a shared resource and so it’s not really practical to expose tens of millions of uid/gid to each container nor would it be very practical to have to carve a super specific map through raw.idmap to make individual uid/gid valid.