GitHub-webhook bereik nie private Jenkins nie: herstel die roete

Jy kan Jenkins oor die VPN oopmaak en steeds sien dat GitHub ’n mislukte webhook rapporteer, want dit is twee verskillende verbindings met twee verskillende eienaars. Die blaaier ry op ’n tonnel wat jou skootrekenaar onderhandel het; GitHub se afleweringsdiens begin op die publieke internet en het geen roete na die private netwerk nie. Toegang tot die bewaarplek verander dit nie, selfs al kan Jenkins self sonder moeite uit dieselfde bewaarplek haal. Kies ’n inkompunt, ’n aflos of peiling, en toets dan die roete wat die gebeurtenis werklik volg.

’n Blaaier-sessie bewys net een rigting

’n VPN-verbinding beantwoord een vraag: kan hierdie skootrekenaar die interne gasheer bereik. Webhook-aflewering vra ’n ander een: kan ’n eksterne diens ’n verbinding na daardie gasheer oopmaak. Jenkins wat ’n bewaarplek haal, is uitgaande verkeer en sê niks oor inkomende bereikbaarheid nie. Hou albei rigtings op aparte lyne in jou diagram, insluitend watter kant elkeen begin.

Lees die afleweringsrekord voordat jy enigiets verander. ’n Tydverstrekking, ’n verbinding wat gereset is en ’n aanvaarde versoek wat by geen taak gepas het nie, het drie verskillende eienaars: netwerk, proxy en sneller-opstelling.

Opsie A: stel ’n smal eindpunt bloot

As die organisasie al ’n goedgekeurde inkompunt publiseer, stel die webhook-roete bloot eerder as die paneelbord. Dit beteken gewoonlik ’n omgekeerde-proxy-reël wat POST's op die haak-URL aanvaar en dit na Jenkins aanstuur terwyl die administrasiekoppelvlak van buite onbereikbaar bly.

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

Voer daardie toets uit vanaf ’n netwerk sonder VPN-toegang, want ’n sukses van binne die tonnel bewys niks. Die eindpunt moet versoeke sonder die gedeelde geheim verwerp, wat GitHub as ’n handtekening-opskrif stuur, en dit moet net die enkele roete en metode aanvaar wat jy gepubliseer het. ’n Openbare Jenkins-konsole is nie ’n webhook-oplossing nie; dit is ’n voorval wat wag vir die volgende skandeerder. Beperk die reël styf genoeg dat die res van die toepassing die toegangsbeheer behou wat dit voorheen gehad het.

Opsie B: keer die rigting om met ’n aflos

Waar inkomende blootstelling nie goedgekeur sal word nie, kan ’n klein kliënt binne die netwerk ’n uitgaande verbinding na ’n aflos hou en doorgestuurde gebeurtenisse ontvang. Die aflos word dan deel van die afleweringsroete, so sy beskikbaarheid en verifikasie maak net so saak soos die bou-taak.

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

Jenkins se leiding oor webhooks agter firewalls beskryf hierdie vorm, en dit is die moeite werd om dit te lees voordat jy ’n pasgemaakte aanstuurder skryf. Beëindig TLS by die aflos, verifieer die handtekening voordat die gebeurtenis die taak bereik, en monitor die uitgaande skakel, want ’n tonnel wat val lyk presies soos ’n gebeurtenis wat nooit gestuur is nie. Bevestig ook dat die aflos die versoekliggaam byte vir byte bewaar, want handtekeningkontroles misluk op JSON wat onderweg geparseer en weer geënkodeer is.

Opsie C: peil die bewaarplek eerder

Peiling ruil vertraging vir eenvoud en het glad geen inkomende roete nodig nie. Jenkins kan volgens ’n skedule peil, of ’n klein taak kan die API bevraag en ’n bou begin wanneer dit ’n onbekende weergawe sien.

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

Elke peiling gebruik API-oproepe en voeg ’n vertraging tussen stoot en bou by, wat sigbaar word op besige bewaarplekke en gedeelde tempolimiete. Dit vereis ook geloofsbriewe wat gestoor word waar die peiler ook al loop, so beperk die token tot lees-alleen toegang tot die bewaarplek en draai dit soos enige ander geheim. Kies dit wanneer gebeurtenisvolume laag is of wanneer geen inkompunt ooit goedgekeur sal word nie, en sê so in die taakbeskrywing sodat niemand later wonder waarom boue agterbly nie.

Aanvaar ’n werklike aflewering, nie ’n bladsylading nie

Watter opsie jy ook gekies het, die aanvaardingstoets is ’n gebeurtenis wat deur die bronplatform gestuur is, nie ’n blaaier-oortjie wat van ’n bevoorregte skootrekenaar oopgemaak is nie. Stoot ’n leë commit na ’n krap-tak en lees die afleweringsreaksiekode, die afloslog of die peiltaak se uitset, in daardie volgorde. ’n 200 van die eindpunt sonder ’n bou beteken die snellerfilter is verkeerd; ’n tydverstrekking beteken die roete is steeds toe. Teken aan watter van die drie ontwerpe in gebruik is, want die volgende persoon wat ontfout sal anders die blaaier-toets herhaal en by dieselfde doodloopstraat uitkom.

Pas dieselfde redenasie toe op betalings-terugroepe en ander kennisgewings van buite: elkeen het sy eie roete na die private toepassing nodig, selfs wanneer elke mens al ’n VPN-sessie het. Die afleweringsroete hoort in die toepassing se ontwerp, nie in ’n netwerk-voetnoot nie.