Basic Jenkins Information
Last updated
Last updated
Ucz się i ćwicz Hacking AWS: Ucz się i ćwicz Hacking GCP:
Najczęstszy sposób logowania do Jenkins to użycie nazwy użytkownika lub hasła.
Jeśli autoryzowane cookie zostanie skradzione, może być użyte do uzyskania dostępu do sesji użytkownika. Cookie zazwyczaj nazywa się JSESSIONID.*
. (Użytkownik może zakończyć wszystkie swoje sesje, ale najpierw musi się dowiedzieć, że cookie zostało skradzione).
Jenkins może być skonfigurowany za pomocą wtyczek, aby być dostępnym przez SSO stron trzecich.
Użytkownicy mogą generować tokeny, aby dać dostęp do aplikacji, aby je imitować za pomocą CLI lub REST API.
W /configureSecurity
można skonfigurować metodę autoryzacji Jenkins. Istnieje kilka opcji:
Każdy może robić cokolwiek: Nawet dostęp anonimowy może administrować serwerem.
Tryb dziedziczony: Tak jak Jenkins <1.164. Jeśli masz rolę "admin", otrzymasz pełną kontrolę nad systemem, a w przeciwnym razie (w tym użytkownicy anonimowi) będziesz miał dostęp do odczytu.
Zalogowani użytkownicy mogą robić cokolwiek: W tym trybie każdy zalogowany użytkownik ma pełną kontrolę nad Jenkins. Jedynym użytkownikiem, który nie będzie miał pełnej kontroli, jest użytkownik anonimowy, który ma tylko dostęp do odczytu.
Bezpieczeństwo oparte na macierzy: Możesz skonfigurować kto może robić co w tabeli. Każda kolumna reprezentuje uprawnienie. Każdy wiersz reprezentuje użytkownika lub grupę/rolę. Obejmuje to specjalnego użytkownika 'anonimowy', który reprezentuje użytkowników nieautoryzowanych, a także 'autoryzowany', który reprezentuje wszystkich użytkowników autoryzowanych.
Strategia autoryzacji oparta na projektach: Ten tryb jest rozszerzeniem do "Bezpieczeństwa opartego na macierzy", które pozwala na zdefiniowanie dodatkowej macierzy ACL dla każdego projektu osobno.
Strategia oparta na rolach: Umożliwia definiowanie autoryzacji za pomocą strategii opartej na rolach. Zarządzaj rolami w /role-strategy
.
W /configureSecurity
można skonfigurować królestwo bezpieczeństwa. Domyślnie Jenkins zawiera wsparcie dla kilku różnych Królestw Bezpieczeństwa:
Własna baza danych użytkowników Jenkins: Użyj wbudowanej bazy danych użytkowników Jenkins do autoryzacji zamiast delegować do zewnętrznego systemu. Jest to włączone domyślnie.
LDAP: Deleguj całą autoryzację do skonfigurowanego serwera LDAP, w tym zarówno użytkowników, jak i grupy.
Baza danych użytkowników/grup Unix: Deleguje autoryzację do podstawowej bazy danych użytkowników Unix na kontrolerze Jenkins. Ten tryb pozwoli również na ponowne wykorzystanie grup Unix do autoryzacji.
Wtyczki mogą zapewnić dodatkowe królestwa bezpieczeństwa, które mogą być przydatne do włączenia Jenkins w istniejące systemy tożsamości, takie jak:
Węzły to maszyny, na których działają agenci budowy. Jenkins monitoruje każdy podłączony węzeł pod kątem miejsca na dysku, wolnego miejsca tymczasowego, wolnej pamięci swap, czasu zegara/synchronizacji i czasu odpowiedzi. Węzeł jest wyłączany, jeśli jakakolwiek z tych wartości przekroczy skonfigurowany próg.
Agenci zarządzają wykonywaniem zadań w imieniu kontrolera Jenkins, używając wykonawców. Agent może używać dowolnego systemu operacyjnego, który obsługuje Javę. Narzędzia wymagane do budowy i testów są instalowane na węźle, na którym działa agent; mogą być zainstalowane bezpośrednio lub w kontenerze (Docker lub Kubernetes). Każdy agent jest w rzeczywistości procesem z własnym PID na maszynie gospodarza.
Wykonawca to slot do wykonywania zadań; w rzeczywistości jest to wątek w agencie. Liczba wykonawców na węźle definiuje liczbę równoległych zadań, które mogą być wykonywane na tym węźle w danym czasie. Innymi słowy, określa to liczbę równoległych stages
Pipeline, które mogą być wykonywane na tym węźle w danym czasie.
hudson.util.Secret
: używany do ogólnych sekretów;
com.cloudbees.plugins.credentials.SecretBytes.KEY
: używany dla niektórych typów poświadczeń;
Poświadczenia mogą być ograniczone do globalnych dostawców (/credentials/
), które mogą być dostępne przez każdy skonfigurowany projekt, lub mogą być ograniczone do konkretnych projektów (/job/<project-name>/configure
) i dlatego dostępne tylko z konkretnego projektu.
Dlatego, aby wyeksportować poświadczenia, atakujący musi na przykład zakodować je w base64.
Ten komponent zapewnia wbudowany serwer SSH dla Jenkins. Jest to alternatywne interfejs dla , a polecenia mogą być wywoływane w ten sposób za pomocą dowolnego klienta SSH. (Z )
Delegowanie do kontenera servletów: Do delegowania autoryzacji do kontenera servletów uruchamiającego kontroler Jenkins, takiego jak .
Definicje z :
Definicja z : Jenkins używa AES do szyfrowania i ochrony sekretów, poświadczeń i ich odpowiednich kluczy szyfrujących. Te klucze szyfrujące są przechowywane w $JENKINS_HOME/secrets/
wraz z kluczem głównym używanym do ochrony tych kluczy. Ten katalog powinien być skonfigurowany tak, aby tylko użytkownik systemu operacyjnego, na którym działa kontroler Jenkins, miał dostęp do odczytu i zapisu do tego katalogu (tj. wartość chmod
wynosząca 0700
lub używając odpowiednich atrybutów plików). Klucz główny (czasami nazywany "kluczem szyfrującym" w kryptografii) jest przechowywany _nieszyfrowany_ w systemie plików kontrolera Jenkins w $JENKINS_HOME/secrets/master.key
, co nie chroni przed atakującymi mającymi bezpośredni dostęp do tego pliku. Większość użytkowników i deweloperów będzie używać tych kluczy szyfrujących pośrednio za pomocą API do szyfrowania ogólnych danych sekretów lub przez API poświadczeń. Dla ciekawskich kryptograficznie, Jenkins używa AES w trybie łańcucha bloków szyfrujących (CBC) z paddingiem PKCS#5 i losowymi IV do szyfrowania instancji , które są przechowywane w $JENKINS_HOME/secrets/
z nazwą pliku odpowiadającą ich identyfikatorowi CryptoConfidentialKey
. Typowe identyfikatory kluczy obejmują:
jenkins.model.Jenkins.crumbSalt
: używany przez ; oraz
Zgodnie z : Poświadczenia, które są w zakresie, są udostępniane potokowi bez ograniczeń. Aby zapobiec przypadkowemu ujawnieniu w logu budowy, poświadczenia są ukrywane przed regularnym wyjściem, więc wywołanie env
(Linux) lub set
(Windows), lub programy drukujące swoje środowisko lub parametry nie ujawnią ich w logu budowy użytkownikom, którzy w przeciwnym razie nie mieliby dostępu do poświadczeń.
Ucz się i ćwicz Hacking AWS: Ucz się i ćwicz Hacking GCP:
Sprawdź !
Dołącz do 💬 lub lub śledź nas na Twitterze 🐦 .
Podziel się sztuczkami hackingowymi, przesyłając PR-y do i repozytoriów na GitHubie.