System of centralized management of user authorization on FreeIPA in Docker
In the wake of Docker's popularity on Habré, after participating in some discussions in the comments regarding Docker, and due to the recent need to configure centralized authorization for a cluster of Linux machines, I decided to write a short note. A bright, in my opinion, example of Docker’s application for a small private task will be shown here.
This is, by the way, the FreeIPA WebUI ( official demo ) (clickable):
')
What tasks I wanted to solve with the help of FreeIPA:
Yes, most likely FreeIPA in our case is a gun shot on sparrows, but on the other hand, there is no alternative to something. I considered the following options: NIS (I think he should have gone on holiday for a long time), OpenLDAP + ... + ... (not very friendly, and FreeIPA has LDAP as a result, only we don’t have to deal with it directly) here the list ends, I have not found anything else.
So let's get started!
The list of technologies used:
FreeIPA, due to the fact that it is a product of RedHat, is naturally able to unfold well on CentOS and Fedora and practically doesn’t unfold on other distributions. (Note. I didn’t really set a goal, so there may be instructions somewhere, but there are no servers in Debian / Ubuntu for FreeIPA, but there is a client package
This fact never upset me, but, on the contrary, inspired me! This is also 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, pile everything up and run, BUT even the more pleasant news for me was the official Docker freeipa-server image (they 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 modeled and quickly started from the beginning to debug the process from scratch).
In general, the launch of 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 set up on its own (magic, which is almost impossible to repeat on other DNS). For FreeIPA clients, it is expected that they will have access to this DNS, which still somehow cleverly failover to handle, only in the case of how it is here - all in one Docker image, I don’t really see the benefits of such a failover. However, I didn’t go overboard 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 absolutely did not want to get into the bind inside the FreeIPA container. Therefore, I decided to use a proven solution - Dnsmasq. The Docker Hub has a minimalistic image of Dnsmasq, 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, doesn’t interact with the bind DNS server at all.
Further I connected these two services in one
You may notice a little magic with an additional option to the dnsmasq command; this option will redirect requests to * .example.test to the bind DNS installed in the freeipa container.
The convenience of Docker Compose in this particular case is that its config is still easier to read than a bash script with a
C server is finally finished.
Here I have a solution in 3 teams :)
That's all, now you can do su / sudo / ssh on this host, where the user will be forced to change the password during the very first login, and when you first log in on the new host, the user will automatically create a home directory from
Docker can simplify the deployment of complex projects in any infrastructure. Docker has many uses and this is just one of them.
In the future, I may be willing to write about another project that intensively uses resource limits integrated in Docker (CPU, RAM).
This is, by the way, the FreeIPA WebUI ( official demo ) (clickable):
')
What tasks I wanted to solve with the help of FreeIPA:
- Have the ability to create / change / delete user accounts centrally, rather than on each individual server
- Centralized melting for sudo
- Later we will connect VPN authentication to this system, and then maybe other internal office services.
Yes, most likely FreeIPA in our case is a gun shot on sparrows, but on the other hand, there is no alternative to something. I considered the following options: NIS (I think he should have gone on holiday for a long time), OpenLDAP + ... + ... (not very friendly, and FreeIPA has LDAP as a result, only we don’t have to deal with it directly) here the list ends, I have not found anything else.
So let's get started!
Server Tuning
The list of technologies used:
- FreeIPA is an open source RedHat project that 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 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 the bind that is used in FreeIPA).
- Docker is an open-source platform that automates the deployment of applications into lightweight, portable, self-contained containers that can be transferred between servers without changes. © Use Docker and don't worry about vendor-lock
FreeIPA, due to the fact that it is a product of RedHat, is naturally able to unfold well on CentOS and Fedora and practically doesn’t unfold on other distributions. (Note. I didn’t really set a goal, so there may be instructions somewhere, but there are no servers in Debian / Ubuntu for FreeIPA, but there is a client package
freeipa-client , but more on that later.)This fact never upset me, but, on the contrary, inspired me! This is also 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, pile everything up and run, BUT even the more pleasant news for me was the official Docker freeipa-server image (they 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 modeled and quickly started from the beginning to debug the process from scratch).
In general, the launch of freeipa-server did not cause any problems, everything is in accordance with the documentation for the Docker image:
- Create a directory that will be mounted into the FreeIPA configuration file, which must be left after the restart (the documentation suggests using
/var/lib/ipa-data/, but I don’t like to clutter up the system, therefore/opt/):$ sudo mkdir -p /opt/dockers/freeipa-data - Add a file with options that will be used during the installation of freeipa-server:
$ sudo tee /opt/dockers/freeipa-data/ipa-server-install-options --ds-password=The-directory-server-password --admin-password=The-admin-password - Everything, we are launching (in the dock there is not enough port forwarding, although it is obvious what needs to be done; it is also worth noting that the dock says that you need to connect a partition with a postfix
:Z:rw, but if you do not have SELinux, you need this option not needed (thanks to 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 with
bash- this is where the installation and configuration of FreeIPA Server is complete. You can add freeipa.example.test to yourself in / etc / hosts, go to https: //freeipa.example.test/ , login as admin and create a user.
FreeIPA in its image raised a whole zoo of services, including bind (DNS), which it set up on its own (magic, which is almost impossible to repeat on other DNS). For FreeIPA clients, it is expected that they will have access to this DNS, which still somehow cleverly failover to handle, only in the case of how it is here - all in one Docker image, I don’t really see the benefits of such a failover. However, I didn’t go overboard 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 absolutely did not want to get into the bind inside the FreeIPA container. Therefore, I decided to use a proven solution - Dnsmasq. The Docker Hub has a minimalistic image of Dnsmasq, based on Alpine Linux - 6MB.
Here is how I prepared it:
- Created a directory for configs:
$ sudo mkdir -p /opt/dockers/dnsmasq.d - I 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, the folder with configs):
$ 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/' - Checking 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, doesn’t interact with the bind DNS server at all.
Further I connected these two services in 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 may notice a little magic with an additional option to the dnsmasq command; this option will redirect requests to * .example.test to the bind DNS installed in the freeipa container.
The convenience of Docker Compose in this particular case is that its config is still easier to read than a bash script with a
docker run . And it's better to do it right away. Save docker-compose.yml and run: $ docker-compose up -d C server is finally finished.
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/interfacesor/etc/resolvconf/resolv.conf.d/head) so that the following lines appear in/etc/resolv.conf:nameserver 10.12.0.172 search example.test - And now, by changing the admin password to FreeIPA in the following command, you can run it:
$ sudo bash -c 'bash -c "cat > /usr/share/pam-configs/mkhomedir <<EOF Name: activate mkhomedir Default: yes Priority: 900 Session-Type: Additional Session: required pam_mkhomedir.so umask=0022 skel=/etc/skel EOF" && DEBIAN_FRONTEND=noninteractive apt-get install -y freeipa-client && ipa-client-install -U -N -p admin -w The-admin-password && sed -i "s/services = .*/services = nss, pam, ssh, sudo/" /etc/sssd/sssd.conf && restart sssd && restart ssh'
Here you will add a PAM module to automatically create home directories, install freeipa-client, launch the ipa-client installation, add sudo service to sssd.conf, and reload sssd and ssh.
That's all, now you can do su / sudo / ssh on this host, where the user will be forced to change the password during the very first login, and when you first log in on the new host, the user will automatically create a home directory from
/etc/skel .findings
Docker can simplify the deployment of complex projects in any infrastructure. Docker has many uses and this is just one of them.
In the future, I may be willing to write about another project that intensively uses resource limits integrated in Docker (CPU, RAM).
Source: https://habr.com/ru/post/254233/
All Articles