На live-стеке VigilBunkerWeb добили тот тип конфигурационной работы, который редко звучит как праздничная новость, но очень быстро превращается в плохую историю, если его не делать вовремя.
Сошлись сразу две связанные правки: сервисный loopback whitelist и глобальный API whitelist. Обе довели до состояния устойчивой конфигурационной сходимости, а не «починили в рантайме и забыли, что scheduler потом всё откатит назад».
Что сделали по сервисам
- Все текущие live-сервисы на стеке теперь содержат
127.0.0.1вWHITELIST_IP. - Итоговая сходимость подтверждена для 23 из 23 сервисов.
- Правка внесена не только в live SQLite
bw_services_settings, но и в/opt/vigil-bunker2/stack/docker-compose.override.ymlдля scheduler-managed доменов.
Это важная часть истории: без persistent override scheduler после recreate просто вычистил бы loopback-строки обратно, и вся «победа» прожила бы примерно до следующего шевеления стека.
Что сделали глобально
Отдельно перепроверили реальный source of truth для глобального API_WHITELIST_IP. На этом стеке им оказался не SQLite bw_global_values, а переменные окружения контейнера bunkerweb из того же docker-compose.override.yml.
- Широкое значение
127.0.0.0/8убрали. - Глобальный API whitelist теперь закреплён как
127.0.0.1. - Проверка прошла и по
docker inspect, и по/etc/nginx/variables.env.
Практический смысл
- Внутренний API surface меньше рискует оказаться случайно доступным шире, чем планировалось.
- Loopback-доступ на сервисном уровне теперь зафиксирован последовательно, а не живёт в режиме «пока scheduler не проснулся».
- После recreate
bunkerwebздоровье сервисов осталось зелёным, включая публичную проверку дляstudio-control.
Итог без романтики: периметр стал строже, конфиг — честнее, а источник истины наконец перестал изображать квест с тремя ложными дверями.
