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:




    1. Have the ability to create / modify / delete user accounts centrally, and not on each individual server
    2. Centralized smelted for sudo
    3. 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:

    1. 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
      

    2. 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
      

    3. 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
      

    4. 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:
    1. Created a directory for configs:
      $ sudo mkdir -p /opt/dockers/dnsmasq.d
      

    2. 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
      

    3. 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/'
      

    4. 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.ymland run:
    $ docker-compose up -d
    

    C server is finally done.

    Customer setup


    Here I have a solution in 3 teams :)

    1. 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
      

    2. Configure DNS (via /etc/network/interfacesor /etc/resolvconf/resolv.conf.d/head) so that the /etc/resolv.conffollowing lines appear:
      nameserver 10.12.0.172
      search example.test
      

    3. 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).

    Also popular now: