ИНФРАСКОПИЯ
ИНФРАСКОПИЯ
Telegram

Keycloak: запуск, БД, URL и доступ (п.5–10)

ИНФРАСКОПИЯ

Мы разбираем инфраструктуру по фактам: Linux, Zabbix, мониторинг, диагностика и архитектура. От симптома — к проверяемому выводу: что именно доказывает метрика, какие гипотезы остаются и как подтвердить решение. Без догадок там, где можно проверить. Если нужно понимать не только что сделать, но и почему — вам сюда.

Открыть в TelegramДругие публикации
Keycloakбаза данныхsecrets

Лучше создать отдельного системного пользователя:

keycloak

и запускать сервис от него.

Логика обычная:

root
  ↓
устанавливает / настраивает систему

keycloak
  ↓
запускает только Keycloak

У пользователя должны быть только необходимые права:

  • читать приложение;
  • читать требуемую конфигурацию;
  • обращаться к сертификатам, если TLS завершается на Keycloak;
  • читать secrets, которые действительно нужны;
  • писать только туда, где это предусмотрено эксплуатационной схемой.

То есть:

service account
        ≠
обычный административный пользователь

6. База данных — одно из главных решений

Для production Keycloak нужен нормальный внешний relational database.

Например:

Keycloak
   ↓
PostgreSQL

или другая поддерживаемая СУБД.

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

db=postgres
db-url-host=db01.example.net
db-username=keycloak

Но важнее не сами три параметра.

Нужно заранее решить:

  • где находится база;
  • кто ею управляет;
  • как создаётся database/user;
  • как ограничен сетевой доступ;
  • используется ли TLS;
  • как выполняется backup;
  • какие требования к доступности;
  • что произойдёт при недоступности DB.

Потому что:

Keycloak работает
        ≠
Keycloak независим от database

Фактически база является одним из ключевых компонентов всей IAM-системы.

7. Пароль от базы не должен случайно стать частью обычной конфигурации

Самый простой вариант:

db-password=SuperSecretPassword

технически работает.

Но сразу возникает вопрос:

кто может прочитать этот файл?

Keycloak умеет получать конфигурацию из нескольких источников:

CLI
environment
keycloak.conf
Java KeyStore

Для чувствительных значений стоит заранее выбрать подходящий механизм хранения secrets.

Например:

database password
SMTP password
client secrets
keystore passwords

не должны бесконтрольно расползаться по:

shell history
systemd unit
world-readable config
deployment scripts

8. Главный вопрос — какой URL будет у Keycloak

Представим:

https://sso.example.ru

Это не просто удобная DNS-запись.

Keycloak использует собственный URL в:

  • OIDC discovery;
  • issuer;
  • redirect flows;
  • action links;
  • письмах;
  • административном интерфейсе.

Поэтому hostname должен быть спроектирован заранее.

Например:

hostname=https://sso.example.ru

Здесь особенно опасна логика:

сейчас запустим на IP, потом поменяем URL.

Потому что клиенты IAM сильно завязаны на корректность URL и issuer.

URL Keycloak
    ≠
косметическая настройка

9. DNS должен соответствовать реальной архитектуре

Если пользователи обращаются к:

sso.example.ru

нужно понимать, куда разрешается это имя.

Например:

sso.example.ru
        ↓
reverse proxy
        ↓
keycloak01

а не обязательно:

sso.example.ru
        ↓
keycloak01

Это принципиально.

DNS должен отражать точку входа пользователей, а не просто IP сервера, на котором находится Java-процесс.

10. Admin Console можно отделить от пользовательского доступа

Это очень полезное архитектурное решение.

Например:

пользователи:
https://sso.example.ru

администраторы:
https://sso-admin.example.ru

Тогда:

sso.example.ru
       ↓
Internet / corporate users

sso-admin.example.ru
       ↓
VPN / management network

Keycloak позволяет задавать отдельный административный hostname.

Но одного параметра недостаточно.

Ограничение доступа необходимо обеспечивать и на уровне:

reverse proxy
firewall
network ACL

Смысл:

публичному пользователю нужны endpoints аутентификации, но ему совершенно не обязательно иметь сетевой доступ к Admin Console.

Читайте так же