GitHub-webhook ei tavoita yksityistä Jenkinsiä: korjaa polku

Voit avata Jenkinsin VPN:n yli ja nähdä silti GitHubin raportoivan epäonnistuneesta webhookista, koska kyse on kahdesta eri yhteydestä ja kahdesta eri omistajasta. Selain kulkee tunnelissa, jonka kannettavasi neuvotteli; GitHubin toimitustapalvelu alkaa julkisesta internetistä eikä sillä ole reittiä yksityiseen verkkoon. Repositorion käyttöoikeus ei muuta sitä, vaikka Jenkins itse voisi noutaa samasta repositoriosta ongelmitta. Valitse sisäänkäynti, välitin tai kysely ja testaa sitten polku, jota tapahtuma todella kulkee.

Selainistunto todistaa vain yhden suunnan

VPN-yhteys vastaa yhteen kysymykseen: pääseekö tämä kannettava sisäiseen isäntään. Webhookin toimitus kysyy toista: voiko ulkoinen palvelu avata yhteyden siihen isäntään. Se, että Jenkins noutaa repositoriosta, on lähtevää liikennettä eikä kerro mitään saapuvasta tavoitettavuudesta. Pidä molemmat suunnat erillisillä viivoilla kaaviossasi, mukaan lukien se, kumpi puoli aloittaa kumman.

Lue toimitusmerkintä ennen kuin muutat mitään. Aikakatkaisu, yhteyden nollaus ja hyväksytty pyyntö, joka ei vastannut mitään työtä, kuuluvat kolmelle eri omistajalle: verkko, välityspalvelin ja laukaisimen kokoonpano.

Vaihtoehto A: paljasta kapea päätepiste

Jos organisaatio jo julkaisee hyväksytyn sisäänkäynnin, paljasta webhookin polku hallintapaneelin sijaan. Se tarkoittaa yleensä käänteisen välityspalvelimen sääntöä, joka hyväksyy POST-pyynnöt koukun URL-osoitteeseen ja välittää ne Jenkinsiin, kun taas hallintakäyttöliittymä pysyy ulkopuolelta tavoittamattomana.

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

Suorita testi verkosta, jossa ei ole VPN-yhteyttä, koska menestys tunnelin sisältä ei todista mitään. Päätepisteen tulisi hylätä pyynnöt, joista puuttuu jaettu salaisuus, jonka GitHub lähettää allekirjoitusotsikkona, ja hyväksyä vain se yksi polku ja menetelmä, jotka julkaisit. Julkinen Jenkins-konsoli ei ole webhookin korjaus; se on tapaus, joka odottaa seuraavaa skanneria. Rajaa sääntö riittävän tiukasti, jotta muu sovellus säilyttää aiemmat käyttöoikeuden valvontansa.

Vaihtoehto B: käännä suunta välittimellä

Siellä missä saapuvaa paljastusta ei hyväksytä, pieni asiakasohjelma verkon sisällä voi pitää lähtevän yhteyden välittimeen ja vastaanottaa välitetyt tapahtumat. Välittimestä tulee silloin osa toimituspolkua, joten sen käytettävyys ja todennus ovat yhtä tärkeitä kuin koontityö.

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

Jenkinsin ohjeet palomuurien takana olevista webhookeista kuvaavat tämän muodon, ja ne kannattaa lukea ennen oman välittäjän kirjoittamista. Lopeta TLS välittimessä, vahvista allekirjoitus ennen kuin tapahtuma saapuu työhön ja seuraa lähtevää yhteyttä, koska katkennut tunneli näyttää täsmälleen tapahtumalta, jota ei koskaan lähetetty. Varmista myös, että välitin säilyttää pyynnön rungon tavu tavulta, koska allekirjoituksen tarkistukset epäonnistuvat JSONilla, joka on matkalla jäsennetty ja koodattu uudelleen.

Vaihtoehto C: kysely repositorioon

Kysely vaihtaa viiveen yksinkertaisuuteen eikä tarvitse lainkaan saapuvaa polkua. Jenkins voi kysellä aikataulun mukaan, tai pieni työ voi hakea APIa ja käynnistää koontiversion, kun se näkee tuntemattoman version.

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

Jokainen kysely kuluttaa API-kutsuja ja lisää viivettä pushin ja koontiversion välille, mikä näkyy vilkkaissa repositorioissa ja jaetuissa nopeusrajoissa. Se tarvitsee myös valtuustiedot tallennettuina sinne, missä kyselijä toimii, joten rajaa token vain luku -oikeuteen repositorioon ja kierrätä sitä kuin mitä tahansa muuta salaisuutta. Valitse tämä, kun tapahtumamäärä on pieni tai kun sisäänkäyntiä ei koskaan hyväksytä, ja kerro se työn kuvauksessa, ettei kukaan myöhemmin ihmettele, miksi koontiversiot laahaavat.

Hyväksy todellinen toimitus, älä sivun lataus

Minkä vaihtoehdon valitsitkin, hyväksyntätesti on lähdealustan lähettämä tapahtuma, ei etuoikeutetusta kannettavasta avattu selainvälilehti. Työnnä tyhjä commit väliaikaiseen haaraan ja lue toimituksen vastauskoodi, välittimen loki tai kyselytyön tuloste, juuri siinä järjestyksessä. Vastaus 200 päätepisteestä ilman koontiversiota tarkoittaa, että laukaisimen suodatin on väärä; aikakatkaisu tarkoittaa, että polku on yhä suljettu. Kirjaa, mitä kolmesta mallista käytetään, sillä muuten seuraava vianetsijä toistaa selaintestin ja päätyy samaan umpikujaan.

Sovella samaa logiikkaa maksujen takaisinkutsuihin ja muihin ulkoisiin ilmoituksiin: jokainen tarvitsee oman reittinsä yksityiseen sovellukseen, vaikka jokaisella ihmisellä olisi jo VPN-istunto. Toimituspolku kuuluu sovelluksen suunnitteluun, ei verkkoliitteeseen.