Jenkins su Kubernetes: risolvere errori SSL degli agent JNLP con CA privata

Jenkins su Kubernetes: risolvere errori SSL degli agent JNLP con CA privata

Jenkins su Kubernetes: agent JNLP e certificati SSL di una CA privata interna

Uno degli scenari più comuni (e più fastidiosi da debuggare) quando si gestisce Jenkins su Kubernetes è il fallimento dei pod agent JNLP nel momento in cui devono clonare un repository ospitato su un GitLab interno aziendale, protetto da un certificato SSL emesso da una Certificate Authority privata non presente nel trust store di sistema dei container.

Il sintomo

Il job Jenkins parte, il pod agent viene schedulato correttamente nel namespace dedicato (nel mio caso devops-tools), ma la fase di git clone fallisce con errori del tipo “certificate signed by unknown authority” o “SSL certificate problem: unable to get local issuer certificate”. Il pod è raggiungibile, la rete funziona, ma manca la fiducia SSL verso l’endpoint interno.

Perché succede

I container delle immagini standard usate come JNLP agent non includono, ovviamente, la CA privata della tua organizzazione nel bundle di certificati di sistema. Ogni chiamata HTTPS verso servizi interni firmati da quella CA (come il GitLab aziendale) fallisce la verifica del certificato, a meno che non venga esplicitamente iniettata la CA nel container.

La soluzione

L’approccio più pulito e riutilizzabile è:

  • Creare un ConfigMap in Kubernetes contenente il certificato della CA privata (es. ca.crt)
  • Montare quel ConfigMap come volume nel pod template base usato da Jenkins per generare gli agent (via Jenkins Kubernetes plugin, nel pod template YAML)
  • Impostare la variabile d’ambiente GIT_SSL_CAINFO nel container dell’agent, puntando al path montato del certificato, così Git (e curl/wget se serve) sanno dove trovare la CA per validare la connessione

Un dettaglio da non sottovalutare: se Jenkins usa più pod template (ad esempio uno base e diversi “inherited” per specifiche pipeline), il volume mount e la variabile d’ambiente vanno propagati correttamente su tutti i template che devono clonare da endpoint interni, non solo su quello “padre”.

Debug pratico

Per verificare rapidamente se il problema è la CA mancante, un buon test è entrare nel pod agent (quando è ancora vivo, o tramite un pod di debug con la stessa immagine) e lanciare manualmente:

curl -v https://il-tuo-gitlab-interno.aziendale.it

Se l’errore SSL si riproduce da riga di comando, hai la conferma che il problema è a livello di trust store del container e non della pipeline Jenkins in sé.