Есть в жизни инфраструктурщика несколько стадий взросления.

  1. Сначала ты создаешь пользователей руками на каждом сервере.
  2. Потом понимаешь, что количество серверов растет и начинаешь писать скрипты на bash
  3. Позже растешь и начинаешь писать роли на Ansible и Terraform.
  4. Бам и у тебя 400 серверов, 120 разработчиков, 20 “временных подрядчиков”, которые работают уже третий год, и один одинаковый ssh ключ на всех стендах (бывает и хуже - одинаковый пароль вида qwe123).

И вот в этот момент появляется мысль:

“А может хватит этого цифрового колхоза? Ломанут ведь...”

Осознав все свою не правоту, начинаешь искать варианты и тут на сцену выходит FreeIPA.

Не как “еще одна модная LDAP-штука”, а как нормальная система управления идентификацией, политиками, сертификатами, sudo, DNS, Kerberos и всем тем, что обычно размазано по двадцати txt-файлам, конфлюэнсу,  памяти одного уставшего DevOps-инженера и немного странного безопастника с дергающимся глазом (если он вообще есть - безопастник, не глаз).

Что вообще такое FreeIPA

FreeIPA - это централизованная система управления:

  • пользователями
  • группами
  • SSH-доступами
  • sudo-политиками
  • DNS
  • сертификатами
  • Kerberos-аутентификацией
  • хостами
  • политиками безопасности

Проще говоря, FreeIPA - это попытка мира Linux сказать:

“Слушайте… А давайте тоже сделаем Active Directory. Но без боли и страданий. Ну… Почти.”

Из чего состоит FreeIPA

Внутри FreeIPA живет целый зоопарк:

Компонент Для чего
LDAP (389 Directory Server) хранение пользователей
Kerberos аутентификация
Dogtag PKI сертификаты
DNS централизованный DNS
SSSD авторизация клиентов
NTP/chrony синхронизация времени
Web UI чтобы безопасники тоже чувствовали себя полезными

И да. Если время между сервером и клиентом отличается больше чем на несколько минут - Kerberos просто скажет:

“Давай! Досвидания!” (с) Мем из 2010-ых

И все перестанет работать. Потому что Kerberos живет по принципу:

“Время - это не рекомендация. Это закон!”

Что FreeIPA реально улучшает в безопасности

Вот где начинается самое интересное.

1. Централизованный контроль пользователей

Больше не надо:

  • создавать пользователей руками
  • удалять их на 400 серверах
  • вспоминать где еще у человека остался доступ после увольнения

Теперь:

ipa user-add ivanov
И пользователь появляется везде.

Удалить - так же просто:

ipa user-disable ivanov
И доступ исчезает везде.

Магия? Нет. Наконец-то нормальная инфраструктура и попытка сделать свою работу безопаснее.

2. Kerberos вместо SSH-ключевого ада

Обычно инфраструктура выглядит так:

authorized_keys
authorized_keys_old
authorized_keys_final
authorized_keys_final2
authorized_keys_use_this_one
FreeIPA позволяет:
  • централизованно хранить SSH-ключи
  • автоматически прокидывать их на хосты
  • использовать Kerberos ticket authentication

То есть:

kinit username
ssh server01
И ты входишь без пароля.

Красиво. Кайфово. Безопасно. Пока не истек ticket в ночи во время релиза.

3. Sudo-политики

Вместо:

vim /etc/sudoers
На каждом сервере.

Можно:

ipa sudorule-add devops-admins

И централизованно управлять sudo.

Например:

  • девопсы - полный sudo
  • разработчики - только restart сервиса
  • аналитики - вообще ничего, но они все равно как-то получают root доступ (но тут надо уже бить по рукам разрабам)

4. Сертификаты

FreeIPA умеет быть CA - центром сертификации (но лучше делать такой через Hashicorp Vault - я это опишу в будущем, правда-правда. Уже даже черновик статьи написал. Чуть позже опубликую.).

То есть можно выпускать сертификаты для:

  • серверов
  • сервисов
  • внутренних API
  • PostgreSQL mTLS
  • Kubernetes ingress
  • VPN

И это уже огромный шаг к нормальной security-модели и повышению культуры безопасности.

Архитектура FreeIPA

Минимальная схема

                +----------------+
                |  FreeIPA       |
                |  Server        |
                +--------+-------+
                         |
         +---------------+--------------+
         |               |              |
    client01        client02       client03

Нормальная production-схема

        +-------------------+
        | FreeIPA Replica 1 |
        +---------+---------+
                  |
        +---------+---------+
        | FreeIPA Replica 2 |
        +---------+---------+
                  |
        +---------+---------+
        | FreeIPA Replica 3 |
        +-------------------+
