Meilleures pratiques pour la gestion sécurisée des informations d'identification Jenkins

Jenkins sert de système nerveux central pour l'intégration continue et le déploiement continu (CI/CD), nécessitant souvent un accès à des ressources hautement sensibles, notamment des bases de données de production, des API cloud, des référentiels d'artefacts et une infrastructure sécurisée. La gestion appropriée des secrets nécessaires à ces opérations — mots de passe, clés API et clés SSH privées — est primordiale pour maintenir la sécurité et l'intégrité de votre pipeline de déploiement.

Une mauvaise gestion des informations d'identification, telle que le codage source des secrets directement dans les scripts de pipeline ou leur stockage en texte clair, constitue une vulnérabilité de sécurité importante. Ce guide détaille les stratégies essentielles et les meilleures pratiques architecturales pour utiliser le plugin intégré Jenkins Credentials Plugin et intégrer des contrôles de sécurité avancés afin de garantir que vos données sensibles restent protégées.

La Fondation : Le Plugin Credentials de Jenkins

Le Credentials Plugin est le mécanisme standard que Jenkins utilise pour stocker les données sensibles. Il fournit un référentiel crypté et centralisé pour les informations d'identification, garantissant que les secrets ne sont jamais exposés dans les journaux de construction, le contrôle de source ou les fichiers de configuration.

Lorsque Jenkins stocke des informations d'identification, celles-ci sont chiffrées à l'aide de l'extension Java Cryptography Extension (JCE). Ce chiffrement est lié à un fichier master.key unique stocké sur le contrôleur Jenkins. Cette architecture signifie que l'accès au système de fichiers du contrôleur doit être rigoureusement contrôlé.

Types d'informations d'identification clés

Comprendre les types d'informations d'identification disponibles est la première étape vers une mise en œuvre sécurisée. Choisissez le type qui correspond le plus précisément au secret stocké :

1. Texte Secret (Secret Text) : Utilisé pour les valeurs textuelles courtes et génériques telles que les jetons d'API, les clés d'accès, les jetons OAuth ou les secrets de webhooks.
2. Nom d'utilisateur et Mot de passe (Username and Password) : Association standard utilisée pour l'authentification auprès de services tels que les référentiels Maven, les registres privés (Docker Hub, Artifactory) ou les applications internes.
3. Nom d'utilisateur SSH avec clé privée (SSH Username with Private Key) : Essentiel pour accéder aux agents distants, cloner des référentiels Git privés ou exécuter des commandes sur une infrastructure distante. La clé privée peut être saisie directement, fournie sous forme de chemin ou gérée par le contrôleur Jenkins.
4. Fichier Secret (Secret File) : Utilisé pour télécharger des fichiers entiers sensibles, tels que des trousses de clés (keystores), des certificats (.pem, .crt) ou des fichiers de configuration contenant des secrets.

Astuce : Utilisez toujours le type d'information d'identification le plus granulaire possible. Par exemple, si vous n'avez besoin que d'une clé API, utilisez Texte Secret plutôt que d'essayer de l'intégrer dans un champ Nom d'utilisateur et Mot de passe.

Principe du moindre privilège : Portée des informations d'identification

La portée des informations d'identification détermine où elles sont accessibles dans l'environnement Jenkins. Appliquer le principe du moindre privilège — n'accorder que l'accès nécessaire pour le travail — est crucial.

1. Portée Système (System Scope)

Les informations d'identification de portée système (stockées sous Manage Jenkins > Manage Credentials > Jenkins) sont disponibles globalement pour tous les travaux, dossiers et pipelines de l'instance Jenkins.

• Utilisation : N'utilisez la portée Système que pour les secrets requis par l'ensemble de l'opération Jenkins, tels que les informations d'identification utilisées par les plugins de configuration globale ou les secrets nécessaires à toutes les connexions d'agents.
• Avertissement : Minimisez l'utilisation de la portée Système. Tout travail compromis pourrait potentiellement accéder à tous les secrets disponibles globalement.

2. Portée Dossier (Folder Scope)

Les informations d'identification de portée dossier sont définies dans un dossier spécifique (créé à l'aide du plugin Dossier ou via les dossiers d'Organisation). Ces secrets ne sont visibles et utilisables que par les travaux résidant dans ce dossier et ses sous-dossiers.

• Recommandation : Privilégiez toujours la portée Dossier. Cela compartimente l'accès et limite le rayon d'impact si un projet est compromis.

Injection sécurisée dans les pipelines déclaratifs

Le codage source des informations d'identification dans les scripts de pipeline ou l'utilisation de variables d'environnement standard est strictement interdit, car les variables d'environnement peuvent être facilement exposées dans les journaux ou les commandes shell.

