В чек-листе приёмки был пункт про изоляцию: у сервиса автоматизации, который живёт на сервере, не должно быть доступа к хранилищам платформы. Он умеет ставить задачи, но лезть напрямую в базу или в шлюз ему нечего.
Проверяю честно: из контейнера пробую достучаться до базы, до кэша и до шлюза по адресам узла в туннеле. База — отказ. Шлюз — отказ. Сам API платформы напрямую — отказ. Всё опубликовано на петлевом интерфейсе, снаружи не видно. Пункт пройден.
И одна строка выбивается: кэш отвечает.
Полез разбираться — и это не кэш платформы. Тот тоже на петле, тоже недоступен. Отвечает совсем другой процесс: локальный менеджер баз данных для разработки, из тех, что ставят в два клика и забывают. Он поднял свою копию на всех интерфейсах. Проверил, спрашивает ли он пароль, — не спрашивает: отвечает на пинг и отдаёт полную информацию о себе кому угодно.
Ключевое здесь не «приложение плохое». Оно ведёт себя ровно так, как задумано: это инструмент разработчика, он слушает всё и не требует пароля, потому что предполагается, что он на ноутбуке и снаружи его не видно. Так и было — пока я не поднял туннель. Туннель молча превратил локальный инструмент в сетевую службу, доступную с сервера.
Поправить это внутри приложения не выйдет. Строка запуска лежит в его собственных файлах, и оно перепишет их при следующем запуске из своего интерфейса. Правка, которую приложение тихо отменит, хуже отсутствия правки: про неё забудут и будут считать, что дырка закрыта. Значит, закрывать это место надо не в приложении, а на уровне сети.
Что забрал. Первое: проверка изоляции нашла не то, что искала, — и именно в этом её ценность. Второе: когда добавляешь туннель, ты меняешь границу доверия для всего, что уже работает на машине, а не только для того, ради чего его поднимал.