Вэбхук 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 і зборкай, што становіцца прыкметным на занятых рэпазіторыях і пры агульных лімітах хуткасці. Яму таксама патрэбныя ўліковыя даныя, захаваныя там, дзе выконваецца апытальнік, таму абмяжуйце токен доступам толькі на чытанне рэпазіторыя і мяняйце яго, як любы іншы сакрэт. Выбірайце гэта, калі аб’ём падзей нізкі або калі ўваходны пункт ніколі не ўзгодняць, і скажыце пра гэта ў апісанні задачы, каб потым ніхто не здзіўляўся, чаму зборкі спазняюцца.

Прымайце сапраўдную дастаўку, а не загрузку старонкі

Які б варыянт вы ні выбралі, прыёмачны тэст — гэта падзея, дасланая зыходнай платформай, а не ўкладка браўзера, адкрытая з прывілеяванага ноўтбука. Адпраўце пусты каміт у часовую галіну і прачытайце код адказу дастаўкі, журнал рэлея або вывад задачы апытання, менавіта ў такім парадку. Адказ 200 ад кропкі без зборкі азначае, што фільтр трыгера няправільны; таймаўт азначае, што шлях усё яшчэ зачынены. Запішыце, якая з трох схем выкарыстоўваецца, бо інакш наступны чалавек, што будзе адладжваць, паўторыць тэст у браўзеры і трапіць у той жа тупік.

Прымяніце тую ж логіку да плацёжных зваротных выклікаў і іншых знешніх апавяшчэнняў: кожнаму патрэбны свой маршрут у прыватную праграму, нават калі ў кожнага чалавека ўжо ёсць сеанс VPN. Шлях дастаўкі належыць дызайну праграмы, а не зносцы пра сетку.