Как собрать

OpenClaw на всю команду: один сервер, вход через Cloudflare Access, роли

Поднимаем один Gateway на команду: туннель Cloudflare, вход через Access, профили операторов, роли и плановый откат.

· 8 мин чтения

Коротко

  • Новая страница документации 2026.9.7 собирает командное развёртывание в один путь: один Gateway, Cloudflare Tunnel + Access, GitHub-идентичность, роли, read-only шаринг.
  • Перед выносом наружу прогоните чек-лист по безопасности: openclaw doctor, openclaw security audit --deep, openclaw health, и только потом открывайте туннель.

Сверено с документацией OpenClaw 2026.9.7, 1 октября 2026.

Когда в Gateway заходит второй человек, появляются вопросы: кто это, что ему можно, кому он может показать свою сессию. Новая страница «Deploy a team server» в документации 2026.9.7 собирает ответы в одну инструкцию: один постоянный сервер на команду, Cloudflare Tunnel и Access, вход через Access, профили операторов с ролями и шаринг сессий.

Что нужно заранее

  • Linux-хост с постоянным хранилищем и отдельной сервисной учёткой, поддерживаемая версия Node, установленный OpenClaw.
  • Домен под управлением Cloudflare, аккаунт Zero Trust и cloudflared на хосте.
  • Провайдер идентичности и явная политика «кому можно входить».
  • Модельные креды и, если нужен, бот-аккаунт для командного чата.
  • Административный SSH, приватное хранилище секретов и бэкап за пределами сервера.

Документация отдельно предупреждает: Gateway это одна граница доверия. Роли и владение сессиями помогают в совместной работе, но не изолируют недоверенных пользователей друг от друга. Недоверенный код держите в песочницах или на удалённых воркерах, а для взаимно недоверенных команд поднимайте отдельные Gateway, OS-учётки или хосты.

Шаг 1. Установка под одной сервисной учёткой

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

openclaw onboard --install-daemon
openclaw gateway status --deep

SSH оставьте открытым только из админской сети, Gateway держите на loopback, порт 18789 наружу не выставляйте. Туннель Cloudflare сам делает исходящее соединение, поэтому входящее правило для Gateway в фаерволе не нужно. Зафиксируйте ID агента, например assistant, и используйте его во всех привязках каналов и ролях.

Шаг 2. Публичный URL и доверенный вход

Сначала создайте Access-приложение для team.example.com и пустите по нему только тех администраторов, которые закончат настройку. Потом поднимите туннель с одной записью ingress на loopback Gateway. Публичного обхода для Control UI и его WebSocket быть не должно.

tunnel: <tunnel-id>
credentials-file: /etc/cloudflared/<tunnel-id>.json
ingress:
  - hostname: team.example.com
    service: http://localhost:18789
  - service: http_status:404

Файл с кредом туннеля защитите и запускайте cloudflared как сервис. Локальный пароль для обслуживания спрячьте в SecretRef. Пример ниже ждёт переменную OPENCLAW_GATEWAY_PASSWORD и в сервисе Gateway, и в CLI владельца. Раздавать этот пароль коллегам нельзя: он представляет общего владельца.

Слейте блок ниже в существующий конфиг, не трогая своих агентов, модели и каналы:

{
  gateway: {
    mode: "local",
    bind: "loopback",
    publicOrigin: "https://team.example.com",
    trustedProxies: ["127.0.0.1", "::1"],
    auth: {
      mode: "trusted-proxy",
      password: { source: "env", provider: "default", id: "OPENCLAW_GATEWAY_PASSWORD" },
      identityScopes: {
        "admin@example.com": ["operator.admin"],
      },
      trustedProxy: {
        userHeader: "cf-access-authenticated-user-email",
        requiredHeaders: ["cf-access-jwt-assertion"],
        allowLoopback: true,
        deviceAutoApprove: {
          enabled: true,
          scopes: ["operator.read", "operator.write", "operator.approvals", "operator.questions"],
        },
      },
    },
    roles: {
      default: "observer",
      definitions: {
        observer: {
          sessions: { others: "view" },
          agents: [],
          scopes: ["operator.read"],
        },
        member: {
          sessions: { others: "write" },
          agents: ["assistant"],
          scopes: ["operator.read", "operator.write", "operator.approvals", "operator.questions"],
        },
        administrator: {
          sessions: { others: "write" },
          agents: "*",
          scopes: ["operator.admin"],
        },
      },
    },
  },
}

Если раньше был gateway.auth.token или OPENCLAW_GATEWAY_TOKEN, удалите их: общий токен несовместим с режимом trusted-proxy. Fallback на локальный пароль при этом остаётся.

openclaw config validate --json
openclaw gateway restart
openclaw gateway status --deep

allowLoopback доверяет локальным процессам наравне с cloudflared. OpenClaw проверит источник прокси и обязательные заголовки, но само наличие заголовков это ещё не проверка подписи JWT. Внешнюю границу аутентификации держат Access и приватный origin. На этом слушателе нельзя запускать враждебные нагрузки.

publicOrigin говорит OpenClaw, какой внешний URL объявлять клиентам, и подставляет его в список разрешённых браузерных источников. Если Control UI живёт на том же источнике, отдельный gateway.controlUi.allowedOrigins задавать не нужно. Для существующего сервера, где не хватает только этой настройки, есть безопасная запись:

openclaw config set gateway.publicOrigin https://team.example.com --expect-current-absent

Команда отказывается перезаписывать уже заданное значение. На втором сервере ставьте https://release.example.com, а не копируйте URL первого.

