Basic Jenkins Information
Accesso
Nome utente + Password
Il modo più comune per accedere a Jenkins è con un nome utente o una password.
Cookie
Se un cookie autorizzato viene rubato, può essere utilizzato per accedere alla sessione dell'utente. Il cookie è di solito chiamato JSESSIONID.*. (Un utente può terminare tutte le sue sessioni, ma dovrebbe prima scoprire se è stato rubato un cookie).
SSO/Plugin
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 la Jenkins CLI, e i comandi possono essere invocati in questo modo utilizzando qualsiasi client SSH. (Dai documenti)
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à garantito il controllo completo sul sistema, e altrimenti (inclusi gli utenti anonimi) avrai accesso in sola lettura.
Gli utenti loggati possono fare qualsiasi cosa: In questa modalità, ogni utente loggato ottiene il controllo completo di Jenkins. L'unico utente che non avrà il controllo completo è l'utente anonimo, che ottiene solo accesso in sola lettura.
Sicurezza basata su matrice: È possibile 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 utenti non autenticati, così come 'autenticato', che rappresenta tutti gli utenti autenticati.
Strategia di autorizzazione basata su matrice basata su progetto: Questa modalità è un'estensione della "sicurezza basata su matrice" che consente di definire ulteriori matrici ACL per ciascun progetto separatamente.
Strategia basata su ruoli: Consente di definire autorizzazioni utilizzando una strategia basata su ruoli. Gestisci i ruoli in
/role-strategy.
Reame di sicurezza
In /configureSecurity è possibile configurare il reame di sicurezza. Per impostazione predefinita, Jenkins include il supporto per alcuni Reami di Sicurezza diversi:
Delega al contenitore servlet: Per delegare l'autenticazione a un contenitore servlet in esecuzione sul controller Jenkins, come Jetty.
Database utenti di Jenkins: Utilizza il proprio datastore utenti integrato di Jenkins per l'autenticazione anziché delegare a un sistema esterno. Questo è abilitato per impostazione predefinita.
LDAP: Delega tutta l'autenticazione a un server LDAP configurato, inclusi utenti e gruppi.
Database utenti/gruppi Unix: Delega l'autenticazione al database utenti di livello Unix sottostante sul controller Jenkins. Questa modalità consentirà anche il riutilizzo dei gruppi Unix per l'autorizzazione.
I plugin possono fornire ulteriori reami di sicurezza che possono essere utili per incorporare Jenkins nei sistemi di identità esistenti, come:
Nodi, Agenti ed Esecutori di Jenkins
Definizioni dai documenti:
Nodi sono le macchine su cui vengono eseguiti gli agenti di build. Jenkins monitora ogni nodo collegato per lo spazio su disco, lo spazio temporaneo libero, lo swap libero, il tempo/orologio di sincronizzazione e il tempo di risposta. Un nodo viene messo offline se uno qualsiasi di questi valori va al di fuori della soglia configurata.
Agenti gestiscono l'esecuzione dei compiti per conto del controller Jenkins utilizzando esecutori. Un agente può utilizzare qualsiasi sistema operativo che supporta Java. Gli strumenti necessari per le build e i test sono installati sul nodo in cui l'agente viene eseguito; possono essere installati direttamente o in un contenitore (Docker o Kubernetes). Ogni agente è effettivamente un processo con il proprio PID sulla macchina host.
Un esecutore è uno slot per l'esecuzione dei compiti; in pratica, è un thread nell'agente. Il numero di esecutori su un nodo definisce il numero di compiti simultanei che possono essere eseguiti su quel nodo contemporaneamente. In altre parole, questo determina il numero di stages Pipeline simultanei che possono essere eseguiti su quel nodo contemporaneamente.
Segreti di Jenkins
Crittografia di Segreti e Credenziali
Definizione dai documenti: Jenkins utilizza AES per crittografare e proteggere segreti, credenziali e le rispettive chiavi di crittografia. Queste chiavi di crittografia sono memorizzate in $JENKINS_HOME/secrets/ insieme alla chiave principale utilizzata per proteggere tali chiavi. Questa directory dovrebbe essere configurata in modo che solo l'utente del sistema operativo su cui è in esecuzione 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 principale (a volte chiamata "chiave di crittografia chiave" 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 tale file. La maggior parte degli utenti e 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à di cifratura a blocchi in catena (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 limitate ai provider globali (/credentials/) che possono essere accessibili da qualsiasi progetto configurato, oppure possono essere limitate a progetti specifici (/job/<nome-progetto>/configure) e quindi accessibili solo dal progetto specifico.
Secondo la documentazione: Le credenziali che sono nel campo di applicazione sono rese disponibili al pipeline senza limitazioni. Per evitare l'esposizione accidentale nel registro di compilazione, le credenziali sono mascherate dall'output regolare, quindi una chiamata a env (Linux) o set (Windows), o programmi che stampino il loro ambiente o parametri non le riveleranno nel registro di compilazione agli utenti che altrimenti non avrebbero accesso alle credenziali.
Ecco perché per esfiltrare le credenziali un attaccante deve, ad esempio, codificarle in base64.
Riferimenti
Last updated
