Почему студии не нужен пароль от репозитория заказчика
Заказчик присылает логин и пароль от своего GitHub, студия хранит их до конца проекта и после. Заявка по ссылке решает то же самое: заказчик авторизует доступ сам, у себя.
Обычный сценарий: студия берёт проект, где код принадлежит заказчику. Чтобы выкатывать, нужен доступ к репозиторию. Заказчик присылает логин и пароль — или токен — в переписке.
Дальше этот доступ живёт у студии до конца проекта. И после конца тоже.
Что не так с присланным паролем
Он не отзывается. Точнее, отозвать его может только заказчик, а он про него забудет через неделю после сдачи.
Он шире, чем нужно. Доступ к учётной записи — это доступ ко всем её репозиториям, а не к одному вашему.
Он лежит в переписке. Мессенджер, почта, тред с пятью участниками — везде, куда его переслали, он остаётся навсегда.
Он ваш риск, а не его. Если доступ утечёт из вашей папки, объясняться перед заказчиком будете вы, независимо от того, кто его туда положил.
Как мы это развернули
Подключение репозитория идёт заявкой по ссылке. Вы отправляете заказчику ссылку, он открывает её у себя и авторизует доступ в своём аккаунте.
Пароля вы не получаете вовсе — его негде хранить и нечего терять.
Важная оговорка, чтобы не выдавать чужое за своё: отсутствие пароля здесь — свойство того, как устроена авторизация в git-хостингах, а не наша заслуга. Наша часть в другом: мы сделали этот путь основным вместо привычного «пришлите доступ», и убрали второй.
Что это меняет на практике
| Пароль в переписке | Заявка по ссылке | |
|---|---|---|
| кто отзывает | заказчик, если вспомнит | заказчик, в своих настройках, в любой момент |
| объём | вся учётная запись | то, что он выдал |
| где остаётся | в чате навсегда | нигде |
| чей риск | ваш | распределён |
И отдельно — разговор при сдаче проекта. «Отзовите наш доступ» звучит совсем иначе, когда отзывать надо одну запись в настройках, а не менять пароль, который вы могли где-то сохранить.
Обратная сторона: доступы, которые заказчик всё-таки присылает
Панель хостера, регистратор домена, платёжный провайдер — там ссылки-заявки нет, и присылать придётся.
Для этого случая у нас форма запроса: заказчик вводит доступ сам, по ссылке, и он сразу попадает в зашифрованное хранилище — минуя переписку. Обратный ход — одноразовая ссылка со сроком жизни, когда доступ надо передать подрядчику.
Смысл обеих механик один: секрет не должен появляться в мессенджере даже на минуту. Оттуда его уже не убрать.
Что из этого следует
Каждый чужой доступ, который вы храните, — это обязательство, о котором обычно не думают как об активе с риском. Оно не отражено в договоре, не оценено и не имеет срока.
Правило, к которому мы пришли: не берите доступ, если задачу можно решить без него. А если взять всё-таки нужно — берите так, чтобы отозвать мог тот, чей он.
Мы подключаем репозиторий заказчика заявкой, а серверы — агентом без ключей. Как устроен выкат — Деплой из Git.
Читайте также
- Почему оператор SaaS не должен уметь читать ваши секретыПраво доступа к чужим данным всегда объясняют поддержкой. Разница между «мы обещаем не смотреть» и «мы не можем посмотреть» — это разница между регламентом и устройством.
- Мы развёртываем на серверы клиентов и не храним ни одного SSH-ключаКлючи в папке — самая дорогая вещь в студии и самая незаметная. Разбор pull-модели: агент сам приходит за заданием, подписывает запросы Ed25519, приватная часть не покидает машину.
Автор
Александр ЦапковОснователь Скоупворк
Веду платформу и её боевой контур сам: разработка, выкат, дежурство. Пишу о том, на чём мы обожглись, — с датами, замерами и ссылками на решения в репозитории.