Basic Jenkins Information
Dostęp
Nazwa użytkownika + Hasło
Najczęstszy sposób logowania do Jenkins to użycie nazwy użytkownika lub hasła.
Cookie
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).
SSO/Wtyczki
Jenkins może być skonfigurowany za pomocą wtyczek, aby być dostępnym przez SSO stron trzecich.
Tokeny
Użytkownicy mogą generować tokeny, aby dać dostęp do aplikacji, aby je imitować za pomocą CLI lub REST API.
Klucze SSH
Ten komponent zapewnia wbudowany serwer SSH dla Jenkins. Jest to alternatywne interfejs dla Jenkins CLI, a polecenia mogą być wywoływane w ten sposób za pomocą dowolnego klienta SSH. (Z dokumentacji)
Autoryzacja
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 samo 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 "bezpieczeństwa opartego na macierzy", które pozwala na definiowanie 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.
Królestwo bezpieczeństwa
W /configureSecurity można skonfigurować królestwo bezpieczeństwa. Domyślnie Jenkins zawiera wsparcie dla kilku różnych Królestw Bezpieczeństwa:
Delegowanie do kontenera servletów: Do delegowania autoryzacji do kontenera servletów uruchamiającego kontroler Jenkins, takiego jak Jetty.
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ą dostarczać 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, agenci i wykonawcy Jenkins
Definicje z dokumentacji:
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 którakolwiek 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ć instalowane 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 miejsce 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 momencie. Innymi słowy, określa to liczbę równoległych stages Pipeline, które mogą być wykonywane na tym węźle w danym momencie.
Sekrety Jenkins
Szyfrowanie sekretów i poświadczeń
Definicja z dokumentacji: 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 Secret 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 CryptoConfidentialKey, które są przechowywane w $JENKINS_HOME/secrets/ z nazwą pliku odpowiadającą ich identyfikatorowi CryptoConfidentialKey. Powszechne identyfikatory kluczy obejmują:
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ń;jenkins.model.Jenkins.crumbSalt: używany przez mechanizm ochrony CSRF; oraz
Dostęp do 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.
Zgodnie z dokumentacją: Poświadczenia, które są w zakresie, są udostępniane potokowi bez ograniczeń. Aby zapobiec przypadkowemu ujawnieniu w dzienniku 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 dzienniku budowy użytkownikom, którzy w przeciwnym razie nie mieliby dostępu do poświadczeń.
Dlatego, aby wyeksportować poświadczenia, atakujący musi na przykład zakodować je w base64.
Odnośniki
Last updated
