Proteggere il tuo server Jenkins: Best Practice Essenziali

Proteggere il tuo server Jenkins è importante perché può accedere al codice sorgente, alle destinazioni di deploy, alle credenziali e agli artefatti di build. Se Jenkins è esposto o configurato in modo lasco, un attaccante potrebbe essere in grado di leggere i repository, alterare le build, rubare segreti o utilizzare gli agenti di build come percorso nella tua rete.

Le configurazioni Jenkins più sicure utilizzano livelli: identità forte, permessi a privilegio minimo, accesso crittografato, gestione attenta dei plugin, pattern di pipeline sicuri e log di audit utili. Inizia con i controlli seguenti prima di esporre Jenkins a un team più ampio o collegarlo a sistemi di produzione.

Gestione degli Utenti e Controllo degli Accessi

Una gestione robusta degli utenti è la prima linea di difesa. Jenkins consente un controllo granulare su ciò che gli utenti possono vedere e fare. Implementare il principio del privilegio minimo garantisce che utenti e servizi abbiano solo i permessi necessari per svolgere i loro compiti, minimizzando il potenziale danno da account compromessi.

Autenticazione

Jenkins può integrarsi con diversi sistemi di autenticazione. Per ambienti di team, utilizza l'autenticazione centralizzata invece di affidarti solo al database utenti interno di Jenkins.

Integrazione LDAP o Active Directory: Utilizza i tuoi gruppi di directory esistenti e i controlli del ciclo di vita degli account.
SAML o OpenID Connect: Utilizza il single sign-on tramite il tuo provider di identità quando il tuo set di plugin Jenkins lo supporta.
Account locali: Tieni un account amministratore di emergenza accuratamente protetto, ma non rendere gli account locali condivisi il tuo modello di accesso normale.

Strategie di Autorizzazione

Una volta che gli utenti sono autenticati, l'autorizzazione determina i loro livelli di accesso.

Sicurezza basata su Matrice: Questa strategia integrata ti consente di assegnare permessi a utenti o gruppi. Funziona bene per configurazioni piccole, ma può diventare difficile da controllare man mano che i team crescono.
Strategia Basata sui Ruoli: Il plugin Role-Based Authorization Strategy ti consente di definire ruoli come Sviluppatore, Operatore e Amministratore, quindi mappare utenti o gruppi a quei ruoli.

Esempio: Impostazione dell'Autorizzazione Basata sui Ruoli

Installa il plugin Role-Based Authorization Strategy dal gestore plugin di Jenkins.
Vai su Gestisci Jenkins > Sicurezza.
Sotto Autorizzazione, seleziona Strategia basata sui ruoli.
Definisci ruoli come sviluppatore, responsabile-rilascio e jenkins-admin.
Dai a ogni ruolo solo i permessi di cui ha bisogno, come Job/Lettura, Job/Build o Credenziali/Visualizzazione.
Assegna gruppi di directory ai ruoli invece che a singole persone quando possibile.

Proteggere la Comunicazione di Jenkins

Garantire che i dati trasmessi da e verso il tuo server Jenkins siano crittografati è cruciale, specialmente quando si ha a che fare con credenziali e informazioni sensibili di build.

Configurazione HTTPS

Configura Jenkins per utilizzare HTTPS per crittografare tutta la comunicazione tra client e server. Questo previene l'intercettazione e gli attacchi man-in-the-middle.

Il pattern di produzione più comune è mettere Jenkins dietro un proxy inverso come Nginx, Apache, HAProxy o un bilanciatore di carico cloud. Termina TLS al proxy, reindirizza HTTP a HTTPS e imposta l'URL pubblico di Jenkins sotto Gestisci Jenkins > Sistema.

Se esegui il server web integrato di Jenkins direttamente con HTTPS, configuralo tramite le opzioni di avvio di Jenkins come --httpsPort, --httpsKeyStore e --httpsKeyStorePassword, o tramite la configurazione del servizio specifica del pacchetto. Il file esatto differisce a seconda del metodo di installazione, quindi controlla come viene avviato il tuo servizio Jenkins prima di modificarlo.

Assicurati anche che il proxy inverso invii le intestazioni inoltrate corrette. Intestazioni proxy errate possono causare URL di reindirizzamento errati, controlli CSRF falliti o collegamenti che puntano di nuovo a HTTP semplice.

Sicurezza di Jenkins e dei Plugin

L'estensibilità di Jenkins tramite plugin è uno dei suoi maggiori punti di forza, ma introduce anche potenziali rischi per la sicurezza se non gestita con attenzione.

Mantieni Jenkins e i Plugin Aggiornati

Le versioni obsolete del core di Jenkins e dei suoi plugin sono una fonte comune di vulnerabilità. Aggiorna regolarmente entrambi per correggere le falle di sicurezza note.

Aggiornamenti del core di Jenkins: Segui gli advisory di sicurezza di Jenkins e pianifica finestre di manutenzione regolari.
Aggiornamenti dei plugin: Controlla spesso le notifiche di aggiornamento. Quando possibile, testa gli aggiornamenti critici dei plugin in un controller non di produzione.

Whitelisting e Audit dei Plugin

Non tutti i plugin sono uguali. Alcuni plugin potrebbero avere vulnerabilità di sicurezza o essere non mantenuti.

