Webhook GitHuba nie dociera do prywatnego Jenkinsa: napraw ścieżkę

Możesz otworzyć Jenkinsa przez VPN i nadal widzieć, jak GitHub zgłasza nieudany webhook, ponieważ to dwa różne połączenia z dwoma różnymi właścicielami. Przeglądarka jedzie tunelem wynegocjowanym przez laptopa; usługa dostarczania GitHuba zaczyna się w publicznym internecie i nie ma trasy do sieci prywatnej. Dostęp do repozytorium tego nie zmienia, choć sam Jenkins może bez problemu pobierać z tego samego repozytorium. Wybierz punkt wejścia, przekaźnik albo odpytywanie, a potem sprawdź ścieżkę, którą zdarzenie rzeczywiście podąża.

Przeglądarka dowodzi tylko jednego kierunku

Połączenie VPN odpowiada na jedno pytanie: czy ten laptop może dotrzeć do wewnętrznego hosta. Dostarczanie webhooków pyta o co innego: czy usługa zewnętrzna może otworzyć połączenie do tego hosta. To, że Jenkins pobiera z repozytorium, jest ruchem wychodzącym i nic nie mówi o osiągalności przychodzącej. Trzymaj oba kierunki na osobnych liniach diagramu, wraz z informacją, która strona każdy z nich rozpoczyna.

Przeczytaj zapis dostarczenia, zanim cokolwiek zmienisz. Przekroczenie limitu czasu, zerwanie połączenia i przyjęte żądanie, które nie pasowało do żadnego zadania, mają trzech różnych właścicieli: sieć, proxy i konfigurację wyzwalacza.

Opcja A: wystaw wąski punkt końcowy

Jeśli organizacja już publikuje zatwierdzone wejście, wystaw ścieżkę webhooka zamiast panelu. Zwykle oznacza to regułę odwrotnego proxy, która przyjmuje POST-y pod adresem URL haka i przekazuje je do Jenkinsa, podczas gdy interfejs administracyjny pozostaje nieosiągalny z zewnątrz.

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

Wykonaj ten test z sieci bez dostępu do VPN, ponieważ sukces z wnętrza tunelu niczego nie dowodzi. Punkt końcowy powinien odrzucać żądania bez wspólnego sekretu, który GitHub wysyła jako nagłówek podpisu, i przyjmować tylko tę jedną ścieżkę i metodę, które opublikowałeś. Publiczna konsola Jenkinsa nie jest naprawą webhooka; to incydent czekający na następny skaner. Ogranicz regułę wystarczająco wąsko, aby reszta aplikacji zachowała dotychczasowe kontrole dostępu.

Opcja B: odwróć kierunek przekaźnikiem

Tam, gdzie wystawienie na wejściu nie zostanie zatwierdzone, mały klient wewnątrz sieci może utrzymywać połączenie wychodzące do przekaźnika i odbierać przekazywane zdarzenia. Przekaźnik staje się wtedy częścią ścieżki dostarczania, więc jego dostępność i uwierzytelnianie są tak samo ważne jak zadanie budowania.

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

Wskazówki Jenkinsa dotyczące webhooków za zaporą opisują ten kształt i warto je przeczytać, zanim napiszesz własny przekazywacz. Zakończ TLS na przekaźniku, zweryfikuj podpis, zanim zdarzenie dotrze do zadania, i obserwuj łącze wychodzące, ponieważ zerwany tunel wygląda dokładnie jak zdarzenie, które nigdy nie zostało wysłane. Potwierdź też, że przekaźnik zachowuje treść żądania bajt po bajcie, bo kontrole podpisu zawodzą przy JSON, który został po drodze przeanalizowany i ponownie zakodowany.

Opcja C: odpytuj repozytorium

Odpytywanie wymienia opóźnienie na prostotę i wcale nie potrzebuje ścieżki przychodzącej. Jenkins może odpytwać według harmonogramu albo małe zadanie może zapytać API i rozpocząć budowanie, gdy zobaczy nieznaną rewizję.

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

Każde odpytywanie zużywa wywołania API i dodaje opóźnienie między push a budowaniem, co widać w zajętych repozytoriach i przy współdzielonych limitach szybkości. Wymaga też poświadczeń przechowywanych tam, gdzie działa odpytywacz, więc ogranicz token do dostępu tylko do odczytu repozytorium i rotuj go jak każdy inny sekret. Wybierz to, gdy wolumen zdarzeń jest niski albo gdy punkt wejścia nigdy nie zostanie zatwierdzony, i napisz to w opisie zadania, aby nikt później nie dziwił się, dlaczego budowania się opóźniają.

Przyjmij prawdziwe dostarczenie, nie wczytanie strony

Niezależnie od wybranej opcji test akceptacyjny to zdarzenie wysłane przez platformę źródłową, a nie karta przeglądarki otwarta z uprzywilejowanego laptopa. Wypchnij pusty commit do gałęzi roboczej i odczytaj kod odpowiedzi dostarczenia, dziennik przekaźnika albo wynik zadania odpytywania, w tej kolejności. 200 z punktu końcowego bez budowania oznacza, że filtr wyzwalacza jest błędny; przekroczenie limitu czasu oznacza, że ścieżka jest nadal zamknięta. Zanotuj, który z trzech projektów jest używany, bo inaczej następna osoba debugująca powtórzy test w przeglądarce i trafi w tę samą ślepą uliczkę.

Zastosuj to samo rozumowanie do wywołań zwrotnych płatności i innych powiadomień z zewnątrz: każde potrzebuje własnej trasy do prywatnej aplikacji, nawet gdy każdy człowiek ma już sesję VPN. Ścieżka dostarczania należy do projektu aplikacji, a nie do przypisu o sieciach.