Basiese Jenkins Inligting

Toegang

Gebruikersnaam + Wagwoord

Die mees algemene manier om in te log in Jenkins is met 'n gebruikersnaam of 'n wagwoord.

Koekie

As 'n geautoriseerde koekie gesteel word, kan dit gebruik word om toegang tot die gebruiker se sessie te verkry. Die koekie word gewoonlik JSESSIONID.* genoem. (‘n gebruiker kan al sy sessies beëindig, maar hy moet eers uitvind dat 'n koekie gesteel is).

SSO/Plugins

Jenkins kan gekonfigureer word met behulp van plugins om toeganklik te wees via derdeparty SSO.

Tokens

Gebruikers kan tokens genereer om toegang tot toepassings te gee om hulle via CLI of REST API na te boots.

SSH Sleutels

Hierdie komponent bied 'n ingeboude SSH-bediener vir Jenkins. Dit is 'n alternatiewe koppelvlak vir die Jenkins CLI, en opdragte kan op hierdie manier met enige SSH-kliënt aangeroep word. (Van die docs)

Magtiging

In /configureSecurity is dit moontlik om die magtigingsmetode van Jenkins te configureer. Daar is verskeie opsies:

Enige iemand kan enigiets doen: Selfs anonieme toegang kan die bediener administreer.
Erfmodus: Dieselfde as Jenkins <1.164. As jy die "admin" rol het, sal jy volledige beheer oor die stelsel ontvang, en andersins (insluitend anonieme gebruikers) sal jy lees toegang hê.
Aangemelde gebruikers kan enigiets doen: In hierdie modus, elke aangemelde gebruiker kry volledige beheer van Jenkins. Die enigste gebruiker wat nie volledige beheer sal hê nie, is die anonieme gebruiker, wat net lees toegang kry.
Matrix-gebaseerde sekuriteit: Jy kan wie kan wat doen in 'n tabel configureer. Elke kolom verteenwoordig 'n toestemming. Elke ry verteenwoordig 'n gebruiker of 'n groep/rol. Dit sluit 'n spesiale gebruiker 'anoniem' in, wat ongemagtigde gebruikers verteenwoordig, sowel as 'gemagtigde', wat alle gemagtigde gebruikers verteenwoordig.

Projek-gebaseerde Matrix Magtiging Strategie: Hierdie modus is 'n uitbreiding van "Matrix-gebaseerde sekuriteit" wat toelaat dat addisionele ACL-matrix vir elke projek apart gedefinieer word.
Rol-gebaseerde Strategie: Maak dit moontlik om magtigings te definieer met behulp van 'n rol-gebaseerde strategie. Bestuur die rolle in /role-strategy.

Sekuriteitsgebied

In /configureSecurity is dit moontlik om die sekuriteitsgebied te configureer. Standaard sluit Jenkins ondersteuning in vir 'n paar verskillende Sekuriteitsgebiede:

Delegeer aan servlet-container: Vir delegasie van magtiging aan 'n servlet-container wat die Jenkins-beheerder uitvoer, soos Jetty.
Jenkins se eie gebruikersdatabasis: Gebruik Jenkins se eie ingeboude gebruikersdatabasis vir magtiging in plaas van om aan 'n eksterne stelsel te delegeer. Dit is standaard geaktiveer.
LDAP: Delegeer alle magtiging aan 'n geconfigureerde LDAP-bediener, insluitend beide gebruikers en groepe.
Unix gebruikers/groep databasis: Delegeer die magtiging aan die onderliggende Unix OS-vlak gebruikersdatabasis op die Jenkins-beheerder. Hierdie modus sal ook die hergebruik van Unix groepe vir magtiging toelaat.

Plugins kan addisionele sekuriteitsgebiede bied wat nuttig kan wees om Jenkins in bestaande identiteitsisteme in te sluit, soos:

Jenkins Nodes, Agents & Executors

Definisies van die docs:

