Уебхук на GitHub не достига до частен Jenkins: поправете пътя

Можете да отворите Jenkins през VPN и въпреки това да видите как GitHub съобщава за неуспешен уебхук, защото това са две различни връзки с двама различни собственици. Браузърът минава през тунел, договорен от лаптопа; услугата за доставка на GitHub започва от публичния интернет и няма маршрут към частната мрежа. Достъпът до хранилището не променя това, дори самият Jenkins да може да тегли от същото хранилище без проблем. Изберете входяща точка, релей или анкетиране, после проверете пътя, по който събитието наистина минава.

Сесията в браузъра доказва само една посока

VPN връзката отговаря на един въпрос: може ли този лаптоп да достигне вътрешния хост. Доставката на уебхук пита друго: може ли външна услуга да отвори връзка към този хост. Тегленето на хранилище от Jenkins е изходящ трафик и не казва нищо за входящата достъпност. Дръжте двете посоки на отделни линии в диаграмата си, включително коя страна започва всяка от тях.

Прочетете записа за доставка, преди да променяте нещо. Таймаут, нулиране на връзката и приета заявка, която не е съвпаднала с нито една задача, имат трима различни собственици: мрежа, прокси и конфигурация на тригера.

Вариант A: отворете тясна крайна точка

Ако организацията вече публикува одобрена входяща точка, отворете пътя на уебхука вместо таблото за управление. Обикновено това означава правило за обратно прокси, което приема POST заявки на URL адреса на куката и ги препраща към Jenkins, докато административният интерфейс остава недостъпен отвън.

curl -sS -o /dev/null -w "%{http_code}\n" -X POST https://jenkins.example.com/github-webhook/

Изпълнете този тест от мрежа без VPN достъп, защото успех отвътре в тунела не доказва нищо. Крайната точка трябва да отхвърля заявки без споделената тайна, която GitHub изпраща като заглавка за подпис, и да приема само единствения път и метод, които сте публикували. Публичната конзола на Jenkins не е поправка на уебхук; тя е инцидент, който чака следващия скенер. Ограничете правилото достатъчно тясно, така че останалата част от приложението да запази контролите за достъп, които е имало.

Вариант B: обърнете посоката с релей

Когато входящото излагане няма да бъде одобрено, малък клиент вътре в мрежата може да поддържа изходяща връзка към релей и да получава препратени събития. Тогава релеят става част от пътя на доставка, затова наличността и удостоверяването му имат същото значение, както задачата за изграждане.

ssh -N -R 9000:localhost:8080 relay.example.net

Насоките на Jenkins за уебхукове зад защитни стени описват тази схема и си струва да ги прочетете, преди да пишете собствен препращач. Прекратявайте TLS на релея, проверявайте подписа, преди събитието да достигне задачата, и наблюдавайте изходящата връзка, защото прекъснат тунел изглежда точно като събитие, което никога не е било изпратено. Уверете се също, че релеят запазва тялото на заявката байт по байт, тъй като проверките на подписа се провалят при JSON, който е бил анализиран и кодиран отново по пътя.

Вариант C: анкетирайте хранилището вместо това

Анкетирането заменя закъснението с простота и не се нуждае от входящ път. Jenkins може да анкетира по график или малка задача може да запита API и да стартира изграждане, когато види непозната ревизия.

curl -sS -u "$USER:$TOKEN" "https://api.github.com/repos/OWNER/REPO/commits?per_page=1"

Всяко анкетиране изразходва API заявки и добавя закъснение между push и изграждане, което става видимо при натоварени хранилища и споделени ограничения на честотата. То също изисква идентификационни данни, съхранени там, където работи анкетьорът, затова ограничете токена до достъп само за четене на хранилището и го сменяйте като всяка друга тайна. Изберете това, когато обемът на събитията е нисък или когато входяща точка никога няма да бъде одобрена, и го кажете в описанието на задачата, за да не се чуди никой по-късно защо изгражданията изостават.

Приемете истинска доставка, а не зареждане на страница

Който и вариант да изберете, приемният тест е събитие, изпратено от изходната платформа, а не раздел в браузъра, отворен от привилегирован лаптоп. Направете push на празен commit към временен клон и прочетете кода на отговора за доставка, журнала на релея или изхода на анкетната задача, точно в този ред. Отговор 200 от крайната точка без изграждане означава, че филтърът на тригера е грешен; таймаут означава, че пътят все още е затворен. Запишете кой от трите дизайна се използва, защото иначе следващият човек, който отстранява проблема, ще повтори теста в браузъра и ще стигне до същата задънена улица.

Приложете същата логика към плащанията с обратно извикване и другите външни известия: всяко се нуждае от свой маршрут към частното приложение, дори когато всеки човек вече има VPN сесия. Пътят на доставка принадлежи на дизайна на приложението, а не на бележка под линия за мрежата.