Облачные задачи можно запускать и контролировать не только с рабочей машины: есть родное приложение для телефона и планшета, веб-интерфейс, а на других платформах - веб-приложение через браузер. Разговор из терминала передаётся в облако специальным префиксом, а затем открывается на любой из этих поверхностей. Удобство очевидное: задача продолжает идти, пока вы в дороге, и результат ждёт вас не в закрытом ноутбуке, а в общем месте, куда можно заглянуть с любого устройства.
Но у распределённого доступа есть вторая сторона - идентичность. Ссылку на агента можно отправить коллеге, и это выглядит как обычный обмен ссылками. На деле видимость требует членства в той же команде и собственного доступа к репозиторию через подключённую систему контроля версий, а просмотр по умолчанию доступен только для чтения. Ссылка не расширяет права: она показывает ровно то, что человек и так имел право увидеть. Это правильное поведение, и понимать его стоит до того, как вы попробуете ей поделиться.
Продолжения чужой задачи - отдельный механизм, который включается администратором и имеет три состояния: выключено, только для служебных учётных записей и для всех. Разница между ними намного больше, чем кажется по формулировке. Продолжение запускается с исходными учётными данными и секретами создателя: человек, дописавший сообщение, направляет процесс, который действует от вашего имени и с вашими правами. В журналах провайдера останется ваша учётная запись, хотя направление работе задал другой участник команды.
Поэтому вариант для всех включают не по умолчанию, а после осознанного разбора модели угроз. Он удобен в маленькой доверенной команде, где у всех и так одинаковый доступ, и опасен в большой организации, где право продолжить чужую задачу означает право воспользоваться чужим доступом - в том числе к репозиториям и секретам, которые самому человеку не открыты. Промежуточный вариант, при котором продолжения разрешены только служебным учётным записям, обычно и есть правильный компромисс: у них узкие права, и сузить их ещё сильнее ничего не стоит.
Отсюда общий принцип, который стоит держать в голове при любой командной работе с агентами: делиться результатом - не то же самое, что делиться доступом. Ссылка на разговор, артефакт или пул-реквест показывает результат. Право продолжить работу передаёт полномочия. Эти два действия часто выглядят одинаково в интерфейсе - одна и та же страница, одна и та же кнопка копирования ссылки - и совершенно по-разному устроены в модели безопасности. Смешение этих двух смыслов и порождает большую часть неожиданных каналов доступа.
| Действие | Что оно передаёт |
|---|---|
| Ссылка на агента | Видимость при членстве в команде и своём доступе к репозиторию |
| Просмотр по умолчанию | Только чтение |
| Продолжение чужой задачи | Полномочия: исходные учётные данные и секреты создателя |
| Служебная учётная запись | Узкие права, пригодные для общих автоматизаций |
Стоит понимать и то, что именно переезжает, когда разговор из терминала передают в облако. Переезжает не окно, а исполнение: дальше работа идёт в облачном окружении, со своими репозиториями, секретами и сетевым режимом, а не на вашей машине. Именно поэтому задача и становится видимой на других поверхностях - она больше не привязана к конкретному компьютеру. Обратная сторона та же самая: локальное состояние, незакоммиченные правки и настройки вашей машины за ней не следуют, и рассчитывать на них после передачи нельзя.
Мобильная поверхность добавляет свой нюанс: она удобна для одобрений и коротких уточнений, но плохо подходит для оценки изменений. Экран телефона показывает несколько строк, а решение о слиянии требует видеть изменение целиком и соседний код, которого оно касается. Соблазн подтвердить на бегу возникает ровно там, где подтверждение и требует внимания. Разумная практика - на телефоне читать, направлять и при необходимости останавливать, а решения о слиянии принимать там, где вы действительно можете посмотреть изменения.
Служебная учётная запись решает не только вопрос прав, но и вопрос принадлежности. Общая автоматизация, запущенная от личного профиля, наследует доступ конкретного человека и ломается в тот день, когда он уходит или у него меняются роли. Отдельная учётная запись с узкими правами делает процесс независимым от кадровых движений и заодно упрощает разбор: видно, что действие совершил процесс, а не сотрудник. Признак, по которому это обычно замечают в реальной работе, простой: коллега пишет, что ссылка не открывается. Это не поломка, а работающая модель доступа - у него нет либо членства в команде, либо прав на репозиторий.
Инженерный вывод простой: удалённый доступ хорош для наблюдения и коротких решений, а полномочия остаются вопросом настроек, а не удобства. Разведите три вещи - видимость, право продолжить и права учётной записи, - и командная работа с облачными агентами перестанет создавать неожиданные каналы доступа. Каждая из трёх настраивается отдельно, и ни одну из них удобство интерфейса не отменяет.
Типичные провалы предсказуемы. Считать, что отправленная ссылка даёт коллеге доступ, или наоборот - что она безопасна независимо от настроек. Включить продолжения для всех, не разобрав, чьи учётные данные при этом используются. Одобрять слияние с телефона, не глядя на изменения. Рассчитывать после передачи в облако на локальное состояние машины. И использовать личную учётную запись там, где нужна служебная.