Потому что один FreeIPA-сервер - это не “high availability”. Это “надеюсь не упадет”. Падали - знаем. Очень не приятно.

Системные требования

Для тестов хватит:

  • 2 CPU
  • 4 GB RAM
  • 20 GB disk

Для production:

Смотря сколько у тебя пользователей, хостов и насколько сильно разработчики смотреть логи в живую на серверах. У нас же пока нет ни ELK, ни Loki...

Очень важный момент - DNS

Вот сейчас внимание.

FreeIPA БЕЗ НОРМАЛЬНОГО DNS - это страдание, боль, унижение и слезы инфраструктурщиков.

Серьезно.

99% проблем:

  • Kerberos не работает
  • replica не добавляется
  • client enrollment падает
  • сертификаты ломаются
  • web ui отваливается

Сводятся к:

“DNS был настроен как попало. Потому что надо было срочно!”

Подготовка сервера

Допустим:

Hostname: ipa01.company.local
IP: 10.10.10.10
Realm: COMPANY.LOCAL
Domain: company.local

Настройка hostname

hostnamectl set-hostname ipa01.company.local
/etc/hosts
10.10.10.10 ipa01.company.local ipa01

Проверка

hostname -f

Должно вернуть:

ipa01.company.local
Если нет - дальше даже не начинай. Серьезно. Будет очень больно.

Установка FreeIPA

Для Rocky Linux / AlmaLinux / RHEL:

dnf install freeipa-server freeipa-server-dns -y

Для Ubuntu/Debian чуть сложнее:

sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install -y software-properties-common
sudo add-apt-repository ppa:freeipa/ppa
sudo apt-get update
sudo apt-get install -y freeipa-server freeipa-server-dns

Запуск установки

ipa-server-install
И дальше мастер задаст вопросы.

Важные параметры

Realm

COMPANY.LOCAL
Realm всегда БОЛЬШИМИ БУКВАМИ. (почему выделил - были некоторые страдашки на этот счет у меня самого)

Kerberos очень любит CAPS LOCK.

Такое ощущение - что он просто любит ОРАТЬ НА ТЕБЯ!

Domain

company.local

Directory Manager password

Это LDAP superadmin.

НЕ путать с admin FreeIPA.

И НЕ терять.

И НЕ хранить в:

password.txt
На рабочем столе. (Привет Вася. Прости, но вспомнилось... Без негатива...)

IPA admin password

Основной администратор FreeIPA.

После установки

Проверяем:

kinit admin
klist
Если видишь ticket - уже хорошо.

Web UI

Открываем:

https://ipa01.company.local
И видим:
  • users
  • hosts
  • policies
  • dns
  • certificates

И внезапно инфраструктура начинает выглядеть как enterprise. Даже если сервер стоит под столом.

Подключение Linux-клиента/серверов

Установка

Для RHEL подобныъ систем

dnf install freeipa-client -y

Для любимой Ubuntu:

sudo apt install freeipa-client -y

Подключение

ipa-client-install \
  --mkhomedir \
  --enable-dns-updates

Проверка

id admin
Если видишь пользователя - отлично.

Автоматическое создание home directory

Очень важная штука. Иначе пользователь войдет и окажется в пустоте, где грустно и одиноко.

Параметр:

--mkhomedir
обязателен почти всегда.

Настройка SSH через FreeIPA

Генерация ключа

ssh-keygen

Добавление ключа

ipa user-mod admin \
  --sshpubkey="$(cat ~/.ssh/id_rsa.pub)"
Теперь ключ автоматически появится на клиентах и серверах.

Sudo policies

Создаем группу

ipa group-add devops

Добавляем пользователя

ipa group-add-member devops \
  --users=ivanov

Создаем sudo rule

ipa sudorule-add devops-root

Разрешаем sudo

ipa sudorule-add-user devops-root \
  --groups=devops

Разрешаем все команды

ipa sudorule-add-allow-command devops-root \
  --sudocmds=ALL

HBAC - Host Based Access Control

До этого мы говорили только про sudo и создание ключей. Но вот этот уровень - уже взрослая безопасность.

Можно ограничивать:

  • кто
  • куда
  • с какого хоста
  • может логиниться

Например:

  • Разработчики могут заходить только на staging.
  • А production - только у DevOps.
  • Аналитикам мы все еще запрещаем куда-то заходить...

И вот тут начинается резкое снижение “случайных” деплоев в прод или "да я сейчас это быстренько поправлю...".

Репликация

Добавление replica:

ipa-replica-install
Но тут начинается веселье.

Потому что:

  • DNS
  • firewall
  • time sync
  • certificates
  • reverse zones

