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 è solitamente chiamato JSESSIONID.*. (Un utente può terminare tutte le sue sessioni, ma deve prima scoprire che un cookie è stato rubato).
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 il Jenkins CLI, e i comandi possono essere invocati in questo modo utilizzando qualsiasi client SSH. (Dalla documentazione)
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: Stessa di Jenkins <1.164. Se hai il ruolo "admin", ti verrà concesso il pieno controllo sul sistema, e altrimenti (inclusi gli utenti anonimi) avrai accesso in lettura.
Gli utenti registrati possono fare qualsiasi cosa: In questa modalità, ogni utente registrato ottiene il pieno controllo di Jenkins. L'unico utente che non avrà pieno controllo è l'utente anonimo, che ottiene 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 utenti non autenticati, così come 'autenticato', che rappresenta tutti gli utenti autenticati.
Strategia di autorizzazione basata su progetto: Questa modalità è un'estensione della "sicurezza basata su matrice" che consente di definire matrici ACL aggiuntive per ogni 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 supporto per alcuni reami di sicurezza diversi:
Delegare al contenitore servlet: Per delegare l'autenticazione a un contenitore servlet che esegue il controller Jenkins, come Jetty.
Database utenti di Jenkins: Usa il proprio archivio dati utenti integrato di Jenkins per l'autenticazione invece di delegare a un sistema esterno. Questo è abilitato per impostazione predefinita.
LDAP: Delega tutta l'autenticazione a un server LDAP configurato, inclusi sia utenti che gruppi.
Database utenti/gruppi Unix: Delega l'autenticazione al database utenti a livello di OS Unix 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 in sistemi di identità esistenti, come:
Nodii, Agenti e Esecutori di Jenkins
Definizioni dalla documentazione:
Nodii sono le macchine su cui i client di build vengono eseguiti. 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 disconnesso se uno di questi valori supera la soglia configurata.
Agenti gestiscono l'esecuzione dei compiti per conto del controller Jenkins utilizzando esecutori. Un agente può utilizzare qualsiasi sistema operativo che supporti 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 di compiti; effettivamente, è un thread nell'agente. Il numero di esecutori su un nodo definisce il numero di compiti concorrenti che possono essere eseguiti su quel nodo in un dato momento. In altre parole, questo determina il numero di stages Pipeline concorrenti che possono essere eseguiti su quel nodo in un dato momento.
Segreti di Jenkins
Crittografia di Segreti e Credenziali
Definizione dalla documentazione: 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 master utilizzata per proteggere tali chiavi. Questa directory dovrebbe essere configurata in modo che solo l'utente del sistema operativo con cui viene eseguito 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 "chiave di crittografia" nel gergo crittografico) è memorizzata _non crittografata_ nel 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à di chaining a blocchi di cifratura (CBC) con padding PKCS#5 e IV casuali per crittografare istanze di CryptoConfidentialKey che sono memorizzate in $JENKINS_HOME/secrets/ con un nome di file corrispondente al loro id CryptoConfidentialKey. Gli id di 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 fornitori globali (/credentials/) che possono essere accessibili da qualsiasi progetto configurato, o possono essere scoperte a progetti specifici (/job/<project-name>/configure) e quindi accessibili solo dal progetto specifico.
Secondo la documentazione: Le credenziali che sono in ambito sono rese disponibili alla pipeline senza limitazioni. Per prevenire esposizioni accidentali 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 rivelerebbero le credenziali nel log di build a 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
