Add impersonation documentation to RBAC security guide.

content/documentation/admin/security/impersonation.ru.md

@@ -0,0 +1,50 @@
+---
+title: Имперсонация
+weight: 25
+---
+
+DDP поддерживает режим имперсонации: пользователь с глобальным разрешением `impersonate:users` может временно работать в веб-интерфейсе от имени другого пользователя.
+
+{{< alert level="info" >}}
+Имперсонация доступна только при входе через браузер (сессия Dex). Запуск через API-токены не поддерживается.
+{{< /alert >}}
+
+## Запуск и завершение
+
+1. Перейдите в раздел «Администрирование» → «Пользователи».
+1. В строке нужного пользователя нажмите «Войти как этот пользователь».
+1. Платформа переключит сессию на выбранного пользователя; внизу экрана появится баннер «Вы вошли как: …» с таймером до автоматического завершения.
+1. Чтобы завершить имперсонацию досрочно, нажмите «Завершить сессию» в баннере.
+
+Кнопка «Войти как этот пользователь» недоступна для заблокированных пользователей и для вашей собственной учётной записи.
+
+## Ограничения безопасности при запуске
+
+Имперсонация не будет запущена, если:
+
+- выбранный пользователь заблокирован;
+- выбран тот же пользователь, под которым уже выполнен вход;
+- выбран супер-администратор, а оператор не является супер-администратором;
+- выбран пользователь, у которого уже есть глобальное разрешение `impersonate:users` (исключение: оператор — супер-администратор).
+
+## Срок действия сессии
+
+Сессия имперсонации имеет ограниченное время жизни:
+
+- длительность сессии: 30 минут;
+- по истечении времени сессия завершается автоматически;
+- в интерфейсе отображается таймер обратного отсчёта до автоматического завершения.
+
+Если пользователь не завершил имперсонацию вручную, платформа завершит её автоматически после истечения срока действия.
+
+## Аудит
+
+Для HTTP-запросов, попадающих в аудит-логи (POST, PUT, DELETE, PATCH), в поле «Email» указывается оператор и целевой пользователь в формате `оператор@example.com [as целевой@example.com]`.
+
+Это позволяет в записи аудит-лога определить:
+
+- кто инициировал запрос;
+- от чьего имени выполнялась операция в сессии;
+- HTTP-метод, путь и статус ответа.
+
+Запросы GET в аудит-логи не записываются. Подробнее — [в документации по аудит-логам](../audit-logs/).

content/documentation/admin/security/overview.ru.md

@@ -17,30 +17,36 @@ DDP Backend использует ключи подписи, получаемые
 В DDP реализована ролевая модель доступа, обеспечивающая разграничение прав пользователей и контроль операций, выполняемых в платформе.
 
 Модель поддерживает иерархию ролей и проверку разрешений на уровне супер-администратора, глобальных ролей, ролей ресурсов и ролей сущностей.
-Подробнее — в [документации по ролевой модели](../rbac/).
+Подробнее — [в документации по ролевой модели](../rbac/).
+
+## Имперсонация
+
+DDP позволяет пользователю с разрешением `impersonate:users` временно работать в интерфейсе от имени другого пользователя для проверки прав доступа и диагностики. Сессия ограничена по времени; операции с учётными данными и секретами целевого пользователя в этом режиме недоступны.
+
+Подробнее — [в документации по имперсонации](../impersonation/).
 
 ## Учётные данные
 
 DDP обеспечивает централизованное и безопасное хранение учётных данных, используемых для интеграции с внешними системами и сервисами. Хранение и обработка учётных данных выполняются на стороне DDP Backend с использованием базы данных PostgreSQL.
 
-Перед сохранением в базе данных учётные данные шифруются с применением алгоритма AES-GCM. Расшифровка выполняется DDP Backend только в момент использования учётных данных в действиях, источниках данных или виджетах.
-Подробнее — в [документации по учетным данным](../credentials/).
+Перед сохранением в базе данных учетные данные шифруются с применением алгоритма AES-GCM. Расшифровка выполняется DDP Backend только в момент использования учетных данных в действиях, источниках данных или виджетах.
+Подробнее — [в документации по учетным данным](../credentials/).
 
 ## Доверенные сертификаты
 
 DDP позволяет добавлять в хранилище корневые и промежуточные сертификаты (CA) или сертификаты серверов. Они используются при проверке TLS в исходящих HTTPS-запросах к внешним сервисам (в действиях, виджетах, источниках данных и др.).
 
 Управление доверенными сертификатами осуществляется через веб-интерфейс в разделе «Администрирование» → «Доверенные сертификаты».
-Подробнее — в [документации по доверенным сертификатам](../trusted-certificates/).
+Подробнее — [в документации по доверенным сертификатам](../trusted-certificates/).
 
 ## Аудит-логи
 
 Аудит-логи предназначены для регистрации действий пользователей и контроля операций, выполняемых через API платформы. Формирование аудит-логов выполняется на стороне DDP Backend.
 
 Такие логи создаются автоматически для всех HTTP-запросов, за исключением GET. Каждая запись содержит информацию о пользователе, IP-адресе клиента, эндпоинте, HTTP-методе и статусе ответа.
 
