Перейти к содержанию

Kubernetes — Ingress, TLS и аутентификация

Внешний вход в платформу управляется единым параметром exposure (gateway | ingress | none) — он же задаётся при установке через Wizard. Наружу публикуются только точки входа; внутренние сервисы остаются ClusterIP.

Модель доступа извне (exposure)

Трафик идёт через Envoy Gateway (Gateway API). Чарт aigate-gateway создаёт GatewayClass aigate-class и Gateway aigate и рендерит Gateway + HTTPRoute для всех точек входа сразу.

При auth: true дополнительно создаётся OIDC SecurityPolicy: аутентификация через Keycloak (realm llm-firewall, OIDC-клиент envoy-gateway), JWT проверяется во всех сервисах. Только этот режим поддерживает OIDC.

Классический Ingress (ingress-nginx и т.п.) — публикуется только Admin UI. OIDC недоступен: сервисы открываются без логина, поэтому режим пригоден для изолированных/доверенных контуров.

Точка входа не создаётся. Gateway / Ingress / HTTPRoute и аутентификацию вы настраиваете самостоятельно поверх установленных сервисов.

Точки входа

Точка входа Сервис Назначение
Трафик LLM api-gateway основной прокси-эндпоинт для клиентов
Admin UI admin-ui административная панель
Admin API admin-api административный API (за аутентификацией)
Webhook (опц.) llm-gateway-adapter guardrail для внешнего LLM Gateway

TLS

TLS-сертификат задаётся секретом, имя которого передаётся в ingressTlsSecretName (используется и в режиме gateway, и в ingress). Создайте секрет заранее:

kubectl -n aigate create secret tls aigate-tls \
  --cert=tls.crt --key=tls.key

После этого пропишите ingressTlsSecretName: aigate-tls в values.yaml (при auth: true + https секрет обязателен).

Аутентификация (Keycloak + OIDC)

В production-режиме exposure: gateway + auth: true доступ защищён OIDC SecurityPolicy Envoy Gateway перед Keycloak (realm llm-firewall, OIDC-клиент envoy-gateway); JWT валидируется во всех сервисах. В режимах ingress и none встроенный OIDC не поднимается.

Note

Управление пользователями и ролями (RBAC) описано в Руководстве администратора.