Basic Jenkins Information
Accesso
Username + Password
Il modo più comune per accedere a Jenkins è con un username o una password.
Cookie
Se un cookie autorizzato viene rubato, può essere utilizzato per accedere alla sessione dell'utente. Il cookie è solitamente chiamato JSESSIONID.*. (Un utente può terminare tutte le sue sessioni, ma deve prima scoprire che un cookie è stato rubato).
SSO/Plugins
Jenkins può essere configurato utilizzando plugin per essere accessibile tramite SSO di terze parti.
Token
Gli utenti possono generare token per dare accesso alle applicazioni per impersonarli tramite CLI o REST API.
Chiavi SSH
Questo componente fornisce un server SSH integrato per Jenkins. È un'interfaccia alternativa per il Jenkins CLI, e i comandi possono essere invocati in questo modo utilizzando qualsiasi client SSH. (Dai docs)
Autorizzazione
In /configureSecurity è possibile configurare il metodo di autorizzazione di Jenkins. Ci sono diverse opzioni:
Chiunque può fare qualsiasi cosa: Anche l'accesso anonimo può amministrare il server.
Modalità legacy: Come Jenkins <1.164. Se hai il ruolo "admin", ti verrà concesso pieno controllo sul sistema, e altrimenti (inclusi gli utenti anonimi) avrai accesso in lettura.
Gli utenti loggati possono fare qualsiasi cosa: In questa modalità, ogni utente loggato ha pieno controllo di Jenkins. L'unico utente che non avrà pieno controllo è l'utente anonimo, che ha solo accesso in lettura.
Sicurezza basata su matrice: Puoi configurare chi può fare cosa in una tabella. Ogni colonna rappresenta un permesso. Ogni riga rappresenta un utente o un gruppo/ruolo. Questo include un utente speciale 'anonimo', che rappresenta gli utenti non autenticati, così come 'autenticato', che rappresenta tutti gli utenti autenticati.
Strategia di Autorizzazione Basata su Matrice di Progetto: Questa modalità è un'estensione della "sicurezza basata su matrice" che consente di definire una matrice ACL aggiuntiva per ogni progetto separatamente.
Strategia Basata su Ruoli: Consente di definire le autorizzazioni utilizzando una strategia basata su ruoli. Gestisci i ruoli in
/role-strategy.
Security Realm
In /configureSecurity è possibile configurare il security realm. Di default Jenkins include il supporto per alcuni diversi Security Realms:
Delega al contenitore servlet: Per delegare l'autenticazione a un contenitore servlet che esegue il controller Jenkins, come Jetty.
Database utenti di Jenkins: Utilizza il database utenti integrato di Jenkins per l'autenticazione invece di delegare a un sistema esterno. Questo è abilitato di default.
LDAP: Delega tutta l'autenticazione a un server LDAP configurato, inclusi sia gli utenti che i gruppi.
Database utenti/gruppi Unix: Delega l'autenticazione al database utenti a livello di sistema operativo Unix sul controller Jenkins. Questa modalità consente anche il riutilizzo dei gruppi Unix per l'autorizzazione.
I plugin possono fornire ulteriori security realms che possono essere utili per incorporare Jenkins nei sistemi di identità esistenti, come:
Jenkins Nodes, Agents & Executors
Definizioni dai docs:
Nodes sono le macchine su cui girano gli agenti di build. Jenkins monitora ogni nodo collegato per spazio su disco, spazio temporaneo libero, swap libero, tempo/sincronizzazione dell'orologio e tempo di risposta. Un nodo viene messo offline se uno di questi valori supera la soglia configurata.
Agents gestiscono l'esecuzione dei compiti per conto del controller Jenkins utilizzando executors. Un agente può utilizzare qualsiasi sistema operativo che supporti Java. Gli strumenti necessari per le build e i test sono installati sul nodo dove l'agente gira; possono essere installati direttamente o in un container (Docker o Kubernetes). Ogni agente è effettivamente un processo con il proprio PID sulla macchina host.
Un executor è uno slot per l'esecuzione dei compiti; effettivamente, è un thread nell'agente. Il numero di executors su un nodo definisce il numero di compiti concorrenti che possono essere eseguiti su quel nodo contemporaneamente. In altre parole, questo determina il numero di stages di Pipeline concorrenti che possono essere eseguiti su quel nodo contemporaneamente.
Segreti di Jenkins
Crittografia di Segreti e Credenziali
Definizione dai docs: Jenkins utilizza AES per crittografare e proteggere i segreti, le credenziali e le rispettive chiavi di crittografia. Queste chiavi di crittografia sono memorizzate in $JENKINS_HOME/secrets/ insieme alla chiave master utilizzata per proteggere tali chiavi. Questa directory dovrebbe essere configurata in modo che solo l'utente del sistema operativo su cui gira il controller Jenkins abbia accesso in lettura e scrittura a questa directory (cioè, un valore chmod di 0700 o utilizzando attributi di file appropriati). La chiave master (a volte chiamata "key encryption key" nel gergo crittografico) è memorizzata _non crittografata_ sul filesystem del controller Jenkins in $JENKINS_HOME/secrets/master.key che non protegge contro gli attaccanti con accesso diretto a quel file. La maggior parte degli utenti e degli sviluppatori utilizzerà queste chiavi di crittografia indirettamente tramite l'API Secret per crittografare dati segreti generici o tramite l'API delle credenziali. Per i curiosi della crittografia, Jenkins utilizza AES in modalità cipher block chaining (CBC) con padding PKCS#5 e IV casuali per crittografare istanze di CryptoConfidentialKey che sono memorizzate in $JENKINS_HOME/secrets/ con un nome file corrispondente al loro id CryptoConfidentialKey. Gli id chiave comuni includono:
hudson.util.Secret: utilizzato per segreti generici;com.cloudbees.plugins.credentials.SecretBytes.KEY: utilizzato per alcuni tipi di credenziali;jenkins.model.Jenkins.crumbSalt: utilizzato dal meccanismo di protezione CSRF; e
Accesso alle Credenziali
Le credenziali possono essere scopate a provider globali (/credentials/) che possono essere accessibili da qualsiasi progetto configurato, o possono essere scopate a progetti specifici (/job/<project-name>/configure) e quindi accessibili solo dal progetto specifico.
Secondo i docs: Le credenziali che sono in scope sono rese disponibili alla pipeline senza limitazioni. Per prevenire l'esposizione accidentale nel log di build, le credenziali sono mascherate dall'output regolare, quindi un'invocazione di env (Linux) o set (Windows), o programmi che stampano il loro ambiente o parametri non le riveleranno nel log di build agli utenti che altrimenti non avrebbero accesso alle credenziali.
Ecco perché per esfiltrare le credenziali un attaccante deve, per esempio, codificarle in base64.
Riferimenti
Last updated
