Webhook GitHubu sa nedostane do súkromného Jenkinsu: opravte cestu

Jenkins môžete otvoriť cez VPN a napriek tomu vidieť, ako GitHub hlási neúspešný webhook, pretože ide o dve rôzne spojenia s dvoma rôznymi vlastníkmi. Prehliadač ide tunelom, ktorý vyjednal váš notebook; doručovacia služba GitHubu začína na verejnom internete a nemá trasu do súkromnej siete. Prístup k repozitáru to nemení, aj keď samotný Jenkins môže z toho istého repozitára bez problémov načítavať. Vyberte vstupný bod, relay alebo dopytovanie a potom otestujte cestu, ktorou udalosť skutočne prechádza.

Relácia prehliadača dokazuje len jeden smer

Spojenie VPN odpovedá na jednu otázku: dosiahne tento notebook na interného hostiteľa. Doručenie webhooku sa pýta na iné: môže externá služba otvoriť spojenie k tomu hostiteľovi. To, že Jenkins načítava z repozitára, je odchádzajúca prevádzka a nič nehovorí o dostupnosti zvonku. Držte oba smery na samostatných riadkoch diagramu, vrátane toho, ktorá strana každý z nich začína.

Predtým než čokoľvek zmeníte, prečítajte si záznam o doručení. Vypršanie časového limitu, reset spojenia a prijatá požiadavka, ktorá nezodpovedala žiadnej úlohe, majú troch rôznych vlastníkov: sieť, proxy a konfiguráciu triggera.

Možnosť A: sprístupnite úzky koncový bod

Ak organizácia už zverejňuje schválený vstup, sprístupnite cestu webhooku namiesto ovládacieho panela. Zvyčajne to znamená pravidlo reverznej proxy, ktoré prijíma POST na URL háku a posiela ich do Jenkinsu, zatiaľ čo administračné rozhranie zostáva zvonku nedostupné.

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

Spustite tento test zo siete bez prístupu k VPN, pretože úspech zvnútra tunela nič nedokazuje. Koncový bod by mal odmietať požiadavky bez spoločného tajomstva, ktoré GitHub posiela ako hlavičku podpisu, a prijímať len tú jedinú cestu a metódu, ktorú ste zverejnili. Verejná konzola Jenkinsu nie je oprava webhooku; je to incident, ktorý čaká na ďalší skener. Vymedzte pravidlo dosť úzko, aby zvyšok aplikácie zachoval riadenie prístupu, ktoré mal.

Možnosť B: obráťte smer pomocou relayu

Tam, kde vstupné sprístupnenie nebude schválené, môže malý klient v sieti držať odchádzajúce spojenie k relayu a prijímať preposielané udalosti. Relay sa potom stane súčasťou doručovacej cesty, takže jeho dostupnosť a autentifikácia sú rovnako dôležité ako úloha zostavenia.

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

Pokyny Jenkinsu k webhookom za firewallom opisujú tento tvar a stojí za to si ich prečítať pred písaním vlastného preposielača. Ukončite TLS na relayi, overte podpis skôr, než udalosť dorazí k úlohe, a sledujte odchádzajúce spojenie, pretože spadnutý tunel vyzerá presne ako udalosť, ktorá nebola nikdy odoslaná. Potvrďte tiež, že relay zachováva telo požiadavky bajt po bajte, keďže kontroly podpisu zlyhávajú pri JSON, ktorý bol cestou spracovaný a znovu zakódovaný.

Možnosť C: dopytujte repozitár

Dopytovanie vymieňa latenciu za jednoduchosť a nepotrebuje žiadnu vstupnú cestu. Jenkins môže dopytovať podľa plánu, alebo malá úloha môže zavolať API a spustiť zostavenie, keď uvidí neznámu revíziu.

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

Každé dopytovanie spotrebúva volania API a pridáva oneskorenie medzi push a zostavenie, čo je vidieť na vyťažených repozitároch a pri zdieľaných limitoch rýchlosti. Potrebuje aj prihlasovacie údaje uložené tam, kde dopytovač beží, preto obmedzte token na prístup k repozitáru len na čítanie a otáčajte ho ako každé iné tajomstvo. Zvoľte to vtedy, keď je objem udalostí nízky alebo keď vstupný bod nikdy nebude schválený, a napíšte to do popisu úlohy, aby sa neskôr nikto nečudoval, prečo zostavenia meškajú.

Prijmite skutočné doručenie, nie načítanie stránky

Nech už ste zvolili ktorúkoľvek možnosť, akceptačný test je udalosť odoslaná zdrojovou platformou, nie karta prehliadača otvorená z privilegovaného notebooku. Pošlite prázdny commit do pomocnej vetvy a prečítajte kód odpovede doručenia, záznam relayu alebo výstup dopytovacej úlohy, v tomto poradí. Odpoveď 200 z koncového bodu bez zostavenia znamená, že filter triggera je nesprávny; vypršanie limitu znamená, že cesta je stále zatvorená. Zaznamenajte, ktorý z troch návrhov sa používa, inak ďalší človek, ktorý bude ladiť, zopakuje test v prehliadači a skončí v tej istej slepej uličke.

Rovnakú úvahu použite na platobné callbacky a ďalšie oznámenia zvonku: každé potrebuje vlastnú trasu do súkromnej aplikácie, aj keď každý človek už má reláciu VPN. Doručovacia cesta patrí do návrhu aplikácie, nie do poznámky pod čiarou o sieťach.