A GitHub webhook nem éri el a privát Jenkinst: javítsa az útvonalat

Megnyithatja a Jenkinst a VPN-en keresztül, és mégis láthatja, hogy a GitHub sikertelen webhookot jelent, mert ez két különböző kapcsolat két különböző tulajdonossal. A böngésző egy olyan alagúton halad, amelyet a laptopja egyeztetett; a GitHub kézbesítési szolgáltatása a nyilvános internetről indul, és nincs útvonala a privát hálózatba. Az adattárhoz való hozzáférés ezt nem változtatja meg, még akkor sem, ha a Jenkins maga gond nélkül tud húzni ugyanabból az adattárból. Válasszon bejövő pontot, relét vagy lekérdezést, majd tesztelje azt az útvonalat, amelyet az esemény valóban bejár.

Egy böngésző-munkamenet csak egy irányt bizonyít

A VPN-kapcsolat egy kérdésre válaszol: eléri-e ez a laptop a belső gazdagépet. A webhook kézbesítése másra kérdez: tud-e egy külső szolgáltatás kapcsolatot nyitni ahhoz a gazdagéphez. Az, hogy a Jenkins adattárat húz, kimenő forgalom, és semmit sem mond a bejövő elérhetőségről. Tartsa mindkét irányt külön vonalakon az ábráján, beleértve azt is, melyik fél indítja mindegyiket.

Olvassa el a kézbesítési rekordot, mielőtt bármit módosítana. Az időtúllépés, a kapcsolat visszaállítása és az elfogadott kérés, amely egyetlen feladattal sem egyezett, három különböző tulajdonoshoz tartozik: hálózat, proxy és az indító beállítása.

A lehetőség: szűk végpontot tegyen elérhetővé

Ha a szervezet már közzétesz egy jóváhagyott bejövő pontot, a webhook útvonalát tegye elérhetővé az irányítópult helyett. Ez általában egy fordított proxy szabályt jelent, amely POST kéréseket fogad a hook URL-címén, és továbbítja őket a Jenkinshez, miközben az adminisztrációs felület kívülről elérhetetlen marad.

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

Futtassa ezt a tesztet VPN-hozzáférés nélküli hálózatról, mert az alagúton belüli siker semmit sem bizonyít. A végpontnak el kell utasítania a közös titok nélküli kéréseket, amelyet a GitHub aláírás-fejlécként küld, és csak azt az egyetlen útvonalat és metódust szabad elfogadnia, amelyet közzétett. A nyilvános Jenkins-konzol nem webhook-javítás; ez egy incidens, amely a következő szkennerre vár. Szűkítse a szabályt elég szigorúra ahhoz, hogy az alkalmazás többi része megtartsa a korábbi hozzáférés-vezérléseit.

B lehetőség: fordítsa meg az irányt relével

Ahol a bejövő megnyitást nem fogják jóváhagyni, egy kis kliens a hálózaton belül kimenő kapcsolatot tarthat fenn egy reléhez és fogadhatja a továbbított eseményeket. A relé ekkor a kézbesítési útvonal részévé válik, ezért elérhetősége és hitelesítése ugyanolyan fontos, mint az összeállítási feladat.

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

A Jenkins útmutatása a tűzfalak mögötti webhookokról ezt a formát írja le, és érdemes elolvasni, mielőtt saját továbbítót ír. Fejezze be a TLS-t a relénél, ellenőrizze az aláírást, mielőtt az esemény eléri a feladatot, és figyelje a kimenő kapcsolatot, mert a megszakadt alagút pontosan úgy néz ki, mint egy soha el nem küldött esemény. Azt is erősítse meg, hogy a relé bájtra pontosan megőrzi a kérés törzsét, mert az aláírás-ellenőrzések elbuknak azon a JSON-on, amelyet útközben feldolgoztak és újrakódoltak.

C lehetőség: inkább kérdezze le az adattárat

A lekérdezés késleltetést cserél egyszerűségre, és egyáltalán nem igényel bejövő útvonalat. A Jenkins ütemezés szerint kérdezhet le, vagy egy kis feladat megkérdezheti az API-t, és összeállítást indíthat, amikor ismeretlen revíziót lát.

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

Minden lekérdezés API-hívásokat költ, és késleltetést ad a push és az összeállítás közé, ami forgalmas adattárakon és megosztott sebességkorlátokon láthatóvá válik. Olyan hitelesítő adatokat is igényel, amelyeket ott tárolnak, ahol a lekérdező fut, ezért korlátozza a tokent az adattár csak olvasható elérésére, és forgassa, mint bármely más titkot. Akkor válassza ezt, ha az események száma alacsony, vagy ha soha nem fognak bejövő pontot jóváhagyni, és mondja el a feladat leírásában, hogy később senki ne csodálkozzon, miért késnek az összeállítások.

Valódi kézbesítést fogadjon el, ne oldalbetöltést

Bármelyik lehetőséget választotta, az elfogadási teszt a forrásplatform által küldött esemény, nem egy kiváltságos laptopról megnyitott böngészőlap. Küldjön üres commitot egy ideiglenes ágra, és olvassa el a kézbesítés válaszkódját, a relé naplóját vagy a lekérdező feladat kimenetét, ebben a sorrendben. A végponttól kapott 200 összeállítás nélkül azt jelenti, hogy az indító szűrője hibás; az időtúllépés azt, hogy az útvonal még zárva van. Jegyezze fel, melyik a három terv közül van használatban, különben a következő hibakereső megismétli a böngészős tesztet, és ugyanabba a zsákutcába jut.

Ugyanezt a logikát alkalmazza a fizetési visszahívásokra és más külső értesítésekre: mindegyiknek saját útvonalra van szüksége a privát alkalmazásba, akkor is, ha minden embernek már van VPN-munkamenete. A kézbesítési útvonal az alkalmazás tervezéséhez tartozik, nem egy hálózati lábjegyzethez.