Шаг 3. Администраторы и роли

Пусть администратор один раз войдёт через Access. Его постоянный профиль в Gateway появится с ролью observer. Дальше из локальной оболочки обслуживания поднимите его до администратора:

openclaw users list --json
openclaw gateway call users.setRole \
  --params '{"profileId":"<administrator-profile-id>","role":"administrator"}' \
  --json

Смена роли закрывает активные подключения этого профиля, браузер придётся переподключить. Администратору нужны и явный identityScopes, и роль с потолком operator.admin. Локальный общий владелец остаётся доступным для обслуживания, и личную роль ему не назначить.

Расширьте Access-политику на команду. После первого входа каждого участника назначайте ему роль member тем же способом. Observer в этом примере читает видимые сессии, но не запускает работу агента. Делать дефолтную роль временно административной ради онбординга нельзя.

Шаг 4. Синхронизация с GitHub-идентичностью

Разнесите четыре ответственности по разным слоям: кто доходит до сайта решает Cloudflare Access, кто именно сидит в системе это проверенный вход и профиль Gateway, что этому человеку разрешено это scopes и именованные роли оператора, каким аккаунтом публикуется код это системная, агентская или личная GitHub-привязка.

С провайдером GitHub в Access OpenClaw опрашивает эндпоинт идентичности Access, сверяет email с аутентифицированным субъектом прокси и подтягивает текущий логин по неизменному числовому ID аккаунта. Имена и аватары обновляются при следующих входах. Это синхронизация по входу, а не фоновый импорт всех членов организации. Профили и роли локальны для каждого Gateway: один и тот же проверенный GitHub-аккаунт идентифицирует человека на двух серверах, не делая их локальные ID равными.

При смене OIDC-провайдера или адреса почты старый профиль можно сохранить по проверенному email:

openclaw users link-email new-address@example.com \
  --to <existing-profile-id> --json

Связывание почты сохраняет профиль и роль, но не копирует выданный scope старого адреса. Для администратора выше новый адрес тоже должен получить свой ["operator.admin"] в gateway.auth.identityScopes. Обновите политику Access или список разрешённых email в trustedProxy.allowUsers, держите старый выданный scope до конца миграции и удалите его, когда идентичность больше не нужна. Объединять людей по отображаемому имени или копировать базы профилей между живыми серверами нельзя.

Шаг 5. Шаринг сессий и режим Worktree

На team.openclaw.ai сами разработчики OpenClaw ведут задачи через один и тот же разговор: выбирают проект и режим Worktree для управляемой ветки и рабочей копии, задают агенту конкретное изменение и проверки. Коллеги с доступом открывают ту же сессию, добавляют контекст и правят следующий ход, а владелец сессии отвечает за доведение до конца. После проверки результата и разницы в рабочей копии изменения публикуются через Publish PR под выбранным GitHub-аккаунтом, ссылка на PR и его CI остаётся в разговоре.

Роль observer в примере выше видит чужие сессии в режиме others: "view". Новые scopes operator.sessions.read и operator.sessions.write появились в 2026.9.7 как раз под этот сценарий: первый для чтения видимых сессий и истории, второй дополнительно для организации своих сессий и запуска собственной работы. Оба не дают общей диагностики, изменения конфигурации или публикации. Архивирование сессии не даёт права её удалить, чужие видимые сессии остаются доступными только для чтения даже под operator.sessions.write. Полный режим разрешений, песочница и изменение окна контекста существующей сессии по-прежнему требуют администратора.

Как проверить

  • openclaw config validate --json принимает конфиг с mode: "trusted-proxy", ролями и identityScopes.
  • openclaw users list --json возвращает профили участников с их email-алиасами.
  • После входа администратора через Access повторное подключение применяет роль administrator.
  • Read-only шаринг: войдите вторым аккаунтом под observer и убедитесь, что сессия первого видна, но править её нельзя.

Если что-то пошло не так

При избыточном выставлении Gateway наружу чек-лист по безопасности предлагает вернуть его на loopback и закрыть все каналы:

{
  gateway: {
    bind: "loopback",
  },
  channels: {
    whatsapp: { dmPolicy: "disabled" },
    telegram: { dmPolicy: "disabled" },
    discord: { dmPolicy: "disabled" },
    slack: { dmPolicy: "disabled" },
  },
  tools: {
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
}

Дальше остановите публичный форвардинг и маршруты прокси, смените токены и пароли Gateway и затронутых интеграций, вычистите "*" и неожиданных отправителей из списков разрешений, прогоните openclaw security audit --deep и только потом включайте доступ заново по самому узкому шаблону.

Типичные сбои этого сценария и их признаки:

  • Остался старый gateway.auth.token или OPENCLAW_GATEWAY_TOKEN. Режим trusted-proxy с ним несовместим, удалите токен и оставьте только SecretRef с паролем.
  • В Access попал публичный bypass для Control UI или WebSocket. Закройте его до того, как пускать команду.
  • Администратор вошёл, но нужных полномочий не видит. Не хватает записи в gateway.auth.identityScopes или роль назначили, но identityScopes остался без operator.admin.
  • После смены OIDC или почты профили разъехались. Используйте openclaw users link-email и не сливайте людей по display name.
  • Хочется раскатать один конфиг на два Gateway. Под второй контур поднимите отдельный сервер, конфиг и состояние, роль назначайте локально.
  • Забыли прогнать чек-лист по безопасности. Перед открытием туннеля выполните openclaw doctor, openclaw security audit --deep, openclaw health и зафиксируйте остаточные предупреждения.