Utilizza plugin affidabili: Preferisci plugin mantenuti dal centro aggiornamenti di Jenkins.
Limita l'installazione dei plugin: Ogni plugin aggiunge codice che viene eseguito all'interno del tuo controller.
Rimuovi i plugin inutilizzati: Esegui un audit dei plugin trimestralmente o dopo cambiamenti importanti nei processi.

Gestione degli Avvisi di Sicurezza dei Plugin

Jenkins può avvisarti sui plugin installati con advisory di sicurezza noti. Presta molta attenzione agli avvisi sotto Gestisci Jenkins e aggiorna, sostituisci o rimuovi i plugin interessati.

Sicurezza dei Jenkinsfile

I Jenkinsfile definiscono le tue pipeline di build. Proteggerli è fondamentale per prevenire l'iniezione di codice malevolo nel tuo processo di build.

Archivia i Jenkinsfile nel controllo versione: Rivedi le modifiche alla pipeline allo stesso modo in cui rivedi il codice dell'applicazione.
Tratta il codice della pipeline come codice eseguibile: Un Jenkinsfile può eseguire comandi shell, pubblicare artefatti e richiedere credenziali.
Fai attenzione con l'approvazione degli script: Il plugin Script Security potrebbe richiedere agli amministratori di approvare determinati metodi o script Groovy. Approva solo codice che capisci.
Evita script di pipeline inline nell'interfaccia utente: Preferisci Jenkinsfile basati su repository con revisione del codice.

Esempio: Approvazione degli Script

Quando una pipeline incontra una firma Groovy non approvata, Jenkins la elenca sotto Gestisci Jenkins > Approvazione script in-process. Rivedi la firma richiesta e il job che l'ha attivata prima di approvare. Un'approvazione ampia può influenzare più di un job.

Gestione delle Credenziali di Jenkins

Jenkins spesso deve memorizzare credenziali sensibili come chiavi API, password e chiavi SSH per accedere ad altri servizi. Gestirle in modo sicuro è cruciale.

Utilizza l'archivio credenziali di Jenkins: Memorizza token API, password, certificati e chiavi SSH come credenziali, non come testo semplice nelle definizioni dei job.
Evita segreti hardcoded: Non inserire segreti in Jenkinsfile, script shell, log di build o variabili di repository.
Limita l'ambito delle credenziali: Utilizza cartelle e permessi per tenere le credenziali di produzione lontane dai job che non ne hanno bisogno.
Ruota le credenziali: Ruota le chiavi di deploy e i token di servizio quando le persone lasciano, i job vengono eliminati o un segreto potrebbe essere apparso nei log.

Esempio: Utilizzo delle Credenziali in una Pipeline

pipeline {
    agent any
    stages {
        stage('Deploy') {
            steps {
                withCredentials([sshUserPrivateKey(credentialsId: 'prod-deploy-key', keyFileVariable: 'SSH_KEY', usernameVariable: 'SSH_USER')]) {
                    sh 'ssh -i "$SSH_KEY" -o IdentitiesOnly=yes "[email protected]" "deploy_command"'
                }
            }
        }
    }
}

In questo esempio, prod-deploy-key è l'ID di una credenziale di chiave privata SSH memorizzata. Jenkins scrive la chiave in un file temporaneo per la durata del passaggio e maschera i valori segreti supportati nei log.

Sicurezza di Rete e Controllo degli Accessi

Oltre alla sicurezza interna di Jenkins, proteggere il server a livello di rete è essenziale.

Regole del firewall: Limita l'accesso a Jenkins a reti fidate, intervalli VPN o punti di ingresso proxy con riconoscimento dell'identità.
Controlli del proxy inverso: Utilizza un proxy inverso per TLS, reindirizzamenti HTTP-to-HTTPS, limiti di richiesta e intestazioni coerenti.
Isolamento degli agenti: Non eseguire build non fidate sul controller. Utilizza agenti usa e getta o strettamente controllati per carichi di lavoro rischiosi.
Segmentazione di rete: Tieni Jenkins lontano dall'accesso di rete interno ampio a meno che un job non ne abbia veramente bisogno.

Audit e Monitoraggio

Rivedere regolarmente i log di Jenkins e monitorare l'attività può aiutare a rilevare e rispondere agli incidenti di sicurezza.

Abilita il logging di audit: Registra accessi, modifiche ai permessi, modifiche alle credenziali, modifiche ai job e azioni amministrative. Plugin come Audit Trail possono aiutare.
Monitora i log di Jenkins: Rivedi i log del controller e i log di build per uso inaspettato di credenziali, nuovi account amministratore, modifiche insolite ai job o login falliti ripetuti.
Esegui il backup della configurazione: Esegui il backup della home di Jenkins, della configurazione dei job, delle liste dei plugin e dei metadati delle credenziali secondo il tuo piano di ripristino. Proteggi i backup come i segreti di produzione.

Mantieni Jenkins Noioso

L'obiettivo è un server Jenkins in cui l'accesso è prevedibile, le modifiche sono riviste, i plugin sono conosciuti e le credenziali non trapelano nei job o nei log. Inizia con SSO, ruoli a privilegio minimo, HTTPS, aggiornamenti dei plugin e uso sicuro delle credenziali. Poi pianifica revisioni regolari in modo che l'eccezione temporanea di ieri non diventi l'incidente di domani.