2.9 KiB
2.9 KiB
Вопросы к DevOps / команде Keycloak — IP WhiteList
Обновлено: 2026-05-30 14:43
Часть вопросов из первоначального списка закрыта реализацией.
❌ ОТКРЫТЫЕ (блокируют деплой)
1. Данные клиента Keycloak
Для активации OIDC-режима (код готов, ждёт переменных):
KC_CLIENT_ID= ? # наш client_id в realm cloud
KC_CLIENT_SECRET= ? # наш client_secret
Redirect URI для регистрации в Keycloak:
https://white.nodejsk8s.dev.nubes.ru/callback
2. Admin-роль: как приходит из Keycloak
ТЗ: Администратор = clientId = WZ01112 + «отдельный чек-бокс».
Сейчас: isAdmin = (ClientID === process.env.ADMIN_CLIENT_ID) — только WZ01112.
Вопросы:
- Есть ли отдельный claim в JWT для признака admin?
- Если да — как называется? Примеры:
realm_access.roles,resource_access.whitelist.roles,is_admin,groups… - Нужна поддержка нескольких adminов или только WZ01112?
Если нет отдельного claim — оставляем текущее решение, закрываем вопрос.
3. /export — IP-ограничение
ТЗ: «на старте может работать без авторизации (по сетевому ограничению)».
Сейчас: открытый endpoint, rate-limit 20 req/мин.
- Ограничение делаем в приложении или в ingress/nginx?
- Если в приложении — список разрешённых IP (env var
EXPORT_ALLOWED_IPS?).
✅ ЗАКРЫТЫЕ
| # | Вопрос | Решение |
|---|---|---|
| DEV_MODE | Нужен ли dev-режим на платформе? | /dev-login — backdoor с DEV_MODE=true (без пароля) или DEV_SECRET=xyz (с ключом). Работает в обоих режимах. |
| Email claim | Как называется claim с email? | Берём payload.email || payload.login || 'unknown' |
| JWT структура | Формат токена auth-api | Изучен из реального токена (см. [DEPRECATED]-auth-architecture.md). Поля: ClientID, company_id, company_name, email, login. |
| CSRF | Защита POST-форм | csrf-csrf (double-submit cookie pattern) |
| Session | Хранение пользователя | express-session (httpOnly, sameSite lax, 8ч) |
Условные обозначения в коде
// TODO(KK): уточнить формат claim — см. docs/questions.md#2
// FIXME(KK): временно, заменить после ответа команды