Nodes is die masjiene waarop bou agents werk. Jenkins monitor elke aangehegte node vir skyfspasie, vrye tydelike ruimte, vrye swap, kloktyd/synk en reaksietyd. 'n Node word vanlyn geneem as enige van hierdie waardes buite die geconfigureerde drempel gaan.

Agents bestuur die taakuitvoering namens die Jenkins-beheerder deur executors te gebruik. 'n agent kan enige bedryfstelsel gebruik wat Java ondersteun. Gereedskap wat benodig word vir bou en toetse word op die node geïnstalleer waar die agent loop; hulle kan direk of in 'n houer (Docker of Kubernetes) geïnstalleer word. Elke agent is effektief 'n proses met sy eie PID op die gasheer masjien.

'n executor is 'n gleuf vir die uitvoering van take; effektief, dit is 'n draad in die agent. Die aantal executors op 'n node definieer die aantal gelyktydige take wat op daardie node op 'n slag uitgevoer kan word. Met ander woorde, dit bepaal die aantal gelyktydige Pipeline stages wat op daardie node op 'n slag kan uitvoer.

Jenkins Geheime

Enkripsie van Geheime en Kredensiale

Definisie van die docs: Jenkins gebruik AES om geheime, kredensiale, en hul onderskeie enkripsiesleutels te enkripteer en te beskerm. Hierdie enkripsiesleutels word in $JENKINS_HOME/secrets/ gestoor saam met die meester sleutel wat gebruik word om genoemde sleutels te beskerm. Hierdie gids moet geconfigureer word sodat slegs die bedryfstelselgebruiker waarvoor die Jenkins-beheerder loop, lees- en skrywe toegang tot hierdie gids het (d.w.s. 'n chmod waarde van 0700 of deur toepaslike lêer eienskappe te gebruik). Die meester sleutel (soms verwys as 'n "sleutel-enkripsiesleutel" in cryptojargon) is gestoor _ongeënkripteer_ op die Jenkins-beheerder se lêerstelsel in $JENKINS_HOME/secrets/master.key wat nie teen aanvallers met direkte toegang tot daardie lêer beskerm nie. Meeste gebruikers en ontwikkelaars sal hierdie enkripsiesleutels indirek gebruik via óf die Secret API vir die enkripsie van generiese geheime data of deur die kredensiale API. Vir die cryptocurious, gebruik Jenkins AES in cipher block chaining (CBC) modus met PKCS#5 padding en willekeurige IV's om voorbeelde van CryptoConfidentialKey te enkripteer wat in $JENKINS_HOME/secrets/ gestoor word met 'n lêernaam wat ooreenstem met hul CryptoConfidentialKey id. Algemene sleutel id's sluit in:

hudson.util.Secret: gebruik vir generiese geheime;
com.cloudbees.plugins.credentials.SecretBytes.KEY: gebruik vir sommige kredensiale tipes;
jenkins.model.Jenkins.crumbSalt: gebruik deur die CSRF beskermingsmeganisme; en

Kredensiale Toegang

Kredensiale kan geskik word vir globale verskaffers (/credentials/) wat deur enige geconfigureerde projek toegang kan verkry, of kan geskik word vir spesifieke projekte (/job/<project-name>/configure) en dus slegs vanaf die spesifieke projek toeganklik wees.

Volgens die docs: Kredensiale wat in die omvang is, word sonder beperking aan die pyplyn beskikbaar gestel. Om per ongeluk blootstelling in die boulog te voorkom, word kredensiale gemasker van gewone uitvoer, sodat 'n aanroep van env (Linux) of set (Windows), of programme wat hul omgewing of parameters druk, nie in die boulog aan gebruikers wat andersins nie toegang tot die kredensiale sou hê nie, onthul word.

Dit is waarom 'n aanvaller, om die kredensiale te ontvoer, byvoorbeeld, hulle in base64 moet kodifiseer.

8.5 KiB Raw Blame History Unescape Escape