Basic Jenkins Information

Access

Username + Password

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

As 'n geautoriseerde koekie gesteel word, kan dit gebruik word om toegang te verkry tot die gebruiker se sessie. 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 geconfigureer word met behulp van plugins om toeganklik te wees via derdeparty SSO.

Tokens

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

SSH Keys

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)

Authorization

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

Enigeen kan enigiets doen: Selfs anonieme toegang kan die bediener administreer.
Legacy mode: 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 wat kan 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 'geverifieerde', wat alle geverifieerde gebruikers verteenwoordig.

Projek-gebaseerde Matrix Autorisasiestrategie: 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 autorisasies te definieer met 'n rol-gebaseerde strategie. Bestuur die rolle in /role-strategy.

Security Realm

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 autentisering aan 'n servlet-container wat die Jenkins-beheerder uitvoer, soos Jetty.
Jenkins se eie gebruikersdatabasis: Gebruik Jenkins se eie ingeboude gebruikersdatastoor vir autentisering in plaas van om aan 'n eksterne stelsel te delegeer. Dit is standaard geaktiveer.
LDAP: Delegeer alle autentisering aan 'n geconfigureerde LDAP-bediener, insluitend beide gebruikers en groepe.
Unix gebruikers/groep databasis: Delegeer die autentisering aan die onderliggende Unix OS-vlak gebruikersdatabasis op die Jenkins-beheerder. Hierdie modus sal ook die hergebruik van Unix-groepe vir autorisasie 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, klok tyd/sink 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 Secrets

Encryption of Secrets and Credentials

Definisie van die docs: Jenkins gebruik AES om geheime, kredensiale, en hul onderskeie versleuteling sleutels te versleutel en te beskerm. Hierdie versleuteling sleutels word gestoor in $JENKINS_HOME/secrets/ saam met die meester sleutel wat gebruik word om genoemde sleutels te beskerm. Hierdie gids moet geconfigureer word sodat slegs die bedryfstelsel gebruiker wat die Jenkins-beheerder uitvoer, 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 versleuteling sleutel" in cryptojargon) is gestoor _onversleuteld_ op die Jenkins-beheerder 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 versleuteling sleutels indirek gebruik via óf die Secret API vir die versleuteling 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 random IVs om voorbeelde van CryptoConfidentialKey te versleutel wat gestoor word in $JENKINS_HOME/secrets/ 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

Credentials Access

Kredensiale kan geskik word vir globale verskaffers (/credentials/) wat deur enige geconfigureerde projek toegang verkry kan word, 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, so 'n aanroep van env (Linux) of set (Windows), of programme wat hul omgewing of parameters druk, sou nie hulle in die boulog onthul nie aan gebruikers wat andersins nie toegang tot die kredensiale sou hê nie.

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

8.5 KiB Raw Blame History Unescape Escape