Sécuriser votre serveur Jenkins : bonnes pratiques essentielles

Sécuriser votre serveur Jenkins est important car il peut accéder à votre code source, vos cibles de déploiement, vos identifiants et vos artefacts de build. Si Jenkins est exposé ou mal configuré, un attaquant pourrait lire des dépôts, modifier des builds, voler des secrets ou utiliser des agents de build comme point d'entrée dans votre réseau.

Les configurations Jenkins les plus sûres utilisent plusieurs couches : identité forte, permissions au moindre privilège, accès chiffré, gestion prudente des plugins, modèles de pipeline sécurisés et journaux d'audit utiles. Commencez par les contrôles ci-dessous avant d'exposer Jenkins à une équipe plus large ou de le connecter à des systèmes de production.

Gestion des utilisateurs et contrôle d'accès

Une gestion robuste des utilisateurs est la première ligne de défense. Jenkins permet un contrôle fin de ce que les utilisateurs peuvent voir et faire. L'application du principe du moindre privilège garantit que les utilisateurs et services n'ont que les permissions nécessaires pour effectuer leurs tâches, minimisant ainsi les dommages potentiels en cas de compromission de comptes.

Authentification

Jenkins peut s'intégrer à plusieurs systèmes d'authentification. Pour les environnements d'équipe, utilisez une authentification centralisée plutôt que de vous fier uniquement à la base de données utilisateur interne de Jenkins.

Intégration LDAP ou Active Directory : Utilisez vos groupes d'annuaire existants et les contrôles de cycle de vie des comptes.
SAML ou OpenID Connect : Utilisez l'authentification unique via votre fournisseur d'identité lorsque votre ensemble de plugins Jenkins le prend en charge.
Comptes locaux : Gardez un compte administrateur d'urgence soigneusement protégé, mais ne faites pas des comptes locaux partagés votre modèle d'accès normal.

Stratégies d'autorisation

Une fois les utilisateurs authentifiés, l'autorisation détermine leurs niveaux d'accès.

Sécurité matricielle : Cette stratégie intégrée vous permet d'attribuer des permissions à des utilisateurs ou des groupes. Elle fonctionne bien pour les petites configurations, mais peut devenir difficile à auditer à mesure que les équipes grandissent.
Stratégie basée sur les rôles : Le plugin Role-Based Authorization Strategy vous permet de définir des rôles tels que Développeur, Opérateur et Admin, puis de mapper des utilisateurs ou des groupes à ces rôles.

Exemple : Configuration de l'autorisation basée sur les rôles

Installez le plugin Role-Based Authorization Strategy depuis le gestionnaire de plugins Jenkins.
Allez dans Manage Jenkins > Security.
Sous Authorization, sélectionnez Role-Based Strategy.
Définissez des rôles tels que developpeur, responsable-de-version et jenkins-admin.
Donnez à chaque rôle uniquement les permissions dont il a besoin, comme Job/Read, Job/Build ou Credentials/View.
Assignez des groupes d'annuaire aux rôles plutôt qu'à des personnes individuelles lorsque c'est possible.

Sécurisation des communications Jenkins

Assurer le chiffrement des données transmises vers et depuis votre serveur Jenkins est crucial, surtout lorsqu'il s'agit d'identifiants et d'informations de build sensibles.

Configuration HTTPS

Configurez Jenkins pour utiliser HTTPS afin de chiffrer toutes les communications entre les clients et le serveur. Cela empêche l'écoute clandestine et les attaques de l'homme du milieu.

Le modèle de production le plus courant consiste à placer Jenkins derrière un proxy inverse tel que Nginx, Apache, HAProxy ou un équilibreur de charge cloud. Terminez TLS au niveau du proxy, redirigez HTTP vers HTTPS et définissez l'URL publique de Jenkins sous Manage Jenkins > System.

Si vous exécutez le serveur Web intégré de Jenkins avec HTTPS directement, configurez-le via les options de démarrage de Jenkins telles que --httpsPort, --httpsKeyStore et --httpsKeyStorePassword, ou via la configuration de service spécifique au package. Le fichier exact diffère selon la méthode d'installation, alors vérifiez comment votre service Jenkins est lancé avant de le modifier.

Assurez-vous également que le proxy inverse envoie les en-têtes transférés corrects. Des en-têtes de proxy incorrects peuvent provoquer de mauvaises URL de redirection, des échecs de vérification CSRF ou des liens pointant vers du HTTP simple.

Sécurité de Jenkins et des plugins

L'extensibilité de Jenkins via les plugins est l'un de ses plus grands atouts, mais elle introduit également des risques de sécurité potentiels s'ils ne sont pas gérés avec soin.

Maintenez Jenkins et les plugins à jour

Les versions obsolètes du cœur de Jenkins et de ses plugins sont une source courante de vulnérabilités. Mettez régulièrement à jour les deux pour corriger les failles de sécurité connues.

Mises à jour du cœur de Jenkins : Suivez les avis de sécurité Jenkins et planifiez des fenêtres de maintenance régulières.
Mises à jour des plugins : Examinez souvent les notifications de mise à jour. Testez les mises à jour critiques des plugins dans un contrôleur non productif lorsque vous le pouvez.

Liste blanche et audit des plugins

