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

Alauda Build of Keycloak использует cloud-native архитектуру Keycloak для предоставления проверенного решения для управления идентификацией и доступом с высокой доступностью, отвечающего enterprise-требованиям к безопасным, надежным и эластично масштабируемым сервисам аутентификации и авторизации.

#Общая архитектура

Alauda Build of Keycloak развертывается и управляется через Kubernetes Operator. Operator отслеживает Custom Resources Keycloak и KeycloakRealmImport и приводит желаемое состояние к текущему состоянию в cluster. Основные компоненты:

• Keycloak Operator: Controller, который управляет жизненным циклом экземпляров Keycloak и импортом Realm.

• Keycloak Server: Провайдер идентификации и сервер авторизации, работающий как Kubernetes Deployment.

• Database: Постоянная реляционная database (рекомендуется PostgreSQL), в которой хранятся все данные Realm, пользователей, clients и сессий.

• Ingress / Service: Предоставляет доступ к Keycloak Server внутренним cluster services или внешним clients через Kubernetes Ingress.

  ┌─────────────────────────────────────────────────────────┐
  │                    Kubernetes Cluster                   │
  │                                                         │
  │   ┌──────────────────┐     ┌────────────────────────┐   │
  │   │ Keycloak Operator│────▶│   Keycloak CR          │   │
  │   │  (Controller)    │     │   KeycloakRealmImport  │   │
  │   └──────────────────┘     └────────────────────────┘   │
  │           │                                             │
  │           ▼                                             │
  │   ┌──────────────────────────────────┐                  │
  │   │         Keycloak Deployment      │                  │
  │   │  ┌──────────┐  ┌──────────┐      │                  │
  │   │  │ Instance │  │ Instance │ ...  │                  │
  │   │  └──────────┘  └──────────┘      │                  │
  │   └──────────┬───────────────────────┘                  │
  │              │                                          │
  │   ┌──────────▼──────────┐  ┌──────────────────────┐     │
  │   │   PostgreSQL DB     │  │  Ingress / Service   │     │
  │   └─────────────────────┘  └──────────────────────┘     │
  └─────────────────────────────────────────────────────────┘

#Архитектура Keycloak Server

#Мультиарендность на основе Realm

Keycloak организует управление идентификацией в изолированные единицы, называемые Realm. Каждый Realm — это независимый домен аутентификации, который управляет своими собственными:

• Пользователями и учетными данными
• Clients (applications)
• Ролями и разрешениями
• Identity providers и federation
• Потоками аутентификации и политиками

Realm master — это административный Realm верхнего уровня, который используется для управления другими Realm и самим экземпляром Keycloak.

#Управление сессиями и кешем

Keycloak поддерживает распределенные данные сессий и кеша между узлами cluster. В развертываниях с несколькими экземплярами состояние сессий разделяется с использованием встроенного cluster Infinispan (JGroups). Конфигурацию кеша можно настроить через ConfigMap, указанный в Keycloak CR.

#Потоки аутентификации

Keycloak поддерживает полностью настраиваемые потоки аутентификации. Flow — это последовательность шагов аутентификации и sub-flows (например, проверка имени пользователя и пароля, за которой следует проверка OTP). Flow можно настраивать для каждого Realm и для каждого client.

#Управление жизненным циклом на основе Operator

#Custom Resource Definitions

Два CRD определяют поверхность Kubernetes API для Alauda Build of Keycloak:

#Цикл reconciliation

Operator непрерывно приводит фактическое состояние ресурсов Keycloak в соответствие с желаемым состоянием, заданным в CR:

1. Пользователь создает или обновляет Keycloak CR.
2. Operator обнаруживает изменение и вычисляет требуемое состояние cluster (Deployment, Service, Ingress, Secrets).
3. Operator применяет необходимые ресурсы Kubernetes.
4. Проверки состояния (liveness и readiness probes) подтверждают, что экземпляр запущен.
5. Для KeycloakRealmImport Operator запускает import Job, который загружает конфигурацию Realm в Keycloak Server.

#Высокая доступность

Для production-развертываний Alauda Build of Keycloak поддерживает конфигурации с высокой доступностью:

• Несколько реплик: Установите spec.instances в значение 2 или больше, чтобы запустить несколько Keycloak Pod. Kubernetes распределяет трафик между всеми здоровыми репликами.
• Совместное использование сессий: Связь cluster Infinispan обеспечивает общий доступ к пользовательским сессиям между всеми репликами. Если один Pod выходит из строя, пользователи прозрачно перенаправляются на другую реплику без повторной аутентификации.
• Database HA: database является единым источником истины для постоянных данных. Используйте высокодоступную конфигурацию PostgreSQL (например, с репликацией или управляемым сервисом database), чтобы исключить database как единую точку отказа.
• Планирование Pod: Используйте spec.scheduling для настройки node affinity, tolerations и topology spread constraints, чтобы распределять Keycloak Pod по доменам отказа (nodes, availability zones).

#Сеть и безопасность

#TLS

Keycloak поддерживает два режима TLS:

• HTTPS на Keycloak Service: Настройте spec.http.tlsSecret, чтобы завершать TLS на уровне Keycloak Pod. Подходит, когда требуется прямое зашифрованное соединение между pod и client.
• TLS на уровне Ingress: Настройте spec.ingress.tlsSecret для завершения TLS на уровне Ingress controller. Сам Keycloak может обслуживать HTTP внутри cluster при spec.http.httpEnabled: true.

#Network Policy

Поле spec.networkPolicy управляет тем, какие источники могут обращаться к HTTP-, HTTPS- и management-портам Keycloak. Это обеспечивает детализированный контроль входящего трафика на сетевом уровне Kubernetes.

#Security Contexts

Alauda Build of Keycloak обеспечивает усиление безопасности через Pod security contexts:

• Запуск от non-root
• Удаление всех Linux capabilities
• Применение профилей seccomp RuntimeDefault