
System of centralized user authorization management on FreeIPA in Docker
In the wake of the popularity of Docker on Habré, after participating in some discussions in the comments regarding Docker, and in connection with the recent need to configure centralized authorization for a cluster of Linux machines, I decided to write a short note. Here I will show a vivid, in my opinion, example of using Docker for a small private task.
Here, by the way, looks FreeIPA WebUI ( official demo ) (clickable): What tasks I wanted to solve using FreeIPA:


Yes, most likely FreeIPA in our case is a shot with a cannon at sparrows, but on the other hand, something is not visible to the alternatives. I considered such options: NIS (in my opinion, he should go on vacation for a long time), OpenLDAP + ... + ... (not very friendly, and FreeIPA as a result has LDAP under it, but we don’t have to deal with it directly), here the list ends, I did not find anything else.
So let's get started!
The list of technologies used:
FreeIPA, due to the fact that it is a RedHat product, can naturally deploy well on CentOS and Fedora and practically does not deploy on other distributions. (note I didn’t really set a goal, therefore, maybe there are instructions somewhere, but there are no packages in Debian / Ubuntu for FreeIPA server, but there is a client package
This fact has never upset me, but, on the contrary, inspired! This is an ideal task for Docker when on Debian / Ubuntu / Gentoo / etc servers. That is, I could take the basic Fedora image, put the necessary packages there, put everything in a heap and run, BUT the official Docker image of freeipa-server became even more pleasant news for me(they also have a client, but I was interested in the version with the client on Ubuntu, so I ran the ubuntu image in Docker and thus simulated and quickly started from the beginning to debug the process from scratch).
In general, starting freeipa-server did not cause any problems, everything is in accordance with the documentation for the Docker image:
FreeIPA in its image raised a whole zoo of services, including bind (DNS), which it configured as it wanted (magic that is almost impossible to repeat on other DNS). It is expected for FreeIPA clients that they will have access to this DNS, which still knows how to handle failover in a clever way, but in the case like here - all in one Docker image, I do not really see the benefits of such failover. However, I did not go to the argument and took into account the wishes of the FreeIPA developers (by the way, this is a feature of Kerberos, after all, FreeIPA simply combines many packages).
So, what am I talking about DNS? I needed DNS inside the cluster, but I categorically did not want to get into the bind inside the FreeIPA container. Therefore, I decided to use a proven solution - Dnsmasq. There is a Docker Hubminimal Dnsmasq image based on Alpine Linux - 6MB.
Here is how I prepared it:
So we have FreeIPA Server in one container and Dnsmasq in another. By the way, Dnsmasq, as you can see, does not yet interact with FreeIPA's bind DNS server.
Then I connected these two services into one
You can notice a little magic with an additional option to the dnsmasq command, this option will redirect requests to * .example.test to bind DNS installed in the freeipa container.
The convenience of Docker Compose in this particular case is that its config is still more convenient to read than a bash script with
C server is finally done.
Here I have a solution in 3 teams :)
Here, by the way, looks FreeIPA WebUI ( official demo ) (clickable): What tasks I wanted to solve using FreeIPA:


