El webhook de GitHub no arriba al Jenkins privat: arregleu el camí

Podeu obrir el Jenkins per la VPN i tot i així veure que GitHub informa d’un webhook fallit, perquè són dues connexions diferents amb dos propietaris diferents. El navegador viatja per un túnel que ha negociat l’ordinador; el servei de lliurament de GitHub comença a internet pública i no té cap ruta cap a la xarxa privada. L’accés al repositori no ho canvia, encara que el mateix Jenkins pugui obtenir dades del mateix repositori sense problemes. Trieu un punt d’entrada, un repetidor o l’enquesta, i després proveu el camí que fa realment l’esdeveniment.

Una sessió de navegador només demostra una direcció

Una connexió VPN respon una pregunta: pot aquest ordinador arribar a l’amfitrió intern. El lliurament de webhooks en pregunta una altra: pot un servei extern obrir una connexió amb aquest amfitrió. Que Jenkins obtingui dades d’un repositori és trànsit de sortida i no diu res sobre l’abastida d’entrada. Mantingueu les dues direccions en línies separades del vostre diagrama, incloent-hi quin costat inicia cadascuna.

Llegiu el registre de lliurament abans de canviar res. Un temps d’espera esgotat, un restabliment de connexió i una sol·licitud acceptada que no va coincidir amb cap tasca tenen tres propietaris diferents: xarxa, proxy i configuració del disparador.

Opció A: exposeu un punt d’entrada estret

Si l’organització ja publica un punt d’entrada aprovat, exposeu el camí del webhook en lloc del tauler. Normalment això vol dir una regla de proxy invers que accepta POST a l’URL del hook i els reenvia al Jenkins mentre la interfície d’administració continua sent inabastable des de fora.

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

Executeu aquesta prova des d’una xarxa sense accés VPN, perquè un èxit des de dins del túnel no demostra res. El punt d’entrada hauria de rebutjar les sol·licituds que no portin el secret compartit, que GitHub envia com a capçalera de signatura, i hauria d’acceptar només l’únic camí i mètode que heu publicat. Una consola de Jenkins pública no és una solució per al webhook; és un incident esperant el proper escàner. Limiteu la regla prou estretament perquè la resta de l’aplicació conservi els controls d’accés que tenia.

Opció B: invertiu la direcció amb un repetidor

On no s’aprovarà l’exposició d’entrada, un client petit dins de la xarxa pot mantenir una connexió de sortida amb un repetidor i rebre els esdeveniments reenviats. El repetidor passa llavors a formar part del camí de lliurament, així que la seva disponibilitat i autenticació importen tant com la tasca de compilació.

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

La guia del Jenkins sobre webhooks darrere de tallafocs descriu aquesta forma, i val la pena llegir-la abans d’escriure un reenviador propi. Acabeu el TLS al repetidor, verifiqueu la signatura abans que l’esdeveniment arribi a la tasca i vigileu l’enllaç de sortida, perquè un túnel caigut sembla exactament un esdeveniment que no s’ha enviat mai. Confirmeu també que el repetidor conserva el cos de la sol·licitud byte a byte, ja que les comprovacions de signatura fallen amb JSON que s’ha analitzat i tornat a codificar pel camí.

Opció C: enquesteu el repositori

L’enquesta canvia latència per simplicitat i no necessita cap camí d’entrada. Jenkins pot enquestar segons una planificació, o una tasca petita pot consultar l’API i iniciar una compilació quan veu una revisió desconeguda.

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

Cada enquesta gasta crides a l’API i afegeix un retard entre el push i la compilació, cosa que es nota en repositoris amb molta activitat i en límits de velocitat compartits. També necessita credencials desades allà on s’executi l’enquestador, així que limiteu el testimoni a accés de només lectura al repositori i renoveu-lo com qualsevol altre secret. Trieu-ho quan el volum d’esdeveniments sigui baix o quan no s’hagi d’aprovar mai cap punt d’entrada, i digueu-ho a la descripció de la tasca perquè ningú no es pregunti més endavant per què les compilacions van endarrerides.

Accepteu un lliurament real, no una càrrega de pàgina

Tant se val quina opció hàgiu triat: la prova d’acceptació és un esdeveniment enviat per la plataforma d’origen, no una pestanya del navegador oberta des d’un ordinador amb privilegis. Feu un push d’una confirmació buida a una branca temporal i llegiu el codi de resposta del lliurament, el registre del repetidor o la sortida de la tasca d’enquesta, en aquest ordre. Un 200 del punt d’entrada sense compilació vol dir que el filtre del disparador és incorrecte; un temps d’espera vol dir que el camí encara és tancat. Anoteu quin dels tres dissenys s’utilitza, perquè altrament la propera persona que depuri repetirà la prova del navegador i arribarà al mateix carreró sense sortida.

Apliqueu el mateix raonament a les devolucions de pagament i a altres notificacions externes: cadascuna necessita la seva pròpia ruta cap a l’aplicació privada, fins i tot quan tothom ja té una sessió VPN. El camí de lliurament pertany al disseny de l’aplicació, no a una nota al peu sobre xarxes.