La méthode sécurisée pour accéder aux informations d'identification dans un pipeline déclaratif est d'utiliser l'étape intégrée withCredentials. Cette étape charge l'information d'identification spécifiée dans une variable d'environnement délimitée qui n'est disponible que pendant l'exécution du bloc.

Exemple 1 : Injection de texte secret (Jeton API)

Cet exemple récupère en toute sécurité une information d'identification de type Texte Secret (MY_API_TOKEN) et attribue sa valeur à la variable interne SECRET_TOKEN. Une fois le bloc withCredentials terminé, SECRET_TOKEN est automatiquement supprimé de l'environnement.

pipeline {
    agent any
    stages {
        stage('Deploy via API') {
            steps {
                script {
                    withCredentials([string(credentialsId: 'MY_API_TOKEN', variable: 'SECRET_TOKEN')]) {
                        // Utiliser la variable injectée en toute sécurité
                        sh "echo 'Appel de l'API externe...'"
                        sh "curl -X POST -H 'Authorization: Bearer ${SECRET_TOKEN}' https://api.mycorp.com/deploy"
                    }
                    // La variable n'est pas disponible en dehors de ce bloc
                    sh 'echo "Tentative d'accès au jeton : ${SECRET_TOKEN}"'
                    // ^ Ceci affichera null ou la valeur d'environnement précédente (protégeant contre l'exposition accidentelle)
                }
            }
        }
    }
}

Exemple 2 : Injection de nom d'utilisateur et de mot de passe

Lors de l'utilisation des informations d'identification Nom d'utilisateur et Mot de passe, l'étape withCredentials divise le secret en deux variables : une pour le nom d'utilisateur et une pour le mot de passe, généralement suffixées par _USR et _PSW (ou des noms personnalisés).

pipeline {
    agent any
    stages {
        stage('Login to Registry') {
            steps {
                withCredentials([usernamePassword(credentialsId: 'DOCKER_REGISTRY_CRED', usernameVariable: 'DOCKER_USER', passwordVariable: 'DOCKER_PASS')]) {
                    sh "docker login -u ${DOCKER_USER} -p ${DOCKER_PASS} my.registry.com"
                }
            }
        }
    }
}

Avertissement de sécurité : Suppression des journaux

Jenkins tente automatiquement de supprimer les valeurs d'identification des journaux de construction standard. Cependant, cela repose sur une simple correspondance de chaînes de caractères. N'utilisez jamais echo pour imprimer la valeur de la variable d'identification. Si le débogage nécessite de connaître le contenu de la variable, assurez-vous d'utiliser la forme masquée fournie par l'étape withCredentials, et supprimez la sortie de débogage immédiatement après avoir résolu le problème.

Intégration de sécurité avancée

Pour les environnements de haute sécurité, se fier uniquement à la clé maître locale de Jenkins est souvent insuffisant. L'intégration avec un système de gestion des secrets externe offre une séparation des préoccupations, une audition centralisée et des capacités de chiffrement améliorées.

Magasins de secrets externes

Les intégrations populaires comprennent :

• HashiCorp Vault : En utilisant le plugin Vault, Jenkins peut demander dynamiquement des secrets à Vault à l'exécution. Cela signifie que les secrets ne sont jamais stockés de manière permanente sur le contrôleur Jenkins, mais seulement temporairement en mémoire pendant la phase d'exécution.
• AWS Secrets Manager/Azure Key Vault : Les plugins natifs du cloud permettent aux pipelines de récupérer des secrets directement à partir de ces services en utilisant des rôles IAM ou des principaux de service, minimisant ainsi l'exposition des informations d'identification statiques.

L'utilisation de magasins externes s'aligne sur les meilleures pratiques de sécurité en :

1. Séparant le stockage : L'infrastructure des secrets est découplée du serveur CI/CD.
2. Accès dynamique : Les secrets peuvent être soumis à une rotation fréquente sans nécessiter de mises à jour manuelles de la configuration Jenkins.
3. Audition améliorée : Toutes les tentatives d'accès aux secrets sont enregistrées dans le système de coffre-fort externe.

Contrôle d'accès basé sur les rôles (RBAC)

L'implémentation d'un plugin RBAC (comme Role-based Authorization Strategy) permet aux administrateurs de contrôler non seulement qui peut exécuter un travail, mais aussi qui peut configurer et visualiser des informations d'identification spécifiques.

• Définissez des rôles qui accordent la permission d'utiliser des informations d'identification (par exemple, Job.UseCredentials).
• Restreignez la capacité de modifier ou de créer des informations d'identification de niveau Système à un petit groupe d'administrateurs de sécurité ou de plateforme.

Résumé des meilleures pratiques de gestion des informations d'identification

En suivant ces meilleures pratiques, vous transformez Jenkins d'une faiblesse de sécurité potentielle en un moteur d'automatisation robuste et sécurisé, garantissant que les données sensibles sont traitées de manière responsable tout au long du cycle de vie du CI/CD.