Le webhook GitHub n’atteint pas Jenkins privé : corrigez le chemin

Vous pouvez ouvrir Jenkins par le VPN et voir malgré tout GitHub signaler un webhook en échec, car ce sont deux connexions différentes avec deux propriétaires différents. Le navigateur passe par un tunnel que votre portable a négocié ; le service de livraison de GitHub part de l’internet public et n’a aucune route vers le réseau privé. L’accès au dépôt n’y change rien, même si Jenkins lui-même peut récupérer depuis ce même dépôt sans difficulté. Choisissez une entrée, un relais ou l’interrogation, puis testez le chemin que l’événement emprunte réellement.

Une session de navigateur ne prouve qu’un sens

Une connexion VPN répond à une question : cet ordinateur peut-il atteindre l’hôte interne. La livraison de webhook en pose une autre : un service externe peut-il ouvrir une connexion vers cet hôte. Que Jenkins récupère un dépôt relève du trafic sortant et ne dit rien de l’accessibilité entrante. Gardez les deux sens sur des lignes séparées de votre schéma, y compris le côté qui initie chacun.

Lisez l’enregistrement de livraison avant de changer quoi que ce soit. Un délai dépassé, une réinitialisation de connexion et une requête acceptée qui ne correspondait à aucun job ont trois propriétaires différents : le réseau, le proxy et la configuration du déclencheur.

Option A : exposer un point d’entrée étroit

Si l’organisation publie déjà une entrée approuvée, exposez le chemin du webhook plutôt que le tableau de bord. Cela signifie généralement une règle de proxy inverse qui accepte les POST sur l’URL du hook et les transmet à Jenkins, tandis que l’interface d’administration reste injoignable depuis l’extérieur.

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

Exécutez ce test depuis un réseau sans accès VPN, car un succès depuis l’intérieur du tunnel ne prouve rien. Le point d’entrée doit rejeter les requêtes dépourvues du secret partagé, que GitHub envoie comme en-tête de signature, et n’accepter que l’unique chemin et la méthode que vous avez publiés. Une console Jenkins publique n’est pas une correction de webhook ; c’est un incident qui attend le prochain scanner. Cadrez la règle assez étroitement pour que le reste de l’application conserve les contrôles d’accès qu’il avait.

Option B : inverser le sens avec un relais

Là où l’exposition entrante ne sera pas approuvée, un petit client à l’intérieur du réseau peut maintenir une connexion sortante vers un relais et recevoir les événements transmis. Le relais devient alors une partie du chemin de livraison, donc sa disponibilité et son authentification comptent autant que la tâche de build.

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

Les conseils de Jenkins sur les webhooks derrière un pare-feu décrivent cette forme, et il vaut la peine de les lire avant d’écrire votre propre redirecteur. Terminez TLS au relais, vérifiez la signature avant que l’événement n’atteigne le job et surveillez le lien sortant, car un tunnel interrompu ressemble exactement à un événement qui n’a jamais été envoyé. Confirmez aussi que le relais préserve le corps de la requête octet par octet, car les vérifications de signature échouent sur un JSON qui a été analysé et réencodé en chemin.

Option C : interroger le dépôt à la place

L’interrogation échange de la latence contre de la simplicité et ne nécessite aucun chemin entrant. Jenkins peut interroger selon un calendrier, ou un petit job peut consulter l’API et lancer un build lorsqu’il voit une révision inconnue.

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

Chaque interrogation consomme des appels d’API et ajoute un délai entre le push et le build, ce qui devient visible sur les dépôts chargés et les limites de débit partagées. Elle exige aussi des identifiants stockés là où tourne l’interrogateur, alors limitez le jeton à un accès en lecture seule au dépôt et faites-le tourner comme tout autre secret. Choisissez-la quand le volume d’événements est faible ou quand aucune entrée ne sera jamais approuvée, et dites-le dans la description du job pour que personne ne se demande plus tard pourquoi les builds traînent.

Acceptez une vraie livraison, pas un chargement de page

Quelle que soit l’option choisie, le test d’acceptation est un événement envoyé par la plateforme source, pas un onglet de navigateur ouvert depuis un portable privilégié. Poussez un commit vide vers une branche de travail et lisez le code de réponse de la livraison, le journal du relais ou la sortie du job d’interrogation, dans cet ordre. Un 200 du point d’entrée sans build signifie que le filtre du déclencheur est faux ; un délai dépassé signifie que le chemin est toujours fermé. Notez laquelle des trois conceptions est utilisée, sinon la personne suivante qui débogue refera le test du navigateur et aboutira au même cul-de-sac.

Appliquez le même raisonnement aux retours de paiement et aux autres notifications extérieures : chacun a besoin de sa propre route vers l’application privée, même quand chaque personne détient déjà une session VPN. Le chemin de livraison relève de la conception de l’application, pas d’une note de bas de page sur le réseau.