При первом старте Keycloak требуется создать начального администратора.
Для этого могут использоваться:
KC_BOOTSTRAP_ADMIN_USERNAME KC_BOOTSTRAP_ADMIN_PASSWORD
Но это bootstrap-механизм. Не стоит превращать его в постоянную схему управления credentials. После первоначальной настройки нужно определить:
- кто является администраторами;
- используются ли персональные учётные записи;
- включается ли MFA;
- где хранится emergency access;
- кому разрешён доступ к Admin Console.
Особенно плохо:
общий admin + один пароль + пять инженеров
27. План обновления нужен ещё до первой установки
Если Keycloak просто распакован:
/opt/keycloak
а затем каждая новая версия копируется поверх старой, через несколько обновлений легко потерять понимание:
- какие файлы штатные;
- какие были изменены;
- какие providers добавлены;
- какая версия сейчас реально работает.
Удобнее заранее разделять:
software configuration secrets custom providers backup
и использовать версионную схему установки. Тогда upgrade становится управляемой процедурой, а не заменой файлов «на месте».
28. Нужно понимать, что именно резервировать
Keycloak хранит критичное состояние прежде всего в базе данных. Но одной DB может быть недостаточно для полного восстановления инфраструктуры. Нужно отдельно сохранить:
- конфигурацию Keycloak;
- database;
- сертификаты и keys;
- custom providers;
- themes, если используются;
- systemd unit;
- reverse proxy configuration;
- secrets или способ их повторного получения.
Полезный вопрос: если сервер Keycloak полностью исчезнет, что нужно для его воспроизводимого восстановления на чистой ОС? Если ответа нет — backup strategy ещё не закончена.
29. Если в будущем планируется кластер — это стоит учитывать сразу
Одна instance:
users ↓ Keycloak01 ↓ database
может быть достаточной для небольшой системы. Но это очевидная точка отказа. Для высокой доступности архитектура уже другая:
┌── Keycloak01
users → LB ──┤
└── Keycloak02
↓
database
Keycloak использует clustering/caching mechanisms для работы нескольких экземпляров. Не обязательно строить HA с первого дня. Но полезно заранее избежать решений, которые потом сделают добавление второго узла болезненным.
30. Минимальный pre-flight checklist
Перед фактической установкой я бы хотел иметь ответы на эти вопросы:
[ ] выбрана версия Keycloak [ ] проверена совместимая версия JDK [ ] создан отдельный service account [ ] определена структура каталогов [ ] выбрана production database [ ] создана схема backup database [ ] выбран окончательный public hostname [ ] DNS подготовлен [ ] решено, нужен ли отдельный admin hostname [ ] определена точка TLS termination [ ] спроектирован reverse proxy [ ] определён режим proxy headers [ ] определены firewall rules [ ] management port не публикуется наружу [ ] спроектировано хранение secrets [ ] включение health/metrics запланировано [ ] определён способ systemd startup [ ] синхронизация времени проверена [ ] проверены LDAP / SMTP / external IdP dependencies [ ] понятен процесс обновления [ ] понятен процесс восстановления
Если большая часть этих решений ещё неизвестна, распаковка Keycloak мало что даст.
31. И только теперь установка
После подготовки процесс становится значительно понятнее:
JDK ↓ Keycloak distribution ↓ configuration ↓ build ↓ systemd ↓ reverse proxy ↓ validation
То есть установка перестаётся быть: «запустим и посмотрим». Она становится реализацией заранее выбранной архитектуры.