-Аудит-логи сохраняются в базе данных PostgreSQL и доступны для просмотра через веб-интерфейс платформы.
-Подробнее — в [документации по аудит-логам](../audit-logs/).
+Аудит-логи сохраняются в базе данных PostgreSQL и доступны для просмотра через веб-интерфейс платформы. Также возможна выгрузка аудит-логов в CSV из интерфейса платформы.
+Подробнее — [в документации по аудит-логам](../audit-logs/).
 
 ## HTTP-заголовки безопасности
 
@@ -57,4 +63,4 @@ DDP позволяет добавлять в хранилище корневые
 - Permissions-Policy.
 - Strict-Transport-Security (HSTS).
 
-Настройка осуществляется в конфигурации DDP в секции `security.headers`. Подробнее — в [документации по HTTP-заголовкам безопасности](../http-security-headers/).
+Настройка осуществляется в конфигурации DDP в секции `security.headers`. Подробнее — [в документации по HTTP-заголовкам безопасности](../http-security-headers/).

content/documentation/admin/security/rbac.ru.md

@@ -117,6 +117,10 @@ weight: 20
 Типы учётных данных:
 - `edit:user-access-credentials-types` — создание, редактирование и удаление типов учётных данных; настройка интеграции с Vault (просмотр и изменение конфигурации, проверка подключения).
 
+Пользователи:
+- `edit:users` — создание, блокировка, разблокировка и удаление пользователей.
+- `impersonate:users` — запуск и завершение имперсонации пользователей. Подробнее — [в документации по имперсонации](../impersonation/).
+
 {{< alert level="info" >}}
 Разрешение `update:team-variables` позволяет редактировать переменные только тех команд, участником которых является пользователь. Даже супер-администратор не сможет изменить переменные команд, в которых не состоит.
 {{< /alert >}}

content/documentation/release-notes/v1.6.0.ru.md

@@ -10,6 +10,11 @@ description: Заметки о выпуске v1.6.0 — выгрузка ауд
 
 ## Новые возможности
 
+### Пользователи
+
+- Добавлена имперсонация пользователей. Подробнее — в разделе [«Имперсонация»](../../admin/security/impersonation/).
+- Добавлена возможность создания [«сервисных пользователей»](../../user/teams-users/#сервисные-пользователи).
+
 ### Аудит-логи
 
 Добавлена выгрузка аудит-логов в CSV. Подробнее — в разделе [«Аудит-логи»](../../admin/security/audit-logs/#выгрузка-в-csv).

content/documentation/user/teams-users.ru.md

@@ -2,7 +2,9 @@
 title: Команды и пользователи
 ---
 
-В Deckhouse Development Platform (DDP) существует две встроенные сущности — команды и пользователи. Основным источником данных для авторизации является Dex, установленный в Deckhouse Kubernetes Platform. Создание встроенных пользователей и команд не поддерживается.
+В платформе существуют две встроенные сущности — команды и пользователи. Основным источником данных для авторизации является Dex, установленный в Deckhouse Kubernetes Platform.
+
+Пользователи обычно появляются при первой авторизации через Dex; администратор также может создать учётную запись заранее. Создание команд вручную в платформе не поддерживается.
 
 Принадлежность пользователя к командам определяется на основе информации из Dex и обновляется при каждой аутентификации пользователя.
 
@@ -44,5 +46,23 @@ title: Команды и пользователи
 Время последней активности пользователя в платформе. Отображается в таблице пользователей в разделе «Администрирование» → «Пользователи». Обновляется при авторизации, либо при автоматической ротации JWT-токена пользователя (интервал ротации зависит от конфигурации Dex и по умолчанию равен 10 минутам).
 
 {{< alert level="info" >}}
-Время последней активности не обновляется при использовании API-токена, выписанного пользователем, либо при каких-либо действиях пользователя в платформе в интервале между автоматическими ротациями JWT-токена.
+Время последней активности не обновляется при использовании API-токена, выписанного пользователем, либо при каких-либо действиях пользователя в платформе в интервале между автоматическими ротациями JWT токена.
 {{< /alert >}}
+
+## Сервисные пользователи
+
+Сервисный пользователь — учётная запись платформы для автоматизации и интеграций (скрипты, технические сценарии).
+
+От обычного пользователя сервисный отличается тем, что не может авторизоваться в веб-интерфейсе через Dex. В таблице «Администрирование» → «Пользователи» у таких записей в колонке «Последняя активность» обычно отображается «никогда».
+
+При этом для сервисного пользователя доступны:
+
+- настройка учётных данных для внешних сервисов;
+- создание API-токенов для вызова API DDP;
+- роли и команды — по тем же правилам RBAC, что и для остальных пользователей.
+
+Учётную запись можно пометить как сервисную при создании в разделе «Пользователи» или переключателем «Сервисный пользователь» в таблице. Для этого администратору нужно разрешение `edit:users`. Супер-администратор не может быть сервисным пользователем.
+
+Поскольку сервисный пользователь не может войти через браузер, учётные данные и API-токены для него настраивают через [имперсонацию](../../admin/security/impersonation/): администратор с разрешением `impersonate:users` входит в сессию «как этот пользователь» и заполняет профиль от его имени.
+
+На странице «Администрирование» → «Лицензия» сервисные пользователи учитываются отдельно и не входят в показатель «Лицензируемые».