Все должно быть идеально.

Kerberos не любит “быстренько настроим и так сойдет”.

Firewall

Минимум:

firewall-cmd --add-service=freeipa-ldap --permanent
firewall-cmd --add-service=freeipa-ldaps --permanent
firewall-cmd --add-service=dns --permanent
firewall-cmd --add-service=http --permanent
firewall-cmd --add-service=https --permanent

Время - это святое

Повторю еще раз. Если chrony/NTP работает плохо - FreeIPA превратится в генератор депрессии.

Настраиваем chrony:

dnf install chrony -y
systemctl enable --now chronyd

И для Ubuntu:

sudo apt install chrony -y
sudo systemctl enable chronyd
sudo systemctl start chronyd

Интеграция с Kubernetes

А вот тут начинается нормальная работа.

Можно:

  • выдавать сертификаты
  • использовать LDAP auth
  • делать mTLS
  • подключать Rancher
  • интегрировать ArgoCD
  • использовать SSO
  • делать сборки в Jenkins безопаснее

Например через Dex + LDAP. И внезапно Kubernetes перестает быть “cluster-admin для всех”.

Интеграция с PostgreSQL

Можно делать:

  • LDAP auth
  • Kerberos auth
  • mTLS auth

Пример pg_hba.conf:

hostssl all all 10.0.0.0/8 cert clientcert=verify-full
И вот уже базы начинают выглядеть как инфраструктура банка (в финтехе очень любят mTLS и не зря), а не стартапа на энергетиках.

Плюсы FreeIPA

Централизация

Самый большой плюс.

Kerberos

Очень мощная штука.

LDAP + DNS + PKI в одном месте

Удобно. Очень. Нет, даже сказал бы - оооочень удобно!

Бесплатно

Особенно приятно после цен на enterprise IAM-решения.

Минусы FreeIPA

Kerberos

Одновременно плюс и минус. Пока работает - прекрасно.

Когда ломается:

Server not found in Kerberos database
И ты следующие 4 часа смотришь:
  • DNS
  • SPN
  • realm
  • time sync
  • reverse lookup

Очень чувствителен к DNS

Я не шучу. С этим нужно быть прям очень осторожным!

Replica setup иногда больнее чем миграция PostgreSQL на две версии выше

Особенно через NAT/VPN.

Не Active Directory

Хотя многие пытаются использовать как “AD replacement”. Ну ребят, ну правда. Ну давайте я лучше позже расскажу как подружить FreeIPA с Keycloak.

Частые ошибки

Reverse DNS

Должен быть. ВСЕГДА.

Время

Синхронизация обязательна.

Неправильный hostname

Очень популярная боль.

localhost в resolv.conf

Поздравляю! Ты только что создал себе квест на несколько часов!

Резервное копирование

Backup

ipa-backup

Restore

ipa-restore
Но restore FreeIPA - это всегда:
  • чуть-чуть магия
  • чуть-чуть молитва
  • чуть-чуть “а почему replica теперь ненавидит master” и что теперь делать?!

Поэтому backup проверяем заранее. А еще лучше - проводим учения по восстановлению.

Когда стоит ли внедрять FreeIPA?

Если у тебя:

  • больше 20 серверов
  • больше 10 пользователей
  • есть compliance
  • нужен аудит
  • нужна централизованная аутентификация
  • нужна нормальная база для построения безопасности в дальнейшем

То ответ:

Да. Однозначно.

Когда НЕ стоит

Если у тебя:

  • 3 VPS
  • pet project
  • один разработчик
  • SSH по root
  • пароль “qwerty123”

То FreeIPA будет выглядеть как:

“Я купил авианосец чтобы ездить в магазин в соседнее село и катать девчонок.”

Финальные мысли

FreeIPA - это не просто LDAP.

Это момент, когда инфраструктура перестает быть:

  • набором серверов
  • коллекцией SSH-ключей
  • файлом final_final_users_v12.xlsx

И начинает становиться системой и первым кирпичиком для построения нормального инфобеза.

Да, будут:

  • Kerberos-ошибки
  • DNS-боль
  • странные SPN
  • replica synchronization issues

Но зато потом:

  • централизованная безопасность
  • аудит
  • SSO
  • политики
  • сертификаты
  • нормальное управление доступом

И самое приятное: Когда сотрудник увольняется - ты удаляешь ОДНОГО пользователя. А не открываешь файл servers.txt и начинаешь "ходить по серверам" и его отключать.

В следующий раз, как и обещал ранее, попробую рассказать про объединение FreeIPA + KeyCloak. Там мы чуть-чуть попишем код и вообще узнаем, что такое SSO...