- Have the ability to create / modify / delete user accounts centrally, and not on each individual server
- Centralized smelted for sudo
- Later we will connect VPN authentication to this system, and then other internal office services can
Yes, most likely FreeIPA in our case is a shot with a cannon at sparrows, but on the other hand, something is not visible to the alternatives. I considered such options: NIS (in my opinion, he should go on vacation for a long time), OpenLDAP + ... + ... (not very friendly, and FreeIPA as a result has LDAP under it, but we don’t have to deal with it directly), here the list ends, I did not find anything else.
So let's get started!
Server Tuning
The list of technologies used:
- FreeIPA is an open source project of RedHat, which combines many other open source projects: 389 Directory Server, MIT Kerberos, NTP, DNS (bind), Dogtag certificate system, SSSD and others. At the same time, this solution has a Web UI, CLI, XMLRPC, JSONRPC API and Python SDK.
- Dnsmasq is a lightweight DNS server (later I will explain why I needed it in addition to bind, which is used in FreeIPA).
- Docker is an open-source platform that automates the deployment of applications in lightweight, portable, self-contained containers that can be transferred between servers without any changes. © We use Docker and do not worry about vendor-lock
FreeIPA, due to the fact that it is a RedHat product, can naturally deploy well on CentOS and Fedora and practically does not deploy on other distributions. (note I didn’t really set a goal, therefore, maybe there are instructions somewhere, but there are no packages in Debian / Ubuntu for FreeIPA server, but there is a client package
freeipa-client
, but more on that later.)This fact has never upset me, but, on the contrary, inspired! This is an ideal task for Docker when on Debian / Ubuntu / Gentoo / etc servers. That is, I could take the basic Fedora image, put the necessary packages there, put everything in a heap and run, BUT the official Docker image of freeipa-server became even more pleasant news for me(they also have a client, but I was interested in the version with the client on Ubuntu, so I ran the ubuntu image in Docker and thus simulated and quickly started from the beginning to debug the process from scratch).
In general, starting freeipa-server did not cause any problems, everything is in accordance with the documentation for the Docker image:
- We create a directory that will be mounted in the image for the FreeIPA configs that need to be left after the restart (it is suggested to use in the documentation
/var/lib/ipa-data/
, but I do not like to clog the system, therefore/opt/
):$ sudo mkdir -p /opt/dockers/freeipa-data
- Add a file with options that will be used when installing freeipa-server:
$ sudo tee /opt/dockers/freeipa-data/ipa-server-install-options --ds-password=The-directory-server-password --admin-password=The-admin-password
- We’ll start it (the dock does not have enough port forwarding, although it’s obvious what needs to be done; it’s also worth noting that the dock says that you need to connect the partition with the postfix
:Z:rw
, but if you don’t have SELinux, you do not need this option (thanks grossws )):$ docker run \ --name freeipa-server-test \ -it \ --rm \ --hostname freeipa.example.test \ --volume /opt/dockers/freeipa-data:/data \ --publish "443:443" \ --publish "389:389" \ --publish "636:636" \ --publish "88:88" \ --publish "88:88/udp" \ --publish "464:464" \ --publish "464:464/udp" \ adelton/freeipa-server
- After a short installation, you will be kindly provided
bash
- with this, the installation and configuration of FreeIPA Server has by and large been completed. You can add freeipa.example.test to yourself in / etc / hosts, go to https: //freeipa.example.test/ , log in as admin and create a user.
FreeIPA in its image raised a whole zoo of services, including bind (DNS), which it configured as it wanted (magic that is almost impossible to repeat on other DNS). It is expected for FreeIPA clients that they will have access to this DNS, which still knows how to handle failover in a clever way, but in the case like here - all in one Docker image, I do not really see the benefits of such failover. However, I did not go to the argument and took into account the wishes of the FreeIPA developers (by the way, this is a feature of Kerberos, after all, FreeIPA simply combines many packages).
So, what am I talking about DNS? I needed DNS inside the cluster, but I categorically did not want to get into the bind inside the FreeIPA container. Therefore, I decided to use a proven solution - Dnsmasq. There is a Docker Hubminimal Dnsmasq image based on Alpine Linux - 6MB.
Here is how I prepared it:
- Created a directory for configs:
$ sudo mkdir -p /opt/dockers/dnsmasq.d
- Added dnsmasq config there:
$ sudo tee /opt/dockers/dnsmasq.d/dnsmasq.conf address=/freeipa.example.test/10.12.0.172 address=/server00.example.test/10.12.0.172 address=/server01.example.test/10.12.0.173 address=/server02.example.test/10.12.0.174
- We start (DNS works on 53 / tcp and 53 / udp ports, so we forward them to the config folder):
$ docker run \ --name dnsmasq-test \ --rm \ --publish 53:53 \ --publish 53:53/udp \ --cap-add NET_ADMIN \ --volume /opt/dockers/dnsmasq.d:/etc/dnsmasq.d \ --entrypoint /bin/sh \ andyshinn/dnsmasq \ -c '/usr/sbin/dnsmasq -k -h --conf-dir /etc/dnsmasq.d/'
- Check what works:
$ nslookup server00.example.test 127.0.0.1
So we have FreeIPA Server in one container and Dnsmasq in another. By the way, Dnsmasq, as you can see, does not yet interact with FreeIPA's bind DNS server.
Then I connected these two services into one
docker-compose.yml
:docker-compose.yml
dnsmasq:
image: andyshinn/dnsmasq
ports:
- "53:53"
- "53:53/udp"
cap_add:
- NET_ADMIN
links:
- freeipa
volumes:
- "/opt/dockers/dnsmasq.d:/etc/dnsmasq.d"
entrypoint: ["/bin/sh", "-c", "/usr/sbin/dnsmasq -k -h --conf-dir /etc/dnsmasq.d/ -S /example.test/`getent hosts freeipa | cut -f1 -d' '`"]
freeipa:
image: adelton/freeipa-server
hostname: freeipa.example.test
ports:
- "443:443"
- "389:389"
- "636:636"
- "88:88"
- "88:88/udp"
- "464:464"
- "464:464/udp"
cap_add:
- NET_ADMIN
volumes:
- "/opt/dockers/freeipa-data:/data"
You can notice a little magic with an additional option to the dnsmasq command, this option will redirect requests to * .example.test to bind DNS installed in the freeipa container.
The convenience of Docker Compose in this particular case is that its config is still more convenient to read than a bash script with
docker run
. And it’s better to do well right away. Save docker-compose.yml
and run:$ docker-compose up -d
C server is finally done.
Customer setup
Here I have a solution in 3 teams :)
- You need to fix / etc / hosts so that the first in the list is the fully qualified domain name (FQDN):
127.0.1.1 server00.example.test server00
- Configure DNS (via
/etc/network/interfaces
or/etc/resolvconf/resolv.conf.d/head
) so that the/etc/resolv.conf
following lines appear:nameserver 10.12.0.172 search example.test
- And now changing the admin password for FreeIPA in the following command, you can run it:
$ sudo bash -c 'bash -c "cat > /usr/share/pam-configs/mkhomedir <
Здесь добавится PAM-модуль для автоматического создания домашних директорий, установится freeipa-client, запустится установка ipa-client, добавится сервис sudo в sssd.conf и перегрузятся sssd и ssh.
Вот и всё, теперь на этом хосте можно делать su/sudo/ssh, где пользователя при самом первом входе заставят сменить пароль, а при первом входе на новом хосте для пользователя будет автоматически создана домашняя директория из /etc/skel
.
Выводы
Docker может упростить разворачивание сложных проектов в любой инфраструктуре. У Docker есть масса применений и это только одно из них.
В дальнейшем я, возможно, сподвигнусь написать о другом проекте, который интенсивно использует ограничения ресурсов, интегрированные в Docker (CPU, RAM).