Basic Jenkins Information
Toegang
Gebruikersnaam + Wagwoord
Die mees algemene manier om in Jenkins in te teken is met 'n gebruikersnaam en wagwoord.
Koekie
As 'n geautoriseerde koekie gesteel word, kan dit gebruik word om toegang tot die sessie van die gebruiker te verkry. Die koekie word gewoonlik JSESSIONID.* genoem. ('n Gebruiker kan al sy sessies beëindig, maar hy sal eers moet uitvind dat 'n koekie gesteel is).
SSO/Inproppe
Jenkins kan gekonfigureer word met inproppe om toeganklik te wees via 'n derde party SSO.
Tokens
Gebruikers kan tokens genereer om toegang aan aansoeke te gee om hulle te impersoneer via CLI of REST API.
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 uitgevoer word deur enige SSH-kliënt te gebruik. (Van die dokumente)
Magtiging
In /configureSecurity is dit moontlik om die magtigingsmetode van Jenkins te konfigureer. Daar is verskeie opsies:
Enigiemand kan enigiets doen: Selfs anonieme toegang kan die bediener administreer.
Erfenis-modus: Dieselfde as Jenkins <1.164. As jy die "admin" rol het, sal jy volle beheer oor die stelsel hê, en andersins (insluitend anonieme gebruikers) sal jy leestoegang hê.
Ingelogde gebruikers kan enigiets doen: In hierdie modus kry elke ingelogde gebruiker volle beheer oor Jenkins. Die enigste gebruiker wat nie volle beheer het nie, is die anonieme gebruiker, wat slegs leestoegang kry.
Matriks-gebaseerde sekuriteit: Jy kan konfigureer wie wat kan doen in 'n tabel. Elke kolom verteenwoordig 'n toestemming. Elke ry vertteenwoordig 'n gebruiker of 'n groep/rol. Dit sluit 'n spesiale gebruiker 'anoniem' in, wat ongeautentiseerde gebruikers verteenwoordig, sowel as 'geautentiseer', wat alle geautentiseerde gebruikers verteenwoordig.
Projek-gebaseerde Matriksmagtigingstrategie: Hierdie modus is 'n uitbreiding van "Matriks-gebaseerde sekuriteit" wat toelaat dat addisionele ACL-matriks vir elke projek afsonderlik gedefinieer kan word.
Rolgebaseerde Strategie: Maak dit moontlik om magtigings te definieer met 'n rolgebaseerde strategie. Bestuur die rolle in
/role-strategy.
Sekuriteitsgebied
In /configureSecurity is dit moontlik om die sekuriteitsgebied te konfigureer. Standaard sluit Jenkins ondersteuning in vir 'n paar verskillende Sekuriteitsgebiede:
Delegeer aan bedieningstoepassingkontainer: Vir delegering van outentifisering aan 'n bedieningstoepassingkontainer wat die Jenkins-beheerder uitvoer, soos Jetty.
Jenkins se eie gebruikersdatabasis: Gebruik Jenkins se eie ingeboude gebruikersdatabasis vir outentifisering in plaas van delegeer na 'n eksterne stelsel. Dit is standaard geaktiveer.
LDAP: Delegeer alle outentifisering na 'n gekonfigureerde LDAP-bediener, insluitend beide gebruikers en groepe.
Unix-gebruiker/groepdatabasis: Delegeer die outentifisering na die onderliggende Unix OS-vlak gebruikersdatabasis op die Jenkins-beheerder. Hierdie modus sal ook hergebruik van Unix-groepe vir magtiging toelaat.
Inproppe kan addisionele sekuriteitsgebiede voorsien wat nuttig kan wees vir die inkorporering van Jenkins in bestaande identiteitsisteme, soos:
Jenkins Nodes, Agents & Uitvoerders
Definisies van die dokumente:
Nodes is die rekenaars waarop bou-agente uitgevoer word. Jenkins monitor elke aangehegte node vir skyfspasie, vrye tydelike spasie, vrye swop, kloktyd/sinkronisasie en responstyd. 'n Node word afgehaal as enige van hierdie waardes buite die gekonfigureerde drempel gaan.
Agente bestuur die taakuitvoering namens die Jenkins-beheerder deur uitvoerders te gebruik. 'n Agent kan enige bedryfstelsel wat Java ondersteun, gebruik. Gereedskap benodig vir bou- en toetsdoeleindes word op die node waar die agent uitgevoer word, geïnstalleer; 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-rekenaar.
'n Uitvoerder is 'n gleuf vir die uitvoering van take; effektief is dit 'n draad in die agent. Die aantal uitvoerders op 'n node bepaal die aantal gelyklopende take wat op daardie node op een tyd uitgevoer kan word. Met ander woorde, dit bepaal die aantal gelyklopende Pyplyn stages wat op daardie node op een tyd uitgevoer kan word.
Jenkins Geheime
Versleuteling van Geheime en Gelde
Definisie van die dokumente: Jenkins gebruik AES om geheime, gelde en hul onderskeie versleutelingssleutels te versleutel en beskerm. Hierdie versleutelingssleutels word gestoor in $JENKINS_HOME/secrets/ saam met die meestersleutel wat gebruik word om genoemde sleutels te beskerm. Hierdie gids moet so gekonfigureer word dat slegs die bedryfstelselgebruiker waarop die Jenkins-beheerder uitgevoer word, lees- en skryftoegang tot hierdie gids het (d.w.s., 'n chmod-waarde van 0700 of deur die toepaslike lêereienskappe te gebruik). Die meestersleutel (soms verwys na as 'n "sleutelversleutelingssleutel" in kriptojargon) word ongeversleutel op die Jenkins-beheerder se lêersisteem gestoor 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 versleutelingssleutels indirek gebruik via die Secret API vir die versleuteling van generiese geheime data of deur die gelde API. Vir die kriptonuuskieriges gebruik Jenkins AES in blokketting (CBC) modus met PKCS#5-voltooiing en lukrake IV's om gevalle van CryptoConfidentialKey te versleutel wat in $JENKINS_HOME/secrets/ gestoor word met 'n lêernaam wat ooreenstem met hul CryptoConfidentialKey-id. Gewone sleutel-ID's sluit in:
hudson.util.Secret: gebruik vir generiese geheime;com.cloudbees.plugins.credentials.SecretBytes.KEY: gebruik vir sommige gelde tipes;jenkins.model.Jenkins.crumbSalt: gebruik deur die CSRF-beskermingsmeganisme; en
Verifikasie-inligting
Verifikasie-inligting kan beperk word tot globale verskaffers (/credentials/) wat toeganklik is vir enige gekonfigureerde projek, of kan beperk word tot spesifieke projekte (/job/<project-name>/configure) en dus slegs toeganklik wees vanaf die spesifieke projek.
Volgens die dokumentasie: Verifikasie-inligting wat in bereik is, word beskikbaar gestel aan die pyplyn sonder beperking. Om toevallige blootstelling in die bou-log te voorkom, word verifikasie-inligting gemasker vanaf gewone uitset, sodat 'n aanroep van env (Linux) of set (Windows), of programme wat hul omgewing of parameters druk, dit nie in die bou-log aan gebruikers wat andersins nie toegang tot die verifikasie-inligting het nie.
Dit is waarom 'n aanvaller die verifikasie-inligting moet uitlek, byvoorbeeld deur dit te base64.
Verwysings
Last updated
