Webhook-ul GitHub nu ajunge la Jenkins privat: corectați calea

Puteți deschide Jenkins prin VPN și totuși vedea GitHub raportând un webhook eșuat, pentru că sunt două conexiuni diferite cu doi proprietari diferiți. Browserul călătorește printr-un tunel negociat de laptop; serviciul de livrare al GitHub pornește din internetul public și nu are nicio rută către rețeaua privată. Accesul la depozit nu schimbă asta, chiar dacă Jenkins însuși poate prelua din același depozit fără probleme. Alegeți un punct de intrare, un releu sau interogarea, apoi testați calea pe care evenimentul o urmează de fapt.

O sesiune de browser dovedește o singură direcție

O conexiune VPN răspunde la o întrebare: poate acest laptop să ajungă la gazda internă. Livrarea webhook-urilor întreabă altceva: poate un serviciu extern să deschidă o conexiune către acea gazdă. Faptul că Jenkins preia dintr-un depozit este trafic de ieșire și nu spune nimic despre accesibilitatea de intrare. Țineți ambele direcții pe linii separate în diagramă, inclusiv care parte o inițiază pe fiecare.

Citiți înregistrarea livrării înainte de a schimba ceva. Un timeout, o resetare a conexiunii și o cerere acceptată care nu corespundea niciunei sarcini au trei proprietari diferiți: rețea, proxy și configurația declanșatorului.

Opțiunea A: expuneți un punct de intrare îngust

Dacă organizația publică deja o intrare aprobată, expuneți calea webhook-ului în locul panoului de control. De obicei asta înseamnă o regulă de proxy invers care acceptă POST la URL-ul cârligului și le trimite mai departe către Jenkins, în timp ce interfața de administrare rămâne inaccesibilă din exterior.

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

Rulați acel test dintr-o rețea fără acces VPN, pentru că un succes din interiorul tunelului nu dovedește nimic. Punctul de intrare ar trebui să respingă cererile fără secretul comun, pe care GitHub îl trimite ca antet de semnătură, și să accepte doar singura cale și metoda pe care le-ați publicat. O consolă Jenkins publică nu este o remediere a webhook-ului; este un incident care așteaptă următorul scaner. Limitați regula suficient de strict încât restul aplicației să păstreze controalele de acces pe care le avea.

Opțiunea B: inversați direcția cu un releu

Acolo unde expunerea de intrare nu va fi aprobată, un client mic din interiorul rețelei poate să mențină o conexiune de ieșire către un releu și să primească evenimentele redirecționate. Releul devine atunci parte din calea de livrare, așa că disponibilitatea și autentificarea lui contează la fel de mult ca sarcina de compilare.

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

Îndrumările Jenkins despre webhook-uri din spatele firewall-urilor descriu această formă și merită citite înainte de a scrie propriul redirector. Terminați TLS la releu, verificați semnătura înainte ca evenimentul să ajungă la sarcină și monitorizați legătura de ieșire, pentru că un tunel căzut arată exact ca un eveniment care nu a fost trimis niciodată. Confirmați și că releul păstrează corpul cererii octet cu octet, deoarece verificările de semnătură eșuează la JSON care a fost analizat și recodificat pe parcurs.

Opțiunea C: interogați depozitul

Interogarea schimbă latența pe simplitate și nu are nevoie de nicio cale de intrare. Jenkins poate interoga după un program, sau o sarcină mică poate întreba API-ul și porni o compilare când vede o revizie necunoscută.

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

Fiecare interogare consumă apeluri API și adaugă o întârziere între push și compilare, ceea ce devine vizibil pe depozite aglomerate și la limitele de rată partajate. Are nevoie și de acreditări stocate oriunde rulează interogatorul, așa că limitați tokenul la acces doar pentru citire la depozit și rotiți-l ca pe orice alt secret. Alegeți asta când volumul de evenimente este scăzut sau când nu va fi aprobat niciodată un punct de intrare, și spuneți-o în descrierea sarcinii ca să nu se întrebe nimeni mai târziu de ce compilările întârzie.

Acceptați o livrare reală, nu o încărcare de pagină

Indiferent de opțiunea aleasă, testul de acceptare este un eveniment trimis de platforma sursă, nu o filă de browser deschisă de pe un laptop privilegiat. Trimiteți un commit gol către o ramură de lucru și citiți codul de răspuns al livrării, jurnalul releului sau ieșirea sarcinii de interogare, în această ordine. Un 200 de la punctul de intrare fără compilare înseamnă că filtrul declanșatorului este greșit; un timeout înseamnă că calea este încă închisă. Notați care dintre cele trei modele este folosit, altfel următoarea persoană care depanează va repeta testul din browser și va ajunge în aceeași fundătură.

Aplicați același raționament callback-urilor de plată și altor notificări externe: fiecare are nevoie de propria rută către aplicația privată, chiar și atunci când fiecare om are deja o sesiune VPN. Calea de livrare ține de proiectarea aplicației, nu de o notă de subsol despre rețele.