GitHub webhook ne može dosegnuti privatni Jenkins: popravite putanju
VPN sesija na vašem laptopu ne daje GitHubu putanju do Jenkinsa. Uporedite ulaznu točku, relej i anketiranje, pa testirajte putanju kojom idu događaji.
Možete otvoriti Jenkins preko VPN-a i ipak vidjeti da GitHub prijavljuje neuspjeli webhook, jer su to dvije različite veze s dva različita vlasnika. Preglednik se vozi kroz tunel koji je pregovarao vaš laptop; GitHubova usluga dostave počinje na javnom internetu i nema putanju u privatnu mrežu. Pristup repozitoriju to ne mijenja, iako sam Jenkins može bez problema dohvaćati iz istog repozitorija. Odaberite ulaznu točku, relej ili anketiranje, pa testirajte putanju kojom događaj zaista prolazi.
Sesija preglednika dokazuje samo jedan smjer
VPN veza odgovara na jedno pitanje: može li ovaj laptop dosegnuti unutrašnji host. Dostava webhooka pita drugo: može li vanjska usluga otvoriti vezu prema tom hostu. Jenkinsovo dohvaćanje repozitorija je odlazni promet i ne govori ništa o dolaznoj dostupnosti. Držite oba smjera na odvojenim linijama svoje skice, uključujući i to koja strana započinje svaki.
Pročitajte zapis o dostavi prije nego što bilo šta promijenite. Istek vremena, prekid veze i prihvaćen zahtjev koji nije odgovarao nijednom poslu imaju tri različita vlasnika: mrežu, proxy i konfiguraciju okidača.
Opcija A: izložite usku ulaznu točku
Ako organizacija već objavljuje odobrenu ulaznu točku, izložite putanju webhooka umjesto nadzorne ploče. To obično znači pravilo obrnutog proxyja koje prihvaća POST zahtjeve na URL kuke i prosljeđuje ih Jenkinsu, dok administracijsko sučelje ostaje nedostupno izvana.
curl -sS -o /dev/null -w "%{http_code}\n" -X POST https://jenkins.example.com/github-webhook/Izvedite taj test s mreže bez VPN pristupa, jer uspjeh iz unutrašnjosti tunela ništa ne dokazuje. Ulazna točka treba odbijati zahtjeve bez zajedničke tajne, koju GitHub šalje kao zaglavlje potpisa, i prihvaćati samo jedinu putanju i metodu koju ste objavili. Javna Jenkins konzola nije popravka webhooka; to je incident koji čeka sljedeći skener. Ograničite pravilo dovoljno usko da ostatak aplikacije zadrži kontrole pristupa koje je imao.
Opcija B: obrnite smjer pomoću releja
Tamo gdje dolazno izlaganje neće biti odobreno, mali klijent unutar mreže može držati odlaznu vezu prema releju i primati proslijeđene događaje. Relej tada postaje dio putanje dostave, pa su njegova dostupnost i autentifikacija jednako važne kao i posao izgradnje.
ssh -N -R 9000:localhost:8080 relay.example.netJenkinsove smjernice o webhookovima iza vatrozida opisuju ovaj oblik i vrijedi ih pročitati prije pisanja vlastitog prosljeđivača. Prekinite TLS na releju, provjerite potpis prije nego događaj stigne do posla i nadzirite odlaznu vezu, jer prekinuti tunel izgleda isto kao događaj koji nikada nije poslan. Potvrdite i da relej čuva tijelo zahtjeva bajt po bajt, jer provjere potpisa padaju na JSON-u koji je usput parsiran i ponovno kodiran.
Opcija C: umjesto toga anketirajte repozitorij
Anketiranje mijenja latenciju za jednostavnost i uopće ne treba dolaznu putanju. Jenkins može anketirati po rasporedu, ili mali posao može upitati API i pokrenuti izgradnju kada vidi nepoznatu reviziju.
curl -sS -u "$USER:$TOKEN" "https://api.github.com/repos/OWNER/REPO/commits?per_page=1"Svako anketiranje troši API pozive i dodaje kašnjenje između pusha i izgradnje, što postaje vidljivo na zauzetim repozitorijima i zajedničkim ograničenjima brzine. Treba i vjerodajnice pohranjene gdje god anketar radi, pa ograničite token na pristup repozitoriju samo za čitanje i rotirajte ga kao svaku drugu tajnu. Odaberite to kada je obim događaja nizak ili kada ulazna točka nikada neće biti odobrena, i navedite to u opisu posla da se kasnije niko ne pita zašto izgradnje kasne.
Prihvatite stvarnu dostavu, a ne učitavanje stranice
Koju god opciju odabrali, prihvatni test je događaj koji je poslala izvorna platforma, a ne kartica preglednika otvorena s privilegovanog laptopa. Pošaljite prazan commit na privremenu granu i pročitajte kôd odgovora dostave, zapisnik releja ili izlaz anketnog posla, tim redom. Odgovor 200 s ulazne točke bez izgradnje znači da je filtar okidača pogrešan; istek vremena znači da je putanja još zatvorena. Zapišite koji se od tri dizajna koristi, jer će u suprotnom sljedeća osoba koja otklanja grešku ponoviti test u pregledniku i doći do istog ćorsokaka.
Primijenite isto razmišljanje na povratne pozive plaćanja i druge vanjske obavijesti: svaki treba svoju putanju u privatnu aplikaciju, čak i kada svaki čovjek već ima VPN sesiju. Putanja dostave pripada dizajnu aplikacije, a ne fusnoti o mreži.