Migliori Pratiche per la Gestione Sicura delle Credenziali in Jenkins

I job Jenkins spesso necessitano di segreti adiacenti alla produzione: token cloud, password di registro, chiavi di deploy, certificati di firma e credenziali API. Se questi segreti finiscono in un Jenkinsfile, log di console o parametro di job, il tuo sistema CI/CD diventa un percorso diretto verso la compromissione.

Utilizza il Plugin Credenziali, mantieni le credenziali con ambito ristretto e iniettarle solo per il passaggio che ne ha bisogno.

Le Fondamenta: Il Plugin Credenziali di Jenkins

Il Plugin Credenziali è il meccanismo standard che Jenkins utilizza per memorizzare dati sensibili. Fornisce un repository centralizzato e crittografato per le credenziali, assicurando che i segreti non vengano mai esposti nei log di build, nel controllo sorgente o nei file di configurazione.

Quando Jenkins memorizza le credenziali, le crittografa utilizzando materiale chiave sul controller Jenkins, inclusi i file sotto JENKINS_HOME/secrets. Chiunque abbia un accesso ampio al filesystem del controller e alla configurazione di Jenkins può potenzialmente recuperare i segreti, quindi l'accesso al filesystem e dell'amministratore deve essere strettamente controllato.

Tipi Chiave di Credenziali

Comprendere i tipi di credenziali disponibili è il primo passo verso un'implementazione sicura. Scegli il tipo che corrisponde più accuratamente al segreto da memorizzare:

Testo Segreto: Utilizzato per valori di testo generici e brevi come token API, chiavi di accesso, token OAuth o segreti di webhook.
Nome Utente e Password: Abbinamento standard utilizzato per l'autenticazione contro servizi come repository Maven, registri privati (Docker Hub, Artifactory) o applicazioni interne.
Nome Utente SSH con Chiave Privata: Essenziale per accedere ad agent remoti, clonare repository Git privati o eseguire comandi su infrastruttura remota. La chiave privata può essere inserita direttamente, fornita come percorso o gestita dal controller Jenkins.
File Segreto: Utilizzato per caricare interi file sensibili, come keystore, certificati (.pem, .crt) o file di configurazione contenenti segreti.

Suggerimento: Utilizza sempre il tipo di credenziale più granulare possibile. Ad esempio, se hai bisogno solo di una chiave API, utilizza Testo Segreto piuttosto che cercare di inserirla in un campo Nome Utente e Password.

Principio del Minimo Privilegio: Ambito delle Credenziali

L'ambito delle credenziali determina dove sono accessibili all'interno dell'ambiente Jenkins. Applicare il principio del minimo privilegio—concedere solo l'accesso necessario per il lavoro—è cruciale.

1. Ambito di Sistema

Le credenziali con ambito di sistema (memorizzate sotto Gestisci Jenkins > Gestisci Credenziali > Jenkins) sono disponibili globalmente a tutti i job, cartelle e pipeline sull'istanza Jenkins.

Utilizzo: Utilizza l'ambito di sistema solo per segreti necessari all'intera operazione di Jenkins, come credenziali utilizzate dai plugin di configurazione globale o segreti necessari per tutte le connessioni degli agent.
Avvertenza: Riduci al minimo l'uso dell'ambito di sistema. Qualsiasi job compromesso potrebbe potenzialmente accedere a tutti i segreti disponibili globalmente.

2. Ambito Cartella

Le credenziali con ambito cartella sono definite all'interno di una cartella specifica (creata utilizzando il plugin Cartella o tramite cartelle di Organizzazione). Questi segreti sono visibili e utilizzabili solo dai job che risiedono in quella cartella e nelle sue sottocartelle.

Raccomandazione: Preferisci sempre l'ambito Cartella. Questo compartimentalizza l'accesso e limita il raggio di esplosione se un progetto viene compromesso.

Iniezione Sicura nelle Pipeline Dichiarative

Non codificare le credenziali negli script della pipeline. Le variabili d'ambiente sono accettabili solo quando Jenkins le inietta per un blocco ristretto e maschera i valori segreti noti nei log.

Il metodo sicuro per accedere alle credenziali in una Pipeline Dichiarativa è utilizzare il passo withCredentials integrato. Questo passo carica la credenziale specificata in una variabile d'ambiente con ambito che è disponibile solo durante l'esecuzione del blocco.

Esempio 1: Iniezione di Testo Segreto (Token API)

Questo esempio recupera in modo sicuro una credenziale di Testo Segreto (MY_API_TOKEN) e assegna il suo valore alla variabile interna SECRET_TOKEN. Una volta che il blocco withCredentials termina, SECRET_TOKEN viene automaticamente rimosso dall'ambiente.

pipeline {
    agent any
    stages {
        stage('Deploy via API') {
            steps {
                script {
                    withCredentials([string(credentialsId: 'MY_API_TOKEN', variable: 'SECRET_TOKEN')]) {
                        sh "echo 'Chiamata API esterna...'"
                        sh '''
                            curl -X POST \
                              -H "Authorization: Bearer $SECRET_TOKEN" \
                              https://api.mycorp.com/deploy
                        '''
                    }
                }
            }
        }
    }
}

