Basic Jenkins Information
Dostęp
Nazwa użytkownika + Hasło
Najczęstszy sposób logowania do Jenkins to za pomocą nazwy użytkownika lub hasła.
Cookie
Jeśli skradziono autoryzowane cookie, można je wykorzystać do uzyskania dostępu do sesji użytkownika. Cookie zazwyczaj nosi nazwę JSESSIONID.*. (Użytkownik może zakończyć wszystkie swoje sesje, ale najpierw musiałby dowiedzieć się, że cookie zostało skradzione).
SSO/Wtyczki
Jenkins może być skonfigurowany za pomocą wtyczek, aby był dostępny za pośrednictwem zewnętrznego SSO.
Tokeny
Użytkownicy mogą generować tokeny, aby umożliwić aplikacjom podszycie się pod nich za pomocą interfejsu wiersza poleceń (CLI) lub interfejsu API REST.
Klucze SSH
Ten komponent zapewnia wbudowany serwer SSH dla Jenkins. Jest to alternatywny interfejs dla Jenkins CLI, a polecenia można wywoływać w ten sposób za pomocą dowolnego klienta SSH. (Z dokumentacji)
Autoryzacja
W /configureSecurity można skonfigurować metodę autoryzacji Jenkinsa. Istnieje kilka opcji:
Każdy może wszystko: Nawet anonimowy dostęp może zarządzać serwerem.
Tryb dziedziczny: To samo co w Jenkinsie <1.164. Jeśli masz rolę "admin", otrzymasz pełną kontrolę nad systemem, a w przeciwnym razie (w tym użytkownicy anonimowi) uzyskasz dostęp tylko do odczytu.
Zalogowani użytkownicy mogą wszystko: W tym trybie każdy zalogowany użytkownik ma pełną kontrolę nad Jenkins. Jedynym użytkownikiem, który nie ma pełnej kontroli, jest użytkownik anonimowy, który otrzymuje tylko dostęp do odczytu.
Bezpieczeństwo oparte na macierzy: Możesz skonfigurować, kto może co robić w tabeli. Każda kolumna reprezentuje uprawnienie. Każdy wiersz reprezentuje użytkownika lub grupę/rolę. Obejmuje on specjalnego użytkownika 'anonimowego', który reprezentuje nieuwierzytelnionych użytkowników, oraz 'uwierzytelnionego', który reprezentuje wszystkich uwierzytelnionych użytkowników.
Strategia autoryzacji oparta na macierzy projektów: Ten tryb to rozszerzenie do "Bezpieczeństwa opartego na macierzy", które pozwala zdefiniować dodatkową macierz 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.
Dziedzina bezpieczeństwa
W /configureSecurity można skonfigurować dziedzinę bezpieczeństwa. Domyślnie Jenkins zawiera obsługę kilku różnych dziedzin bezpieczeństwa:
Deleguj do kontenera serwletów: Do delegowania uwierzytelniania do kontenera serwletów uruchamiającego kontroler Jenkinsa, takiego jak Jetty.
Własna baza danych użytkowników Jenkinsa: Użyj wbudowanej bazy danych użytkowników Jenkinsa do uwierzytelniania zamiast delegować to do zewnętrznego systemu. Jest to domyślnie włączone.
LDAP: Deleguj całe uwierzytelnianie do skonfigurowanego serwera LDAP, obejmującego zarówno użytkowników, jak i grupy.
Baza danych użytkowników/grup Unix: Deleguje uwierzytelnianie do bazowej bazy danych użytkowników Unix na kontrolerze Jenkinsa. Ten tryb pozwala również na ponowne wykorzystanie grup Unix do autoryzacji.
Wtyczki mogą dostarczać dodatkowe dziedziny bezpieczeństwa, które mogą być przydatne do włączenia Jenkinsa do istniejących systemów tożsamości, takich jak:
Węzły, Agenci i Wykonawcy Jenkinsa
Definicje z dokumentacji:
Węzły to maszyny, na których uruchamiane są agenci budowy. Jenkins monitoruje każdy podłączony węzeł pod kątem miejsca na dysku, wolnego miejsca tymczasowego, wolnej przestrzeni wymiany, czasu/zegara i czasu odpowiedzi. Węzeł jest wyłączany, jeśli któreś z tych wartości przekracza skonfigurowany próg.
Agenci zarządzają wykonaniem zadań w imieniu kontrolera Jenkinsa, korzystając z wykonawców. Agent może korzystać z dowolnego systemu operacyjnego obsługującego 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 efektywnie procesem z własnym PID na maszynie hosta.
Wykonawca to slot do wykonywania zadań; efektywnie jest to wątek w agencie. Liczba wykonawców na węźle określa liczbę równoczesnych zadań, które można wykonać na tym węźle jednocześnie. Innymi słowy, to określa liczbę równoczesnych etapów stages Pipeline, które mogą być wykonywane na tym węźle jednocześnie.
Tajemnice Jenkinsa
Szyfrowanie Tajemnic i Poświadczeń
Definicja z dokumentacji: Jenkins używa AES do szyfrowania i ochrony tajemnic, poświadczeń i ich odpowiednich kluczy szyfrowania. Te klucze szyfrowania są przechowywane w $JENKINS_HOME/secrets/ wraz z głównym kluczem używanym do ochrony tych kluczy. Ten katalog powinien być skonfigurowany tak, aby tylko użytkownik systemu operacyjnego, na którym działa kontroler Jenkinsa, miał dostęp do odczytu i zapisu do tego katalogu (tj. wartość chmod 0700 lub odpowiednie atrybuty pliku). Główny klucz (czasami nazywany "kluczem szyfrowania klucza" w kryptojargonie) jest przechowywany _niezaszyfrowany_ na systemie plików kontrolera Jenkinsa 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 programistów będzie korzystać z tych kluczy szyfrowania pośrednio za pomocą interfejsu API Secret do szyfrowania ogólnych danych tajnych lub za pośrednictwem interfejsu poświadczeń. Dla ciekawych kryptografii, Jenkins używa AES w trybie szyfrowania blokowego łańcuchowego (CBC) z dopełnieniem PKCS#5 i losowymi IV do szyfrowania instancji CryptoConfidentialKey, które są przechowywane w $JENKINS_HOME/secrets/ z nazwą pliku odpowiadającą ich id CryptoConfidentialKey. Wspólne identyfikatory kluczy to:
hudson.util.Secret: używany do ogólnych tajemnic;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; i
Dostęp do poświadczeń
Poświadczenia mogą być ograniczone do globalnych dostawców (/credentials/), które mogą być dostępne dla każdego skonfigurowanego projektu, lub mogą być ograniczone do konkretnych projektów (/job/<project-name>/configure) i tym samym dostępne tylko z konkretnego projektu.
Zgodnie z dokumentacją: Poświadczenia, które są w zasięgu, są udostępniane potoku bez ograniczeń. Aby zapobiec przypadkowemu ujawnieniu w dzienniku budowy, poświadczenia są maskowane z regularnego wyjścia, więc wywołanie env (Linux) lub set (Windows), lub programy drukujące swoje środowisko lub parametry nie ujawnią ich w dzienniku budowy dla użytkowników, którzy w innych przypadkach nie mieliby dostępu do poświadczeń.
Dlatego aby wydobyć poświadczenia, atakujący musi np. zakodować je w base64.
Odnośniki
Last updated
