Права и области

Gateway использует явные области доступа, чтобы каждая идентичность могла выполнять только нужную работу с нужными ресурсами. Область содержит базовую возможность и при необходимости суффикс ресурса.

docker:containers:view
docker:containers:view:<node-id>/<resource-id>
databases:view:<database-id>
nodes:details:<node-id>

Базовая возможность определяет разрешённое действие. Суффикс ограничивает его конкретной нодой или идентичностью ресурса. При каждой серверной операции Gateway проверяет аутентифицированную идентичность, итоговые групповые и прямые разрешения, владение ресурсом, текущее состояние продукта и доступность функции по тарифу. Видимость разделов и отключённые элементы интерфейса помогают пользователю понять свои права, но сами по себе не обеспечивают авторизацию.

Права отвечают на два разных вопроса: какое действие разрешено и на какой ресурс оно распространяется. Например, пользователь может видеть Container, но не чувствительные сведения о хосте, или управлять одним Route, не получая управление всеми Routes на его ноде Ingress. Выдавайте минимальный набор разрешений, необходимый для реального сценария, а не широкий доступ только ради появления недоступного экрана.

Правила проектирования

Для обычного доступа используйте группы, а прямые разрешения пользователям оставляйте для исключений.
Предпочитайте разрешения на конкретный ресурс доступу ко всей ноде или разделу продукта.
Разделяйте просмотр и изменение, раскрытие секретов, экспорт, точки монтирования и разрушительные действия.
Считайте API-токены и разрешения OAuth делегированными полномочиями, а не альтернативным способом получить права администратора.
Проверяйте полный путь пользователя: видимость навигации и отказ при прямом запросе к API.

Начните с задачи, которую должна выполнять идентичность. Перечислите действия чтения, необходимые для поиска и проверки цели, действия изменения и отдельно защищённые данные или разрушительные операции. Затем ограничьте каждое разрешение точным ресурсом, нодой или папкой, где выполняется работа. Членство в группах обычно проще проверять и отзывать, чем множество прямых разрешений одному пользователю.

Не выдавайте глобальное право управления только потому, что рабочий процесс затрагивает несколько типов ресурсов. Для публикации могут понадобиться ограниченные права на Pages Project, Domain, сертификат, Route и состояние Build Worker, но не общее администрирование нод или экспорт закрытых ключей. До использования в рабочей среде проверьте весь процесс через предполагаемую идентичность без административных прав.

Уровни областей и видимость

Глобальные области действуют во всей разрешённой части продукта. Разрешения уровня ноды ограничивают операции ресурсами конкретной управляемой ноды, если контракт ресурса поддерживает такой уровень. Разрешения уровня ресурса указывают одну долговременную идентичность Gateway. Папки могут объединять поддерживаемые ресурсы и участвовать в модели доступа, но перемещение ресурса в папку не меняет владельца его жизненного цикла, среду выполнения или сетевой путь.

Видимость ресурса намеренно отделена от видимости хоста. Пользователь может работать с назначенной ему нагрузкой, не видя инвентарь постороннего хоста. Поиск, навигация, REST, обнаружение инструментов MCP, подписки в реальном времени и прямые запросы ресурса должны применять одинаковые итоговые правила доступа. Отсутствие пункта навигации ещё не доказывает запрет — проверьте и прямой запрос.

Важные разграничения

Право изменять Container не даёт права изменять точки монтирования.
Доступ к базе данных не даёт права раскрывать учётные данные.
Право использовать Inference не даёт доступа к AI Workspace.
Просмотр ресурса не даёт права просматривать сведения о его ноде.
Право изменять Route не даёт права экспортировать закрытый ключ сертификата.

Для других чувствительных операций действует тот же принцип. Доступ к Console или файлам отделён от обычного просмотра рабочей нагрузки. Экспорт архива отделён от просмотра файлов или конфигурации ресурса. Право изменить секрет не означает право его раскрыть: значения, доступные только для записи, заменяются, а не извлекаются. Согласие OAuth и обнаружение инструментов MCP не добавляют областей, которых нет у пользователя-владельца.

AI Workspace и удалённый MCP используют обычную модель авторизации Gateway. Доступ к AI Workspace и использование Gateway Inference — разные возможности. Для удалённого MCP требуются собственный ресурс OAuth и mcp:use; сеансы браузера, обычные API-токены gw_, токены журналирования, токены вывода и токены OAuth для другого ресурса не взаимозаменяемы с учётными данными MCP.

Программные идентичности

Используйте отдельные учётные данные для интерактивного администрирования, CI, мониторинга и сторонних инструментов. API-токен действует с делегированными полномочиями своего пользователя Gateway. OAuth client добавляет явный жизненный цикл перенаправления и согласия. Удалённый MCP использует OAuth и показывает только инструменты, совместимые с текущей идентичностью и состоянием продукта. Отдельный токен gwi_ относится к контура данных Gateway Inference и не подходит для обычных запросов к API Gateway.

Для каждых учётных данных автоматизации укажите владельца, назначение, ожидаемый срок ротации и зависимую систему. Один раз сохраните секрет в менеджере секретов и не помещайте его в URL репозитория, историю команд, снимки экрана или журналы. Проверьте одно разрешённое и одно запрещённое действие. Если токен утрачен, создайте новый и отзовите прежний: замаскированный секрет нельзя восстановить через UI.

Отзыв прав

Сеансы, API, MCP и защищённые операции WebSocket повторно проверяют доступ. Отзыв группы, токена или разрешения ресурса должен блокировать новые привилегированные действия и при необходимости завершать защищённые потоки. Ранее открытая страница или уже обнаруженный инструмент не сохраняют полномочия после отзыва.

Когда обязанности пользователя меняются, вместе проверьте его группы, прямые разрешения, активные сеансы, API-токены, разрешения OAuth и зависимости автоматизации. Блокировка пользователя прекращает новое использование, но сохраняет авторство прежних действий. После удаления исторические записи аудита остаются, а восстановление удалённой записи не активирует её автоматически.

Для ротации сначала создайте новые учётные данные, обновите зависимую систему и подтвердите успешное использование, а затем отзовите старые. При подозрении на утечку сначала отзовите данные, если это безопасно для работы сервиса, затем проверьте аудит и идентификаторы запросов, отдельно завершите связанные сеансы и замените зависимые секреты, которые могли быть раскрыты.

Проверка и диагностика ошибок

Проверяйте права от имени той идентичности, которая будет ими пользоваться, а не от администратора. Убедитесь, что навигация и поиск показывают ожидаемые ресурсы, прочитайте целевой ресурс, выполните одну разрешённую операцию и попробуйте одно заведомо запрещённое действие. Для автоматизации дополнительно проверьте ошибку валидации и сопровождение асинхронной Task.

Интерпретируйте ошибки по уровню, который их выдаёт: 401 означает отсутствующую или недействительную аутентификацию; 403 обычно указывает на отсутствующую область или недоступную по тарифу функцию; 404 может означать отсутствие видимости ресурса, а не только его отсутствие; 409 указывает на конфликт жизненного цикла, квоты или текущего состояния; 422 означает недопустимые входные данные. Проверьте код и ответ конкретного API-запроса, а для асинхронной операции — сообщение Task. Не пытайтесь решить конфликт тарифа или жизненного цикла расширением прав.

Практические сценарии описаны в разделе Области, токены и OAuth.