GitHubi webhook ei jõua privaatse Jenkinsini: parandage tee

Võite avada Jenkinsi VPN-i kaudu ja näha ikkagi, et GitHub teatab ebaõnnestunud webhookist, sest need on kaks erinevat ühendust kahe erineva omanikuga. Brauser sõidab tunnelis, mille teie sülearvuti läbi rääkis; GitHubi kohaletoimetamisteenus algab avalikust internetist ja sellel pole teed privaatvõrku. Hoidla juurdepääs ei muuda seda, kuigi Jenkins ise võib samast hoidlast probleemideta hankida. Valige sisenemispunkt, relee või küsitlemine ja seejärel testige teed, mida sündmus tegelikult läbib.

Brauseri seanss tõestab ainult üht suunda

VPN-ühendus vastab ühele küsimusele: kas see sülearvuti jõuab sisemise hostini. Webhooki kohaletoimetamine küsib teist: kas välisteenus saab selle hostiga ühenduse avada. See, et Jenkins hankib hoidlast, on väljuv liiklus ega ütle midagi sissetuleva kättesaadavuse kohta. Hoidke mõlemad suunad diagrammil eraldi joontel, sealhulgas see, milline pool igaüht algatab.

Lugege kohaletoimetamise kirjet enne, kui midagi muudate. Aegumine, ühenduse lähtestamine ja vastuvõetud päring, mis ei vastanud ühelegi tööle, on kolme erineva omanikuga: võrk, puhverserver ja päästiku konfiguratsioon.

Valik A: avage kitsas lõpp-punkt

Kui organisatsioon juba avaldab kinnitatud sisenemispunkti, avage webhooki tee, mitte juhtpaneel. Tavaliselt tähendab see pöördpuhverserveri reeglit, mis võtab vastu POST-päringud konksu URL-ile ja edastab need Jenkinsile, samal ajal kui haldusliides jääb väljast kättesaamatuks.

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

Tehke see test võrgust, kus VPN-juurdepääsu pole, sest edu tunnelist seestpoolt ei tõesta midagi. Lõpp-punkt peaks tagasi lükkama päringud, millel puudub jagatud saladus, mille GitHub saadab allkirja päisena, ja võtma vastu ainult selle ühe tee ja meetodi, mille avaldasite. Avalik Jenkinsi konsool ei ole webhooki parandus; see on intsident, mis ootab järgmist skannerit. Piiritlege reegel piisavalt kitsalt, et ülejäänud rakendus säilitaks juurdepääsukontrollid, mis tal olid.

Valik B: pöörake suund releega ümber

Kus sissetulevat avamist ei kinnitata, saab väike klient võrgu sees hoida väljuvat ühendust releega ja vastu võtta edastatud sündmusi. Relee muutub siis kohaletoimetamise tee osaks, seega on selle kättesaadavus ja autentimine sama oluline kui ehitustöö.

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

Jenkinsi juhised tulemüüride taga olevate webhookide kohta kirjeldavad seda kuju ja neid tasub lugeda enne oma edastaja kirjutamist. Lõpetage TLS releel, kontrollige allkirja enne, kui sündmus tööni jõuab, ja jälgige väljuvat linki, sest katkenud tunnel näeb välja täpselt nagu sündmus, mida kunagi ei saadetud. Kinnitage ka, et relee säilitab päringu keha bait-baidilt, sest allkirja kontrollid ebaõnnestuvad JSON-i puhul, mida on teel parsitud ja uuesti kodeeritud.

Valik C: küsitlege selle asemel hoidlat

Küsitlemine vahetab latentsuse lihtsuse vastu ja ei vaja üldse sissetulevat teed. Jenkins saab küsitleda ajakava järgi või väike töö saab API-t pärida ja ehituse käivitada, kui näeb tundmatut revisjoni.

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

Iga küsitlus kulutab API-kutseid ja lisab pushi ning ehituse vahele viivituse, mis muutub nähtavaks hõivatud hoidlates ja jagatud kiiruspiirangutes. See vajab ka volitusi, mis on salvestatud sinna, kus küsitleja töötab, seega piirake luba hoidla kirjutuskaitstud juurdepääsuga ja pöörake seda nagu iga teist saladust. Valige see, kui sündmuste maht on väike või kui sisenemispunkti ei kinnitata kunagi, ja öelge seda töö kirjelduses, et keegi hiljem ei imestaks, miks ehitused hilinevad.

Võtke vastu tõeline kohaletoimetamine, mitte lehe laadimine

Ükskõik millise valiku te tegite, vastuvõtutest on allikaplatvormi saadetud sündmus, mitte privilegeeritud sülearvutist avatud brauseri vahekaart. Lükake tühi commit visandharule ja lugege kohaletoimetamise vastusekoodi, relee logi või küsitlustöö väljundit, just selles järjekorras. Vastus 200 lõpp-punktist ilma ehitusteta tähendab, et päästiku filter on vale; aegumine tähendab, et tee on endiselt suletud. Märkige üles, millist kolmest lahendusest kasutatakse, sest muidu kordab järgmine siluja brauseritesti ja jõuab samasse ummikteesse.

Rakendage sama loogikat maksete tagasikutsetele ja teistele välistele teavitustele: igaüks vajab oma teed privaatsesse rakendusse, isegi kui igal inimesel on juba VPN-seanss. Kohaletoimetamise tee kuulub rakenduse disaini, mitte võrgujoonealuse märkuseni.