Esempio 2: Iniezione di Nome Utente e Password

Quando si utilizzano credenziali di Nome Utente e Password, il passo withCredentials divide il segreto in due variabili: una per il nome utente e una per la password, tipicamente suffissate con _USR e _PSW (o nomi personalizzati).

pipeline {
    agent any
    stages {
        stage('Login al Registro') {
            steps {
                withCredentials([usernamePassword(credentialsId: 'DOCKER_REGISTRY_CRED', usernameVariable: 'DOCKER_USER', passwordVariable: 'DOCKER_PASS')]) {
                    sh '''
                        printf '%s' "$DOCKER_PASS" | docker login \
                          --username "$DOCKER_USER" \
                          --password-stdin my.registry.com
                    '''
                }
            }
        }
    }
}

Avvertenza di Sicurezza: Soppressione dei Log

Jenkins tenta di mascherare i valori delle credenziali noti nei log di build, ma il mascheramento non sostituisce script attenti. Non stampare segreti, passare password sulla riga di comando o eseguire tracciamento della shell (set -x) intorno all'uso dei segreti.

Integrazione di Sicurezza Avanzata

Per ambienti ad alta sicurezza, fare affidamento esclusivamente sulla chiave master locale di Jenkins è spesso insufficiente. Integrarsi con un sistema di gestione dei segreti esterno fornisce separazione delle responsabilità, audit centralizzato e capacità di crittografia migliorate.

Archivi di Credenziali Esterni

Le integrazioni popolari includono:

HashiCorp Vault: Utilizzando il Plugin Vault, Jenkins può richiedere dinamicamente segreti da Vault in fase di esecuzione. Ciò significa che i segreti non vengono mai memorizzati permanentemente sul controller Jenkins, solo temporaneamente in memoria durante la fase di esecuzione.
AWS Secrets Manager/Azure Key Vault: I plugin nativi del cloud consentono alle pipeline di recuperare segreti direttamente da questi servizi utilizzando ruoli IAM o principal di servizio, riducendo al minimo l'esposizione statica delle credenziali.

L'uso di archivi esterni si allinea con le migliori pratiche di sicurezza:

Separazione dell'Archiviazione: L'infrastruttura dei segreti è disaccoppiata dal server CI/CD.
Accesso Dinamico: I segreti possono essere ruotati frequentemente senza richiedere aggiornamenti manuali della configurazione di Jenkins.
Audit Migliorato: Tutti i tentativi di accesso ai segreti vengono registrati all'interno del sistema di vault esterno.

Controllo degli Accessi Basato sui Ruoli (RBAC)

Implementare un plugin RBAC (come la Strategia di Autorizzazione Basata sui Ruoli) consente agli amministratori di controllare non solo chi può eseguire un job ma anche chi può configurare e visualizzare credenziali specifiche.

Limita i permessi di configurazione dei job in modo che solo utenti fidati possano associare credenziali nelle pipeline.
Limita la capacità di modificare o creare credenziali a livello di Sistema a un piccolo gruppo di amministratori di sicurezza o piattaforma.

Migliori Pratiche di Gestione delle Credenziali

Pratica	Descrizione	Beneficio di Sicurezza
Utilizza Ambito Cartella	Limita l'accesso alle credenziali ai job/cartelle specifici che ne hanno bisogno.	Limita l'esposizione e il raggio di esplosione.
Evita la Codifica Fissa	Non inserire mai segreti in `Jenkinsfile`, script di build o controllo sorgente.	Elimina la vulnerabilità del codice sorgente.
Utilizza `withCredentials`	Inietta segreti in modo sicuro nei passi della pipeline utilizzando l'API ufficiale di Jenkins.	Garantisce la redazione automatica dei log e la pulizia dell'ambiente.
Integra Vault Esterno	Utilizza Vault, AWS Secrets Manager o Azure Key Vault per distribuzioni aziendali.	Disaccoppia l'archiviazione e consente la rotazione dinamica.
Applica RBAC	Utilizza plugin di autorizzazione per limitare chi può configurare, visualizzare e utilizzare le credenziali.	Applica il principio del minimo privilegio tra gli utenti.
Rotazione Regolare	Ruota regolarmente chiavi API e password (idealmente automatizzata tramite un vault esterno).	Riduce al minimo la finestra temporale per lo sfruttamento dei segreti compromessi.
Proteggi il Controller	Assicura permessi rigorosi del filesystem sul controller Jenkins per proteggere `master.key`.	Protegge il meccanismo di crittografia principale.

Tratta le credenziali Jenkins come segreti di produzione. Ambiti stretti, legami brevi, rotazione regolare e mantieni l'accesso al controller limitato alle persone autorizzate a recuperare quei segreti.