Tous les plugins ne se valent pas. Certains plugins peuvent avoir des vulnérabilités de sécurité ou ne plus être maintenus.

Utilisez des plugins de confiance : Préférez les plugins maintenus provenant du centre de mise à jour Jenkins.
Limitez l'installation des plugins : Chaque plugin ajoute du code qui s'exécute dans votre contrôleur.
Supprimez les plugins inutilisés : Auditez les plugins trimestriellement ou après des changements majeurs de processus.

Gestion des avertissements de sécurité des plugins

Jenkins peut vous avertir des plugins installés avec des avis de sécurité connus. Portez une attention particulière aux avertissements sous Manage Jenkins et mettez à jour, remplacez ou supprimez les plugins concernés.

Sécurité des Jenkinsfiles

Les Jenkinsfiles définissent vos pipelines de build. Leur sécurisation est essentielle pour empêcher l'injection de code malveillant dans votre processus de build.

Stockez les Jenkinsfiles dans le contrôle de version : Examinez les modifications du pipeline de la même manière que vous examinez le code de l'application.
Traitez le code du pipeline comme du code exécutable : Un Jenkinsfile peut exécuter des commandes shell, publier des artefacts et demander des identifiants.
Soyez prudent avec l'approbation de scripts : Le plugin Script Security peut exiger que les administrateurs approuvent certaines méthodes ou scripts Groovy. N'approuvez que le code que vous comprenez.
Évitez les scripts de pipeline en ligne dans l'interface utilisateur : Préférez les Jenkinsfiles stockés dans un dépôt avec révision de code.

Exemple : Approbation de scripts

Lorsqu'un pipeline rencontre une signature Groovy non approuvée, Jenkins la liste sous Manage Jenkins > In-process Script Approval. Examinez la signature demandée et le travail qui l'a déclenchée avant d'approuver. Une approbation large peut affecter plus d'un travail.

Gestion des identifiants Jenkins

Jenkins a souvent besoin de stocker des identifiants sensibles comme des clés API, des mots de passe et des clés SSH pour accéder à d'autres services. Leur gestion sécurisée est cruciale.

Utilisez le stockage d'identifiants Jenkins : Stockez les jetons API, mots de passe, certificats et clés SSH en tant qu'identifiants, et non en texte brut dans les définitions de travaux.
Évitez les secrets codés en dur : Ne mettez pas de secrets dans les Jenkinsfiles, les scripts shell, les journaux de build ou les variables de dépôt.
Limitez la portée des identifiants : Utilisez des dossiers et des permissions pour éloigner les identifiants de production des travaux qui n'en ont pas besoin.
Rotation des identifiants : Faites pivoter les clés de déploiement et les jetons de service lorsque des personnes partent, des travaux sont supprimés ou qu'un secret a pu apparaître dans les journaux.

Exemple : Utilisation d'identifiants dans un pipeline

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

Dans cet exemple, cle-deploiement-prod est l'ID d'un identifiant de clé SSH privée stockée. Jenkins écrit la clé dans un fichier temporaire pour la durée de l'étape et masque les valeurs de secret prises en charge dans les journaux.

Sécurité réseau et contrôle d'accès

Au-delà de la sécurité interne de Jenkins, la protection du serveur au niveau réseau est essentielle.

Règles de pare-feu : Limitez l'accès Jenkins aux réseaux de confiance, aux plages VPN ou aux points d'entrée de proxy conscients de l'identité.
Contrôles du proxy inverse : Utilisez un proxy inverse pour TLS, les redirections HTTP vers HTTPS, les limites de requêtes et les en-têtes cohérents.
Isolement des agents : N'exécutez pas de builds non fiables sur le contrôleur. Utilisez des agents jetables ou étroitement contrôlés pour les charges de travail risquées.
Segmentation réseau : Éloignez Jenkins de l'accès large au réseau interne, sauf si un travail en a vraiment besoin.

Audit et surveillance

L'examen régulier des journaux Jenkins et la surveillance de l'activité peuvent aider à détecter et à répondre aux incidents de sécurité.

Activez la journalisation d'audit : Enregistrez les connexions, les modifications de permissions, les modifications d'identifiants, les modifications de travaux et les actions administratives. Des plugins comme Audit Trail peuvent aider.
Surveillez les journaux Jenkins : Examinez les journaux du contrôleur et les journaux de build pour détecter une utilisation inattendue d'identifiants, de nouveaux comptes administrateur, des modifications inhabituelles de travaux ou des échecs de connexion répétés.
Sauvegardez la configuration : Sauvegardez le répertoire personnel de Jenkins, la configuration des travaux, les listes de plugins et les métadonnées des identifiants conformément à votre plan de reprise. Protégez les sauvegardes comme des secrets de production.

Gardez Jenkins ennuyeux

L'objectif est un serveur Jenkins où l'accès est prévisible, les modifications sont examinées, les plugins sont connus et les identifiants ne fuient pas dans les travaux ou les journaux. Commencez par le SSO, les rôles au moindre privilège, HTTPS, les mises à jour de plugins et une utilisation sécurisée des identifiants. Planifiez ensuite des examens réguliers pour que l'exception temporaire d'hier ne devienne pas l'incident de demain.