Webhook GitHubu se nedostane do privátního Jenkins: opravte cestu

Jenkins můžete otevřít přes VPN a přesto vidět, že GitHub hlásí neúspěšný webhook, protože jde o dvě různá spojení se dvěma různými vlastníky. Prohlížeč jede tunelem, který vyjednal váš notebook; doručovací služba GitHubu začíná na veřejném internetu a nemá trasu do privátní sítě. Přístup k repozitáři to nemění, i když samotný Jenkins může z téhož repozitáře bez potíží načítat. Vyberte vstupní bod, relay nebo dotazování a pak otestujte cestu, kterou událost skutečně prochází.

Relace prohlížeče dokazuje jen jeden směr

Spojení VPN odpovídá na jednu otázku: dosáhne tento notebook na interní hostitel. Doručení webhooku se ptá na jinou: může externí služba otevřít spojení k tomu hostiteli. Načítání repozitáře Jenkinsem je odchozí provoz a nic neříká o dostupnosti zvenčí. Držte oba směry na samostatných řádcích svého diagramu, včetně toho, která strana každý z nich zahajuje.

Než něco změníte, přečtěte si záznam o doručení. Vypršení časového limitu, reset spojení a přijatý požadavek, který neodpovídal žádné úloze, mají tři různé vlastníky: síť, proxy a konfiguraci triggeru.

Možnost A: vystavte úzký koncový bod

Pokud organizace už zveřejňuje schválený vstupní bod, vystavte cestu webhooku místo řídicího panelu. Obvykle to znamená pravidlo reverzní proxy, které přijímá POST na URL hooku a předává je Jenkinsi, zatímco administrativní rozhraní zůstává zvenčí nedostupné.

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

Spusťte tento test ze sítě bez přístupu k VPN, protože úspěch zevnitř tunelu nic nedokazuje. Koncový bod má odmítat požadavky bez společného tajemství, které GitHub posílá jako hlavičku podpisu, a přijímat jen tu jedinou cestu a metodu, kterou jste zveřejnili. Veřejná konzole Jenkinse není oprava webhooku; je to incident, který čeká na další skener. Vymezte pravidlo dostatečně úzce, aby zbytek aplikace zachoval řízení přístupu, které měl.

Možnost B: obraťte směr pomocí relaye

Tam, kde vstupní vystavení nebude schváleno, může malý klient uvnitř sítě držet odchozí spojení k relayi a přijímat předávané události. Relay se pak stane součástí doručovací cesty, takže jeho dostupnost a autentizace jsou stejně důležité jako úloha sestavení.

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

Pokyny Jenkinse k webhookům za firewallem popisují tento tvar a stojí za přečtení, než napíšete vlastní přeposílač. Ukončete TLS na relayi, ověřte podpis dřív, než událost dorazí k úloze, a sledujte odchozí spojení, protože spadlý tunel vypadá přesně jako událost, která nebyla nikdy odeslána. Potvrďte také, že relay zachovává tělo požadavku bajt po bajtu, protože kontroly podpisu selhávají u JSON, který byl cestou parsován a znovu zakódován.

Možnost C: dotazujte místo toho repozitář

Dotazování mění latenci za jednoduchost a nepotřebuje vůbec žádnou vstupní cestu. Jenkins může dotazovat podle plánu nebo malá úloha může zavolat API a spustit sestavení, když uvidí neznámou revizi.

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

Každé dotazování spotřebovává volání API a přidává zpoždění mezi push a sestavení, což je vidět na vytížených repozitářích a při sdílených limitech rychlosti. Potřebuje také přihlašovací údaje uložené tam, kde dotazovač běží, takže omezte token na přístup k repozitáři jen pro čtení a otáčejte ho jako každé jiné tajemství. Zvolte to, když je objem událostí nízký nebo když vstupní bod nikdy nebude schválen, a napište to do popisu úlohy, aby se později nikdo nedivil, proč sestavení zaostávají.

Přijměte skutečné doručení, ne načtení stránky

Ať už jste zvolili kteroukoli možnost, akceptační test je událost odeslaná zdrojovou platformou, ne karta prohlížeče otevřená z privilegovaného notebooku. Pošlete prázdný commit do pomocné větve a přečtěte kód odpovědi doručení, záznam relaye nebo výstup dotazovací úlohy, v tomto pořadí. Odpověď 200 z koncového bodu bez sestavení znamená, že filtr triggeru je špatný; vypršení limitu znamená, že cesta je stále zavřená. Zaznamenejte, který ze tří návrhů se používá, protože jinak příští člověk, který bude ladit, zopakuje test v prohlížeči a dojde do stejné slepé uličky.

Stejnou úvahu použijte na platební callbacky a další oznámení zvenčí: každé potřebuje vlastní trasu do privátní aplikace, i když každý člověk už má relaci VPN. Doručovací cesta patří do návrhu aplikace, ne do poznámky pod čarou o síti.